5 exercises — write clear asynchronous standup updates for distributed teams, where your message must stand on its own without a live conversation.
Writing a great async standup update
Use the same structure: Done / Doing / Blockers
Format for scanning — short lines or bullets, not a paragraph
Be self-contained — no one can ask a follow-up in real time
Link, don't describe — link the PR or ticket instead of explaining it
@mention the specific person when you need something
0 / 5 completed
1 / 5
Which is the best-formatted async standup message?
Async updates should be formatted to scan in seconds: a Done / Doing / Blocked structure with one short line each, and an @mention for the dependency. The reader gets the full picture instantly.
The all-lowercase run-on and the dense single paragraph force the reader to work to extract meaning. "Did some work" is too vague. In async communication there is no live channel to ask "wait, what did you mean?", so structure and clarity matter even more than in a spoken standup.
2 / 5
Why should an async update be self-contained?
In a distributed team, people read your update hours apart and across time zones. There is no live moment to clarify, so a good async update anticipates the obvious questions and answers them upfront — what changed, what is next, what you need.
While people can DM you, relying on that adds a slow round-trip and interrupts you both. "Looks professional" misses the real reason. Self-contained writing respects everyone's time and keeps an async team moving without constant back-and-forth.
3 / 5
You want to reference your work. What is the best practice in an async update?
Linking the PR and ticket keeps the update short while giving anyone who wants detail a one-click path to it. "Shipped: order validation (PR #412, JIRA-203)" is scannable and authoritative.
Describing the whole change in prose bloats the update; "the thing from yesterday" assumes shared memory that async readers may not have; pasting a full diff floods the channel. The async principle is "link, don't describe" — keep the message light and let the linked sources carry the detail.
4 / 5
How do you flag a blocker in an async update so it actually gets seen and acted on?
In async, a blocker must be visually prominent and directly addressed: its own line, a clear marker (🚫 or "Blocked:"), and an @mention of the responsible person or team with a specific ask. That is what triggers action.
Burying it in prose means it gets skimmed past; assuming someone notices or waiting for a live meeting defeats the speed advantage of async. The @mention is critical — it sends a notification to exactly the person who can unblock you, rather than hoping the right reader happens by.
5 / 5
Which convention helps a distributed team read updates quickly?
Consistent visual conventions — the same emoji or labels for done / in-progress / blocked every day — let teammates parse a channel of updates in seconds because the format is predictable. Many distributed teams standardise on exactly this.
Changing format daily forces re-learning each time; ALL CAPS reads as shouting and is hard to scan; random, unstructured posts make the channel noisy. Predictability is a feature in async communication: the more consistent your format, the less effort everyone spends reading it.