Async Communication for Distributed Engineering Teams

Async is oversold, and the overselling causes harm

The strong version of the asynchronous argument holds that meetings are waste, writing scales, and a well-run distributed team barely needs to talk. Parts of this are true and the whole is misleading, because it flattens a real distinction between activities that transfer well to writing and activities that do not.

When a team adopts the strong version wholesale, the failure is predictable. Ambiguous decisions take a fortnight because each clarification costs a full day of round-trip latency. New engineers flounder without ever articulating why. Incidents are handled by whoever is awake, badly, because context is lost at every handoff.

The useful version is narrower. Default to writing, because it is durable, inclusive of every time zone and reviewable later. Then identify the small number of activities where the round-trip cost of writing exceeds its benefit, and protect synchronous time for exactly those.

What genuinely does not transfer to writing

Ambiguity resolution is the clearest case. When a requirement is unclear, the resolution path involves several rounds of question and answer, each of which reveals the next question. Synchronously this is fifteen minutes. Asynchronously, at one exchange per day, it is a working week — and frequently the team gives up and guesses instead, which is the expensive outcome.

Incident coordination is the second. During an incident, context accumulates rapidly and decays just as fast. Sequential handoffs across a follow-the-sun rotation lose exactly the details that matter, and the recovery time reflects it. Written incident channels help, but they are a supplement to overlapping presence rather than a replacement.

Onboarding is the third and the most underestimated. A new engineer does not yet know what they do not know, which makes it very hard for them to formulate the questions that written culture assumes they will ask. This is why the first month benefits disproportionately from synchronous contact even on teams that are otherwise fully asynchronous.

The writing habits that actually matter

Three habits separate distributed teams that function from those that struggle, and none of them is about tooling. The first is writing decisions down at the moment they are made, including the options rejected and why. Half the team is asleep when most decisions happen, and a decision that exists only in a call is a decision that will be relitigated within a month.

The second is writing for the reader rather than the author. A status update that says 'still working on the migration' costs nothing to write and provides nothing. One that says what is done, what is blocked, and what decision is needed from whom is marginally more effort and eliminates an entire round trip.

The third is making documents the venue for decisions rather than the record of them. A design circulated with a comment period genuinely distributes the decision across time zones. A design presented in a call and then written up afterwards has already been decided by whoever was in the room.

Practical rules that hold up

• Default to writing; reserve synchronous time for ambiguity, incidents and onboarding
• Write the decision and the rejected alternatives, not just the outcome
• Give every document an explicit comment deadline, or nobody will comment
• State what you need from the reader in the first two lines of any update
• Record the meetings that genuinely cannot move, and accept people will watch later
• Rotate inconvenient hours on a published schedule rather than letting one region absorb them
• Treat an unanswered question after one working day as a signal to escalate to a call

Where teams most often fail at this

The most common failure is a team that believes it is asynchronous while its decisions are actually made in a daily call that one region attends comfortably and another attends at seven in the evening. The written artefacts exist, but they are summaries produced after the fact, and the people outside the call correctly perceive that their input arrives too late to matter.

The second is confusing documentation with communication. Extensive documentation that nobody reads at the moment they need it does not substitute for a written update that reaches the person who needs it. Documentation answers questions people know they have; communication surfaces the ones they do not.

The third is under-investing in the writing itself. Asynchronous working is fundamentally a bet that your team writes well enough for writing to carry the load. Teams whose written culture is thin will find that a large time-zone offset exposes every weakness simultaneously, and the offset gets blamed for problems that predate it.

Part of the Remote & Global Hiring Operations cluster · Read the pillar page