Async Updates Instead of Meetings
Monday, 9:05 a.m. Your team’s “standup” starts late. Four people read tickets aloud. Two are muted on another call. One person needed a decision yesterday. You hang up at 9:28 with the same blockers you walked in with, plus a vague “I’ll Slack you.”
That meeting did not fail because people are lazy. It failed because the job was information transfer, and live video is a bad tool for that. Status, weekly reviews, and many “quick syncs” work better as async updates: short written notes on a shared channel or doc, with clear asks and response times.
This guide is for remote and hybrid teams, managers redesigning communication, and ICs proposing a better ritual. You’ll get when async beats a meeting, how to write updates people actually read, copy-ready templates, and how to keep accountability without a recurring Zoom.
When async is better (and when it isn’t)
Async usually wins when:
- The goal is status, progress, or FYI (inform, not decide live)
- People are in different time zones or maker-heavy schedules
- You need a searchable record more than a vibe check
- The “meeting” has become a round-robin with no decisions
Stay live (or escalate to live) when:
- You’re negotiating tradeoffs under real ambiguity
- Conflict, trust repair, or sensitive feedback is involved
- A blocker needs rapid back-and-forth that would take days in thread
- You’re building shared judgment on something new (first architecture review, crisis response)
Async is a meeting alternative, not a religion. If last week’s live slot produced zero decisions and only restated a dashboard, cancel it and write instead. If a thread keeps spawning confusion or emotion, book 15 minutes and talk.
For the broader filter on whether a meeting should exist, see how to run effective meetings. For scripts when you want out of an invite, see how to decline a meeting politely.
The insight: structure beats volume
Async fails when it’s a meeting transcript pasted into Slack. Walls of text, no ask, no owner, no due time. People skim, react with an emoji, and nothing moves.
It works when each update answers four fields only: progress, plan, problems, ask, and every ask has a named owner and a due response time. Structure beats volume. Readers should know in under a minute what changed, what’s next, what’s stuck, and what you need from whom by when.
What belongs in a strong async update
Keep it scannable. Lead with the work, not the autobiography.
Daily / weekly async update template (PPP + Ask)
Update: [project or team] | [date]
Owner: [name]
Progress: What shipped or moved since last update (bullets, facts)
Plan: What you’re doing next (next 1–3 concrete steps)
Problems: Blockers, risks, or surprises (name impact if known)
Ask: Who / what / by when
- @Name: please [decision or input] by [day/time]
- Response needed: yes / no (FYI only)
Progress is evidence, not vibes (“Merged auth fix; QA on staging” beats “Making good progress”). Plan is near-term and owned. Problems without an ask is a diary entry. Pair them. Ask is optional when you’re truly FYI, but say so: “No response needed.”
Example (composite, fictional)
Update: Checkout redesign | Wed
Owner: Jordan
Progress:
- Mobile cart prototype in Figma (v3)
- Analytics event list reviewed with Data
Plan:
- Usability test Thu with 3 customers
- Hand off specs to Eng Friday
Problems:
- Legal still reviewing refund copy (blocks Eng handoff)
Ask:
- @Sam (Legal): approve or redline refund paragraph by Thu 3pm PT
- Response needed: yes
That note can replace a 20-minute status call for everyone who only needed the ask.
Channels: pick one home per ritual
Don’t spray the same update across email, three chat channels, and a ticket comment.
| Ritual | Good home |
|---|---|
| Daily standup | Team Slack/Teams channel or standup bot |
| Weekly review | Shared doc or wiki page |
| Project status | Ticket epic + short channel summary |
| Cross-team FYI | Email or announcements channel + doc link |
Tickets hold task truth. Chat holds asks. Docs hold decisions and weekly narrative. Mix them on purpose; don’t make people hunt.
How to run an async standup or weekly review
Async standup: Set a post window (e.g., by 10 a.m. local). Everyone posts PPP + Ask. A facilitator scans only Problems and Asks. Unresolved asks get a reply, a ticket, or a live huddle. No round-robin theater.
Async weekly review: Owners post by a deadline. Readers get a response window (often 24 hours). Facilitator posts a short synthesis: decisions made, open asks, anything that needs live debate. Cancel the old Zoom when the synthesis has nothing live-worthy.
Before → after redesign
Before: 30-minute Tuesday “status sync,” eight people, round-robin, one real decision every other week.
After: Monday written updates in a shared doc (PPP + Ask). Tuesday 15-minute optional huddle only if the doc lists a decision or blocker. If that column is empty by Monday 4 p.m., the huddle auto-cancels.
Same accountability, less theater. If you still need a live operating review for exceptions, see how to run a status meeting.
Getting people to read and respond
Unread async is quieter meeting waste. Make reading cheap:
- Same format every time so eyes know where to look
- Put the Ask in a bold line; don’t bury it
- @mention only people who must act
- Cap length; link out for deep context
- Close the loop in public (“Decided: ship Friday. Thanks @Sam.”)
Managers model the habit: reply to asks on time, praise clear updates, and once rewrite a vague one (“Please resend with Progress / Plan / Problems / Ask”) instead of accepting fog.
Response SLAs
Write defaults down. Examples to adapt (not universal rules):
- FYI: no reply required
- Normal ask: reply or decide within one business day
- Blocking ask: reply within four business hours or propose a live slot
- Decision proposal: decide-by date on the doc (often 48 business hours)
Define clocks in a named timezone or shared core overlap. A Tuesday 5 p.m. PT ask should not silently fail a teammate in London who already logged off.
Decisions async without endless threads
Status updates inform. Decision proposals decide.
Async decision proposal template
Decision needed: [one sentence]
Context: [3–5 lines max; link to detail]
Options:
A) …
B) …
C) …
Recommendation: [which + why in 2–3 lines]
Decide-by: [date/time + timezone]
Decision owner: [name]
How to vote/comment: [thread / doc comments]
Escalation: if no consensus by decide-by, [owner] calls it or books 15 min live
Keep threads sane: one decision per proposal, recommendation required, hard decide-by, named owner who will close. Then record it.
Async decision record
Decision: [what we chose]
Date: … | Owner: …
Options considered: …
Why: …
Revisit if: [trigger]
Link to proposal: …
Store that in a project doc or decision log, not only in chat scrollback.
Escalate from async to live cleanly
Escalation is normal when: more than two clarifying rounds without convergence; emotional heat; a blocker with real customer or launch impact today; three or more functions need to negotiate live.
Script: “Thread isn’t converging on the refund copy. Booking 15 minutes tomorrow 10:30 PT with @Sam @Jordan. Agenda: choose Option A or B; pre-read is the proposal doc.”
Show up having read the doc. Don’t restart as a live reading of the thread.
Time zones, busywork guards, and a small pilot
Time zones: Post at the end of your day so the next region can act at the start of theirs. Use named-zone deadlines (“Thu 3pm PT”). Avoid “ASAP” and bare “EOD.” Keep a short overlap window for true blockers.
Busywork guards: Measure outcomes, not post counts. Allow “nothing material” days. Ban forensic tone. Kill dead rituals instead of guilt-tripping ghost posts.
Pilot one meeting first: Pick a status-heavy recurring slot. Run two weeks of written PPP + Ask with live time only for listed decisions or blockers. Review what worked. Expand only that.
Team agreement checklist
- [ ] Default channel/doc for updates
- [ ] Update format (PPP + Ask)
- [ ] Posting deadline and cadence
- [ ] Response SLAs (FYI / normal / blocking)
- [ ] Emoji or ack meanings (if any)
- [ ] Escalation rule to a live huddle
- [ ] Where decisions get recorded
- [ ] Time zone / deadline convention
- [ ] Pilot end date and review owner
FAQ
How long should an async update be?
Long enough for progress, plan, problems, and ask. Short enough to skim in under a minute. Link out for narrative; keep the channel post as summary plus ask.
What if teammates ignore written updates?
Tighten the Ask, @mention fewer people, and chase only open asks. Treat unanswered blocking asks like missed meeting actions. Fix a messy template before blaming attention spans.
Can async replace 1:1s?
No. Move status out of 1:1s so live time stays for trust and coaching. See how to run a 1:1 meeting.
What if leadership wants the live meeting anyway?
Offer a hybrid: async pre-read and updates, live time only for decisions and risks. Many leaders want visibility and calls, not eight people reading tickets aloud.
Async updates instead of meetings work when you replace the calendar stub with a clear written job: four fields, named asks, real response times, and a clean path back to a short live talk when the thread stalls. Start with one ritual. The quiet you get back is calendar space, and a record you can use next week.