Async and remote stand-ups
When an async stand-up beats a live one, how to run it in a thread, handling timezones, and the tradeoffs remote and distributed teams have to manage on purpose.
An async stand-up replaces the live daily meeting with short written updates that each person posts by a set deadline — no shared clock, no everyone-in-a-room. It trades real-time coordination for schedule flexibility, and for the right team that’s a good trade. For the wrong team it’s a channel full of updates nobody reads.
The question is never “async or live?” in the abstract. It’s “what does this team’s work actually need each morning” — and the answer changes with distribution, coupling, and trust.
When async wins
Reach for async when the cost of synchronising everyone is high and the work doesn’t demand a real-time huddle:
- Timezone spread. If the team spans more than a few hours, a single live slot is somebody’s lunch and somebody else’s late evening. Async stops the meeting from taxing the people furthest from headquarters.
- Deep-focus work. For teams whose value is uninterrupted maker time, a fixed morning meeting is a daily context-switch. Async lets people fold the update into a natural break.
- A stand-up that had already decayed. If the live meeting had become a status recital, moving it async at least stops it eating a synchronous fifteen minutes — though that’s treating a symptom; see the anti-patterns for the underlying fix.
When to stay live
Async is not a free upgrade. Keep the meeting live when:
- The work is tightly coupled. If people are constantly stepping on each other’s changes, real-time coordination prevents collisions that a once-a-day written post won’t.
- The team is new or low-trust. A live stand-up is partly a workaround for a team that can’t yet read itself. Written updates assume a habit of surfacing problems that a young team may not have — see the three questions for why blockers get under-reported.
- Blockers need resolving now. Some blockers can’t wait for a thread reply three hours later. If your blockers are typically urgent, the latency of async is a real cost.
How to run an async stand-up
The mechanics are simple; the discipline is in the follow-up.
- One channel, one deadline. Pick a dedicated channel and a posting deadline in each person’s local morning. A rolling local deadline beats a single global time — nobody’s stand-up should be their midnight.
- The same short prompt every day. Focus, blockers, anything the team needs from you. Use a consistent async template so updates are scannable and comparable.
- Thread the back-and-forth. Keep the channel to one post per person; every follow-up goes in a thread, or the channel is unreadable by mid-morning.
- Answer the blockers. This is the step that separates a working async stand-up from a wall of ignored text. A blocker posted and un-answered is worse than a blocker raised live and forgotten, because now there’s a written record of the team not helping.
- Escalate what’s stuck. Any blocker that isn’t moving after a round of thread replies gets a fifteen-minute live call with the two people it concerns. Async is the default, not a religion.
The tradeoff you’re actually making
Live and async optimise for different things, and pretending otherwise is how teams end up unhappy with both.
| Live stand-up | Async stand-up | |
|---|---|---|
| Coordination | Real-time; blockers resolved on the spot | Delayed; blockers resolved in threads |
| Schedule cost | Everyone stops at once | Fold into your own morning |
| Timezones | Punishes the outliers | Neutral |
| Best for | Coupled work, new teams | Distributed, focus-heavy teams |
| Failure mode | The forty-minute status meeting | The channel nobody reads |
Most distributed teams land on a blend: async by default, with a small live overlap window for the conversations that genuinely need it. What matters is choosing on purpose rather than defaulting to a daily video call because that’s what “stand-up” sounds like.
For where the stand-up sits in the sprint, see the agile ceremonies guide; for making any format stick, start with how to run an effective stand-up; or return to the daily stand-up guide for the full set of chapters.
Frequently asked questions
What is an async stand-up?
An async stand-up replaces the live daily meeting with short written updates each person posts by a set deadline — usually in a channel, thread, or stand-up tool. Everyone answers the same brief prompts on their own time, and the team reads and responds when they log on. It trades the real-time back-and-forth of a live sync for schedule flexibility, which is why it suits distributed and timezone-split teams.
When should a team run async instead of a live stand-up?
When the cost of getting everyone in a room at once is high and the work doesn’t need real-time coordination. Distributed teams across timezones, teams with heavy maker-focus time to protect, and teams where the daily meeting had already decayed into status are all good candidates. Run live when the work is tightly coupled, the team is new or low-trust, or blockers need to be resolved in the moment.
How do you run a stand-up across time zones?
Go async by default and set a rolling deadline in each person’s local morning rather than a single global time. Collect the updates into one digest so nobody has to piece together a scattered thread, keep a shared board as the source of truth, and reserve a small overlap window for the handful of conversations that genuinely need to be live. Don’t force someone’s midnight to be someone else’s stand-up.
Do async stand-ups actually work?
They work when the team treats them as coordination, not compliance. The failure mode is a channel of updates nobody reads — status theatre with extra steps. Async works when blockers get answered in threads, stalled items get escalated to a quick call, and the updates are short enough to actually scan. If people are posting into a void, the format isn’t the problem; the follow-up is.