The daily standup was designed for a team that could physically stand up together. Transplanted onto a distributed team, it inherits a pile of costs nobody budgeted for: one calendar slot that is somebody’s 7 a.m. and somebody else’s 6 p.m., a queue of one-at-a-time updates that only one person at a time cares about, and status reports delivered at a fixed time regardless of when anything actually changed.
The asynchronous standup replaces the meeting with a written ritual: everyone posts a short update in the team channel, at the start of their own day, in their own time zone. It sounds like a small change. In practice it’s the difference between coordination that costs 15 synchronized minutes and coordination that costs 3 unsynchronized ones.
What an async standup replaces
Be precise about what you’re replacing — and what you’re not. The async standup replaces the informational part of the daily meeting: what everyone is doing, what’s blocked, what needs attention. It does not replace human contact, live problem-solving, or the occasional argument that genuinely needs voices and whiteboards. Keep those; put them in your overlap hours, per Improving Remote Team Coordination.
The test for whether your standup can go async: if the meeting is mostly people taking turns talking while others wait, it’s informational. Written updates do that job strictly better — searchable, skimmable, and readable at double speed.
The three questions still work — with changes
The classic prompts survive, but they need rewording for a reader, not a listener:
- “Yesterday” becomes “done.” What did you finish or move forward? Past-tense, concrete, with links to the work.
- “Today” becomes “doing.” What are you working on now, and roughly when should people expect it?
- “Blockers” becomes “needs.” The rewording matters: “blocked” invites a list of complaints, while “needs” invites a request someone can act on — “need a review on the pricing doc by 14:00 UTC,” “need a decision on the API approach.”
A fourth line is optional but valuable: “signal” — one sentence of context the team should know that isn’t a task. “Client demo moved to Thursday,” “I’m offline after 15:00 for school pickup.” It replaces the ambient awareness co-located teams get from the room.
Where written updates should live
Three requirements decide the location: everyone on the team can see it, updates thread separately from each other, and the history stays browsable. That points to your chat platform’s channel, using threads:
- One team, one standup channel (or a dedicated thread convention in the team channel, if your platform threads well).
- Each person’s update is its own thread — replies and problem-solving happen inside the thread, not as top-level interruptions. The channel stays a clean, skimmable feed of one thread per person per day.
- Purpose-built standup apps exist — scheduled prompts, forms, rollups. They’re fine, but they add a place to check. The channel version has one advantage that’s hard to beat: updates arrive where discussion already happens.
Timing, threads, and time zones
The async standup’s superpower is that “daily” stops meaning “at 9:30 for everyone”:
- Everyone posts at the start of their working day. The team’s day becomes a relay — the first time zone’s updates are waiting when the next region logs on. This is the handoff pattern from Improving Remote Team Coordination, applied daily.
- Read before you write. Skim the threads that accumulated overnight first; your update should acknowledge anything that affects you.
- Threads get replies, not the channel. A blocker mentioned in someone’s update is answered in that thread by whoever can unblock it — asynchronously, usually within hours, which is still faster than “let’s discuss at tomorrow’s standup.”
- Skip days when nothing changed. “No update today — same as yesterday” is a legitimate post and better than noise. The ritual serves the information, not the other way around.
Keeping updates honest and short
Written standups fail in two predictable ways: they bloat into diaries, or they curdle into theater — polished summaries that hide problems. Guardrails for both:
- Length limit: five lines. If it doesn’t fit, the detail belongs in a task, a document, or a thread of its own.
- Links over prose. “Finished the migration plan — [link]” beats a paragraph describing the plan.
- Blockers stated as requests with deadlines, so they’re either resolved or visibly aging. A blocker nobody can act on for two days is a management signal, not a status.
- Leaders model honesty: when the most senior person posts “stuck on X, spent the morning on it, not sure it was worth it,” everyone else stops performing. Culture in a written standup is set by the most-watched post, same as everywhere.
- Review the ritual quarterly: is anyone reading them? Do replies happen? If updates have become wallpaper, change the prompts, the channel, or the cadence — the fix is usually one of those three. Fold it into the review from Reviewing and Improving Digital Collaboration Practices.
When live check-ins are still better
Some teams should keep a live component: very small teams in one time zone (the written overhead buys little), brand-new teams still calibrating on each other, and teams in active crisis, where hourly contact genuinely matters. The hybrid that works: async updates daily, one short live session weekly — reserved for discussion, not status. The template for that session is in Building Repeatable Meeting Workflows.
Rolling it out
- Announce the experiment with an end date — “four weeks, then we decide.” Experiments with no exit become resentments.
- Post the prompt template and let the first week be rough. Updates will be too long, then self-correct.
- Have the leader post first for the first several days — format spreads by imitation, not instruction.
- At the end date, review together: did anyone miss the live meeting? Did blockers resolve faster or slower? Keep what worked; the most common verdict is “daily written, weekly live,” which is a fine answer.
Two weeks in, most teams report the same discovery: the information was never the reason for the meeting — it was just the only format anyone had tried. For the surrounding rituals — response expectations, channel routing, writing norms — see Creating Clear Internal Communication Guidelines, or browse the full guides library.