Async Meeting Etiquette: Making Written Updates Work Across Time Zones
The async update is the distributed team's most-used meeting format — and its most abused. How to write updates people can act on eight hours later, set response norms, and know when writing stops working.
Published
On a global team, the most common meeting is not a call at all — it is the written update, the discussion thread, the recorded walkthrough: the whole family of asynchronous exchanges that carry a team's real work between its rare live meetings. Async has a reputation for being more efficient, and it is — but only when it is done with the same care a good meeting chair brings. A badly written update consumes the reader's scarce morning attention without giving them anything to act on; a chaotic thread spreads a decision across forty messages so no one can find it. Async meeting etiquette is the craft of making writing do the work of talking, without wasting the reader's day.
Write for a reader you cannot interrupt
The fundamental constraint of async writing is the same as the handoff note: your reader cannot ask a clarifying question, because by the time they read it, you are asleep. Every question you would have answered verbally in a meeting has to be answered preemptively in the text. That changes what a good update looks like. It leads with the conclusion — what happened, what is decided, what is needed — before any narrative of how you got there. Readers on other continents have limited overlapping attention; giving them the outcome in the first two lines means most of them can stop reading there, and the ones who need the reasoning can keep going.
Structure is a courtesy. A wall of text is a tax on every reader to excavate what matters; headings, short paragraphs, and bullet points let a reader find their part in seconds. State explicitly at the end what you need from whom and by when — 'I need review from Priya by Wednesday 10:00 Europe/Berlin; no action needed from anyone else.' The single most common failure of async updates is ending without a request, forcing every reader to guess whether they were expected to do something.
Before sending an update, re-read it as the person eight time zones away who has no context on what you did yesterday. If they could not act on it without asking you a question, you are not done writing.
Response-time norms: silence is not a status
Async etiquette's second pillar is expectation-setting about replies. Without explicit norms, distributed teams drift into one of two failure modes: everyone expects instant replies (and the team quietly starts working evenings), or no one expects any reply (and legitimate questions sink unanswered). The healthy norm is tiered: normal channel messages get a response within one working day of the recipient; things blocking someone else's work get a same-day acknowledgment even if the full answer takes longer; and anything truly urgent uses the designated urgent path, not a louder message. Publishing this takes one team conversation and removes a background anxiety that otherwise runs constantly.
Acknowledgment deserves its own mention, because it is the cheapest courtesy in async work and the most frequently skipped. 'Seen this, will reply properly in my morning' takes ten seconds and converts the sender's open question into a known state. Without it, the sender re-sends, pings, wonders, and eventually interrupts someone's evening — a chain of wasted effort that a one-line acknowledgment would have prevented entirely.
The status update format that scales
Recurring written standups work best with a fixed skeleton, because a fixed skeleton is scannable and comparable across people. The classic three-part format — done, doing, blocked — has survived everywhere because it answers the reader's actual questions in order: what changed, what is next, and where do I need to help. Two upgrades make it work better across time zones: date every entry (a reader joining the thread a day late should never have to work out which day it describes), and make blockers specific about who is being asked for what and by when. A blocker that says 'waiting on the design team' informs; one that says 'need the final mockup from Design by Thursday 12:00 Europe/Madrid — Ana is the owner' gets unblocked.
Recorded walkthroughs: the async meeting with a face
The recorded video walkthrough deserves more use than most teams give it: it carries tone, diagrams, and screen context that writing struggles with, and it is the most human-feeling format a person in another zone will consume all day. Its etiquette is about respecting the viewer's time. Keep it short — five minutes is the sweet spot, and anything past ten needs timestamps. Say at the start what the viewer will get and whether they need to act. And always pair the video with a written summary of the decisions and requests, because a video without a summary cannot be skimmed, searched, or quoted — and the reader at 7 AM needs the summary far more than they need your face.
Threads, threads, and decisions
Discussion threads are where async teams win or lose their decision records. The etiquette is simple: one thread, one topic — fork a new thread rather than hijacking an existing one, because a hijacked topic is invisible to the people who filtered the original thread out. Quote the specific part you are responding to, not the whole message. And when a thread reaches a decision, close the loop with a clearly-marked summary message — 'DECISION:' at the start, the outcome, the owner, and the date — so the decision is findable without re-reading the debate. Teams that skip this step re-litigate their own decisions monthly, usually in a new thread where nobody can find the old one.
Knowing when async stops working
The final piece of async etiquette is the honesty to escalate to a live conversation when writing has hit its limit. The signals are recognizable: a thread has gone three rounds without converging; the disagreement is about values or feelings rather than facts; the message you just drafted has taken forty-five minutes and three rewrites because it keeps sounding wrong; or the topic is sensitive enough that tone will be misread no matter how carefully you write. Those are not writing problems — they are the problems writing was never designed to solve. A good async culture is not one that never meets; it is one that reserves its live, expensive, hard-to-schedule synchronous time for exactly these conversations, and runs everything else in writing.
Conclusion
Async meeting etiquette comes down to three habits: write for a reader who cannot ask you anything, make the reply norms explicit so silence means sleep rather than neglect, and mark decisions and requests so clearly that no one has to read anything twice. Teams that master them find that the async channel carries most of the coordination load — and their rare live meetings, freed from status updates, become worth the scheduling effort they cost.
