Most async standups are the synchronous standup format pasted into a chat bot. What did you do, what will you do, what's blocking you — three questions, posted at start of day, ignored by lunch. The format is the problem. Fixing it takes two structural changes and a willingness to write at the end of shift instead of the start.
Why the synchronous format breaks async
The synchronous standup format depends on three things that don't exist async: immediate clarification, shared context, and the social signal of seeing the speaker's expression. Take those away and you're left with a form.
The form gets filled. The team doesn't read it. The blocker that should have been escalated sits there for another shift.
Replace the three questions with state transfer
Drop "what did you do" entirely. It's a status report, not useful to anyone. Replace with:
- State — what is currently shipped, in review, in progress, or stuck.
- Next — the specific next action for the incoming shift or the same person tomorrow.
- Decisions — anything decided in the last cycle that the team should know about.
- Blockers + asks — what's blocked, who can unblock it, and the deadline.
Same time to write. Useful to read.
Write at end of shift, not start of day
End-of-shift writing has 80% better information quality than start-of-day. The writer still has the context loaded; the reader doesn't have to wait for it. Adopting this single change usually improves async standup outcomes more than any other tweak.
If your bot prompts at 9am, change it to prompt at end of shift. If your team resists, run it as an experiment for two weeks.
Make the post queryable, not buried in a thread
If async standups live in a Slack thread, they're functionally invisible after 24 hours. Use a structured place — a wraps database, a governance tool, a doc with stable URLs. Anywhere a teammate can search for "what happened last Tuesday on payments" and get an answer.
Validate completeness
A standup that says "working on stuff, no blockers" is worse than no standup — it teaches the team that incomplete posts are fine. Either reject incomplete posts (manually or via tooling) or set a team norm: a post missing the state-and-next fields is incomplete.
The threshold is low: about 90 seconds of writing produces a complete post. If you can't get 90 seconds, you can't get async standups working.
From Status to State Transfer
StandIn replaces status posts with structured wraps that capture decisions, next actions, and authority — the things async standups miss.
See the Workflow →Have a manager actually read them
The biggest reason async standups die: nobody reads them. The EM scans them in the first week, then stops. The team notices. Within a month, posts become perfunctory.
Fix it by giving the EM a 10-minute morning read window and a reply norm — at least one substantive reply per day, naming a blocker or escalating an ask. The signal that someone reads is what keeps the writing real.
Don't run an async standup for every team
Small co-located teams don't need them. Large teams across 6+ timezones do. The middle is judgment. The signal: if your team is having more than one "wait, what's happening with X" moment per week, you'd benefit. If you're not, don't add the ritual.
Common failure modes
Failure: bot fatigue. Three bots posting prompts, none of them read. Consolidate to one. Kill the others.
Failure: requiring posts that turn into theater. If posts are mandatory and unread, they become checkbox compliance. Either read them or stop requiring them.
Failure: optimizing for managers, not engineers. If the standup post is shaped to make the manager feel informed, engineers will write to that audience. Shape it for the next-shift engineer instead; the manager benefits as a side effect.
What to do tomorrow
Pick one async standup to fix. Change the prompt to the four fields above. Move the writing trigger to end of shift. Set the destination to something queryable. Commit to one EM-substantive-reply per day for two weeks. Then measure: are blockers getting resolved faster? Are morning context-reconstruction times dropping? If yes, expand.
Frequently asked questions
How long should an async standup post be?
100-200 words for a normal day. Less and you've under-shared; more and nobody reads it. The bot prompt should hint at the right length, not enforce it.
What if I have nothing new to say?
Write "no state change, next action still X, blocker still Y, deadline Z." That's a complete post; it tells the team they don't need to reconstruct anything.
Do remote-first teams need standups at all?
Many don't, if they have good wraps and decision records. The standup is a fallback when those structures are weak. Build the stronger structures first; standups may become redundant.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to eliminate your daily standup?
Distributed teams use StandIn to start every shift with full context — no standup required. Engineers post a 60-second wrap. The next shift wakes up knowing exactly what to work on.