Engineering Through the Remote Work Transition

March 16, 2020

The shift to remote work has happened almost overnight for many organizations. Teams that never imagined working from home are now doing it indefinitely. The transition is jarring, but engineering teams can not only survive—they can thrive.

Here’s how to make remote engineering work.

Immediate Priorities

Week 1: Get Functional

Focus on basics:

Access:

Equipment:

Security:

Week 2-4: Establish Rhythm

Build sustainable practices:

Communication cadence:

Documentation:

Communication Patterns

Async by Default

Remote work favors asynchronous communication:

## Good Async Communication

### Slack message:
"I'm investigating the timeout issue in the order service.
Current hypothesis: connection pool exhaustion.
Plan: Add metrics, review connection settings.
Will update by EOD with findings.
No action needed from anyone unless you have insights."

### Not this:
"Hey, anyone know about the order service?"
[waits for response]
"It's timing out sometimes"
[waits for response]
...

Async practices:

Sync When Needed

Reserve synchronous communication for:

Meeting Hygiene

Meetings are more draining remote:

Before:

During:

After:

Daily Rhythms

Structured Days

Remote work needs more structure, not less:

## Example Engineering Day

08:30 - Start work, review messages/emails
09:00 - Deep work block (no meetings)
12:00 - Lunch break
13:00 - Standup (15 min)
13:30 - Meetings/collaboration
15:30 - Deep work block
17:30 - Wrap up, document status
18:00 - End of day

Deep Work Protection

Protect focus time:

Boundaries

Working from home blurs boundaries:

Code Collaboration

Pull Requests

PRs become the primary collaboration point:

## Pull Request Template

### What
Brief description of changes

### Why
Context and motivation

### How to Test
1. Check out branch
2. Run `make test`
3. Verify X behavior

### Screenshots (if UI changes)
[images]

### Notes for Reviewers
- Pay attention to X
- Y is intentionally simplified, will address in follow-up

Code Review

Remote code review needs more context:

Reviewer guidelines:

Author guidelines:

Pair Programming

Pair programming works remotely:

Tools:

Practices:

Team Health

Combat Isolation

Remote work can be lonely:

Scheduled social time:

Check-ins:

Psychological Safety

Maintain team trust:

Onboarding Remotely

New hires need extra support:

First week:

First month:

Tools and Infrastructure

Essential Stack

communication:
  async: Slack, Teams, or Discord
  sync: Zoom, Meet, or Teams
  persistent: Notion, Confluence, or similar

development:
  code: GitHub, GitLab, or Bitbucket
  ci_cd: GitHub Actions, CircleCI, etc.
  environments: Cloud-accessible dev environments

collaboration:
  design: Figma, Miro for whiteboarding
  docs: Google Docs, Notion
  project: Jira, Linear, Asana

security:
  vpn: Corporate VPN for sensitive access
  sso: Single sign-on for all tools
  2fa: Required everywhere

Home Office Minimum

What engineers need at home:

Company support matters here.

Management Adjustments

Output Over Hours

Trust and verify results, not presence:

## Good metrics:
- PRs merged
- Features shipped
- Tickets closed
- Quality of work

## Not helpful:
- Hours logged
- Slack activity
- Response time to every message

More Communication, Not Micromanagement

Increase touchpoints without hovering:

Visibility Into Work

Make work visible:

Key Takeaways

The transition is hard. But engineering work—focused, asynchronous, output-oriented—is actually well-suited to remote. The teams that invest in good practices now will emerge stronger.

Take care of yourselves and each other.