"Async-first" is the slogan most distributed teams adopt within their first year, and most of them implement it badly. The failure mode is consistent: the team replaces synchronous meetings with synchronous chat, calls the result async, and discovers six months later that the chat is louder than the meetings ever were. Real async work is not "use Slack instead of Zoom." It is a small set of disciplined patterns that move decisions, status, and coordination off the synchronous critical path. This post walks through the five patterns we have seen actually work, and the four failure modes that look async but produce all the costs of synchronous work without any of the benefits.
The reason async matters specifically for time-zone-distributed teams is arithmetic: every synchronous moment requires every participant to be awake at the same time. If your team spans more than about eight hours of clock time — say, the West Coast US to most of Europe — the synchronous overlap window is small enough that holding more than one or two daily meetings inside it is hostile. Async patterns let work proceed during the 16+ hours per day when the team cannot all be present at once.
Pattern 1: Written async updates
The simplest async pattern is the written daily or weekly update. Each team member posts a structured note in a known channel — what they did since the last update, what they plan to do, what is blocking them. The note is read by the rest of the team during their working hours, in their zone. There is no live ceremony.
The structure that works is short and rigid. Three sections: shipped, working on, blocked by. Five lines maximum per section. If a section needs more than five lines, the right answer is a separate doc linked from the update — not a longer update. Long updates are read with diminishing attention; short updates are read in full.
The cadence depends on the work. Engineering teams shipping daily benefit from daily updates; teams shipping in two-week cycles can move to weekly. The cadence should match the natural unit of progress, not someone's preference for visibility. Daily updates on a team that ships weekly produce four days of "still working on the same thing" noise.
The choice of tool matters less than the choice of structure. Slack threads, GitHub issues, Notion pages, plain email — any of them work as long as the structure is consistent and the location is canonical. What does not work is mixing locations: some updates in Slack, others in Notion, others in DMs to leadership. The location is the main affordance for finding history; splitting it kills the value.
Pattern 2: Decision documents (RFCs and ADRs)
Decisions that span more than one person and more than one day belong in a document, not a meeting. The pattern is borrowed from open-source software: write down the problem, the options considered, the chosen approach, and the rationale. Circulate the document for comment with an explicit deadline. After the deadline, the decision is final unless someone reopens it.
For engineering teams, the convention is the RFC (Request for Comments) for forward-looking decisions and the ADR (Architecture Decision Record) for retrospective documentation of decisions already made. For product or design teams, the same idea is sometimes called a brief, a memo, or a one-pager. The label matters less than the structure.
The structure: title, status (draft / open for comment / accepted / superseded), context (what is the problem, why now), decision (what we are doing), consequences (what becomes harder, what becomes easier, what we are explicitly not doing). Three to five pages of writing covers most decisions. Documents over ten pages tend to be either bundling several decisions (split them) or describing a project plan rather than a decision (move it to a project doc).
The deadline matters. "Comments by end of next Tuesday" works; "please review when you can" produces zero comments and a lingering open decision. The deadline should be at least 48 working hours after publication so that everyone in the team's zones has at least one full working day to read and comment. For four-region teams, that means closer to 72 hours.
Pattern 3: Explicit response-time SLAs
The biggest single source of async friction is uncertainty about how long it will take to get a response. If you do not know whether a question will be answered in 30 minutes or three days, you cannot plan around it. The fix is to make response times explicit and tier them by urgency.
A response-time SLA we have seen work for distributed teams of 10–50 people:
| Channel / tag | Expected response | Use for |
|---|---|---|
| PagerDuty (or equivalent) | 5 minutes | Production incidents only |
| Slack DM marked urgent | 2 hours during sender's working day | Time-sensitive blockers |
| Slack DM (default) | 1 working day | Most one-on-one questions |
| Channel mention | 1 working day | Team-relevant questions |
| Channel post (no mention) | Best effort, may not reply | Status, FYI, conversation |
| 2 working days | External / formal | |
| RFC comment | Before stated deadline | Decision documents |
The numbers above are an example, not a recipe. The point is to publish them and live by them. A team that has explicit SLAs and meets them feels predictable, even if the SLAs are slow. A team that has no SLAs — even one with people who reply quickly — feels chaotic, because nobody can plan around the variance.
Pattern 4: Urgency tagging at the message level
Channel-level SLAs only get you so far. Most messages have a different urgency from their channel's default. The pattern that resolves this is explicit urgency tagging on individual messages: a one- or two-character prefix that signals the response window.
A common convention: [FYI] means no response expected, [Q] means a question that needs an answer eventually, [Q+] means an answer is needed within the working day, [!] means time-sensitive (within the hour). Train the team to use the tags and to honour them in both directions: senders apply them honestly, receivers respond to them within the implied window. The tags are not enforced by tooling; they are a shared norm.
The norm is fragile. It breaks the first time someone uses [!] for a non-urgent message and gets the response they want. Once the system is gamed, it stops being useful. The fix is social: when senders abuse urgency tags, call it out in the moment, gently. Tagging norms either get protected actively or decay quickly.
Pattern 5: Reading windows and quiet hours
Async only works if people read the async updates. The pattern that protects reading time is the explicit reading window: a time slot, recurring, when each person catches up on the asynchronous backlog without being interrupted. For a North American engineer, the reading window might be 09:00–10:00 local. For a European product manager, 14:00–15:00. The exact slot does not matter; the recurrence does.
The complement is quiet hours: published times when each person is unavailable for synchronous interruption. Posting an urgent question at 17:00 to a colleague whose quiet hours start at 18:00 means they will not answer until tomorrow's reading window — which is fine, because the SLA already said 1 working day. Quiet hours are a contract, not a preference. They prevent the slow drift toward 24-hour availability that distributed work otherwise produces.
Failure modes that look async
Four patterns we see repeatedly that get called "async" but are not.
Pseudo-async meetings
"We will have an async standup, but if you have anything to discuss, drop into the call at 10am ET." This is just a meeting with a written warm-up. The meeting time is still the constraint, and the people who cannot attend the meeting are still excluded from the discussion.
Long Slack threads as decisions
A 200-message thread in #engineering arriving at "let's go with option 2" is a synchronous meeting transcribed into chat. Anyone who joined the company a month later cannot read it; anyone in a different zone who was asleep cannot influence it. Decisions belong in decision documents; chat is for low-stakes coordination.
"Async" means "no real-time constraint, but reply now"
Some teams say async while expecting replies within 15 minutes. That is a synchronous norm with a different label. The signal is the manager who follows up on a non-urgent question after 90 minutes; the underlying expectation is sync, regardless of what is officially declared.
Documentation that nobody reads
An async culture that produces 40 pages of documentation per week — and reads none of it — is not async. It is sync work plus a documentation tax. The reading windows pattern (above) is the antidote, but only if the documents are actually short and structured enough to be read in the time allotted.
How time zones interact with async
The patterns above are valuable for any distributed team, but they become essential once the team spans multiple time zones. If the working-hours overlap is small (US ↔ India, US ↔ APAC, anything four-region), the only sustainable way to make progress on inter-region collaboration is to push it async by default. Synchronous moments become reserved for the work that genuinely cannot happen otherwise — high-bandwidth design discussion, conflict resolution, emotional context. Everything else moves to the patterns above. The follow-the-sun handoff guide covers the operational version of this for support and on-call rotations; the four-region all-hands guide covers the limits of synchronous time even when you accept the cost.
Further reading
- Running standups across time zones — async patterns applied to the daily ritual.
- Distributed retros without a single live meeting — async patterns applied to retrospectives.
- Follow-the-sun handoffs — when async-by-default meets 24-hour coverage.
- Scheduling meetings across time zones without the headache — for the synchronous moments that survive.