Async Communication: What to Write Down and What to Meet About

A hypothetical remote team spends a meeting reading status updates that were already posted in chat. The next day, a genuinely disputed design decision becomes a long thread without resolution. The problem is not a lack of communication. The team is using synchronous time for information transfer and asynchronous messages for a disagreement that needs a decision owner.

Separate information, coordination, and decisions

Information can often be written once and read when convenient. Coordination needs clear dependencies and response expectations. A decision needs options, criteria, an owner, and a deadline. These categories overlap, but distinguishing the main job helps choose the medium. A status update that says blocked is incomplete until it names what is needed, from whom, and by when.

Before inviting people, write the output you need. If the output is awareness, a concise written update may suffice. If it is approval, specify the decision and evidence. If it is shared exploration of an unfamiliar problem, a live conversation may help. This is an editorial operating method, not a claim that every distributed team should use the same communication rules.

GitLab's communication handbook documents its own written and asynchronous practices. Treat it as an example of an organization's operating choices rather than proof that the same choices improve every team's performance.

Write messages that can survive your absence

A useful request contains context, the concrete question, relevant evidence, the desired response, and a deadline with a time zone. Put the question early enough that the reader can identify the task. Link to a canonical document rather than pasting slightly different copies into several channels. Distinguish a request for feedback from a decision already made, because those require different responses.

Use headings and short paragraphs for longer proposals. State assumptions and unresolved points explicitly. A reader in another time zone should be able to continue without asking which draft is current or whether silence counts as agreement. If a response window closes before that person's working day begins, the process is effectively excluding them even if the message itself is technically asynchronous.

Decide when a live discussion earns its cost

Move to a meeting when the written exchange reveals a genuine ambiguity that participants cannot resolve efficiently, an emotionally sensitive disagreement, or an urgent operational issue requiring coordinated action. Explain why live discussion is needed and what preparation remains useful. Do not erase the thread's context; summarize the disagreement and preserve links to the evidence already collected.

A meeting also needs a decision owner. Without one, a conversation can repeat the thread's uncertainty at greater scheduling cost. Name which questions are open and which constraints are fixed. Invite people whose participation changes the outcome, while providing a written route for others to contribute. Urgency should be tied to a consequence, not the sender's preference for an immediate answer.

1. State the required output.
2. Write context and the concrete question.
3. Set an inclusive response window.
4. Escalate unresolved ambiguity to a focused discussion.
5. Record the decision and action owners in the canonical document.

A hypothetical architecture decision

A team must choose where to store generated reports. The proposal lists two options, data sensitivity, retrieval requirements, and an operational owner. Reviewers comment during an agreed window. One asks whether reports contain identifiers covered by an existing restriction. The author marks the answer unknown instead of treating silence from the data owner as permission. The implementation remains blocked on that specific fact.

After the owner clarifies the constraint, two options remain viable and the reviewers disagree about maintenance effort. A short live meeting compares those tradeoffs. The decision owner selects one, records the rationale, and names the conditions for revisiting it. This hypothetical case illustrates an asynchronous foundation with a targeted synchronous step, not a measured claim about time saved or team productivity.

Make the final record readable

The document should distinguish the proposal from the decision. Preserve the chosen option, date, owner, rationale, unresolved risks, and next actions. A transcript is not a decision record. Readers should not need to reconstruct forty comments to understand what they must do. If the decision changes, add the new rationale and identify the superseded version rather than quietly editing history.

The W3C writing tips cover clear structure and meaningful links. Those principles help make long asynchronous documents navigable, although they do not prescribe a team's decision-making process.

Protect attention without making people unreachable

Publish ordinary response expectations and a separate urgent escalation route. A team member should know whether an unanswered message means not yet read, not responsible, or waiting on someone else. Avoid requiring constant presence in several channels to prove engagement. At the same time, asynchronous work needs ownership: requests should not disappear because everyone assumes another person will reply.

Communication checklist

• Name the output: awareness, coordination, exploration, or decision.
• Put the concrete request near the beginning.
• Link the current document and relevant evidence.
• Set a deadline that includes time zones.
• State what silence does and does not mean.
• Use live time for a defined unresolved issue.
• Record decisions separately from conversation history.
• Assign each action and escalation to a person.

Review communication failures through missing information and unclear ownership before adding more meetings. Sometimes the right repair is a better question; sometimes it is a live conversation. The useful standard is whether the people involved can understand the work, contribute fairly, and act on an accessible record afterward.