4 exercises — write clear async status updates, blockers, handoffs, and standups for distributed teams.
0 / 4 completed
1 / 4
You need to write an async status update for your team. You've completed the authentication refactor and are now blocked on a backend API endpoint. Which update format communicates this best?
Option B uses BLUF structure (Bottom Line Up Front) and async communication best practices:
BLUF structure: 1. Completed work — specific, verifiable ("auth refactor done ✅") 2. Blocker with context — names what's blocking, who owns it, why it matters ("payment integration on hold") 3. Direct ask — specific person, specific request, specific deadline ("@backend: ETA by EOD today?") 4. Self-unblocking plan — "starting error-handling module" — shows no passive waiting
Why BLUF matters async: • In async communication, readers scan messages — most important info must be first • If they only read the first line, they should still understand the key status • Save context and explanation for after the headline
You're changing the scope of an upcoming feature because of a technical constraint. You need to communicate this asynchronously to the PM and two other engineers. Which update is most effective?
Option C is a professional async decision/scope change communication using the Decision Memo format:
Decision Memo structure: 1. Header — "SCOPE CHANGE" + identifier (version) — makes it scannable and searchable 2. What's changing — precise, not vague ("dropping X, replacing with Y") 3. Why — the reasoning, with specifics ("3 weeks of DevOps work not in scope") 4. Impact — honest trade-off ("slightly less instant, all functional requirements met") 5. Stakeholders named explicitly — @mentions for visibility 6. Consent by silence deadline — "objections by EOD Thursday" — prevents endless back-and-forth 7. Decision log link — preserves institutional memory
Urgency labels for async messages: • URGENT: — response same day required • INPUT NEEDED: — respond by [date] • FYI: — no response needed, for awareness • DECISION: — requires explicit approval • SCOPE CHANGE: — impacts current work
3 / 4
Your backend engineer colleague is signing off for the day (they're UTC+1). A junior developer on your team (UTC-6) will need to pick up their in-progress work. Write the handoff message.
Option B is a complete async handoff message. It eliminates the need for any back-and-forth by providing every piece of context the next engineer needs:
Complete handoff message contains: 1. Timezone + local time — so recipients can calculate overlap and response windows 2. Named recipient — @mention, not implicit 3. Precise work status per component — not "almost done" (useless) but "streaming module 70% done, specific TODO at file:line" 4. Open blockers with named person — "rate-limit config unclear, cc @architect" — prevents junior from spinning on an unanswerable question 5. Test suite status — current pass rate + root cause of failures + known fix approach 6. Exact next steps in order — so the junior doesn't have to guess what to prioritize 7. How to reach you — response window for async questions ("08:00 UTC+1 tomorrow")
Rule: A good handoff message should let the next person start working within 5 minutes without any clarifying questions.
4 / 4
Which of these async standup formats (written standup replacement) provides the most useful information for a distributed team?
Option C is a complete async standup update. Most useful standup updates follow the Yesterday/Today/Blockers/FYI structure with these elements per section:
Yesterday (what was completed): • Specific artifact (PR #288, not "worked on auth") • Discovery or side effect worth noting • Link to review-ready work
Today (what you will work on): • Named tasks with rough time estimates ("est. 4h") • Names collaborators needing your attention (@alice's PR)
Blockers: • Specific ask, named person, specific deadline ("by noon UTC") • Context needed for them to unblock you (Figma link)
FYI (team awareness): • Anything that affects others' work today
Why "Nothing to report" is harmful async: In async teams, silence is indistinguishable from being stuck. Writing "on track" provides false reassurance with zero actionable information. Even on smooth days, share what you finished and what you're starting — this allows the team to spot duplicated work and offer help proactively.