How to run async standups for engineering teams
How to run async standups for engineering teams
Async standups for engineering teams work when every engineer posts three things in a shared channel on a daily deadline: what shipped yesterday, what's planned today, and what's blocked. No meeting. No video. The format is text-first in Slack or a bot like Geekbot, with Linear or GitHub artifacts linked inline so status is verifiable, not vibes.
Most teams that "do async standups" are actually running broken standups. They replaced the 9am Zoom with a Slack thread, kept the same fluffy "I'm working on the dashboard" updates, and lost both the accountability and the unblocking. This post is the operational playbook: format, tooling, timezone math, the blocker channel pattern, sample templates, and the four things that kill async standups before they take hold.
Why daily synchronous standups break on distributed teams
A daily 15-minute standup with 6 engineers across 4 timezones costs each person at least 30 minutes (context-switch in, switch back out). If the team spans more than 4 hours of timezone gap, somebody is always there at 7am or 9pm. After three weeks of that, the West Coast engineer stops showing up and you stop noticing what they shipped.
The math is uglier than it looks. Cal Newport's deep-work research shows a single meeting interruption costs roughly 23 minutes of refocus time. A 15-minute standup is functionally a 38-minute hole in someone's morning. Six engineers, five days a week, is 19 engineer-hours per week burned on a ritual that exists to surface blockers most teams could surface in writing in 90 seconds.
Async standups aren't a culture preference. They're an arithmetic decision once your team crosses two timezones or four engineers.
The four-part format that actually works
The standard format is yesterday / today / blockers / asks. Don't reinvent it. Engineers know how to fill it in within a week, and it parses cleanly when you skim the channel later.
The four parts, in order:
- Yesterday. What you shipped. Link the PR, the Linear ticket, the Loom, the doc. No artifact, no credit.
- Today. What you're planning to ship. Linear ticket IDs make this trivially scannable.
- Blockers. What you're stuck on. Be specific. "Waiting on Stripe webhook reply" is useful. "Some API stuff" is not.
- Asks. What you need from a specific person, named.
@mariaworks because she gets pinged. "Someone" doesn't, because nobody reads themselves into it.
The asks line is the magic. Most async standup templates omit it and then wonder why people don't unblock each other in the thread. The point of a written standup isn't documentation. It's coordination.
Here's a sample post in the format we recommend:
*Yesterday:* Shipped MUL-412 (Stripe webhook retry). PR merged: github.com/co/api/pull/892
*Today:* MUL-413 (idempotency keys), MUL-419 (review Jamal's auth PR)
*Blockers:* None
*Asks:* @rafael can you confirm whether we want exponential or linear backoff on the retry job? Thread: #eng-billing
That post takes 90 seconds to write and 15 seconds to read. Six of them is a 15-minute standup that nobody sat in.
The blocker channel pattern
Here's the operational detail almost every async-standup guide leaves out. Blockers belong in a separate Slack channel, not the standup thread.
Why: blockers in the standup thread get buried under tomorrow's standup. Blockers in #eng-blockers (or whatever you call it) stay visible until someone resolves them and reacts with a :white_check_mark:. They also become searchable: "what's the third time this month we got blocked on the same Datadog integration?"
The pattern is:
- Daily standup: mention the blocker in one line. "Blocked on Auth0 SAML config, posted in #eng-blockers".
#eng-blockerschannel: every blocker becomes its own message. Format: who's blocked, on what, what they've already tried, who they need.- Anyone who can unblock reacts with
:eyes:(I'm on it) then:white_check_mark:(done). The eng manager scans the channel once a day for stale:eyes:reactions.
We've seen teams cut median time-to-unblock from 18 hours to under 4 hours just by separating the two channels. This pattern is the core of async communication for engineering teams. Written status without a structured escalation path turns into write-only theater.
Tooling: what to actually run
The standup itself is one of four moving parts. You also need a project tracker, a video tool for the cases where text fails, and an artifact store.
| Tool | What it does | Cost | Why we pick it |
|---|---|---|---|
| Slack | Standup channel, blocker channel, async threads | $7-15/user/month | Universal. The threading model is the only one that doesn't collapse under 6+ engineers. |
| Geekbot | Prompts each engineer at their local 9am, posts the answers to a Slack channel | $2.50/user/month | Best for teams who want zero ceremony. Engineers reply to a DM, output is auto-formatted. |
| Range | Same idea as Geekbot, plus async check-ins on mood and goals | $6/user/month | Better when you also want to track engineer satisfaction signals. Pricier. |
| Linear | Source of truth for tickets, sprints, cycles | $8-14/user/month | The ticket IDs in the standup post are useless without a tracker that loads instantly. Linear does. |
| Loom | Async video for the 5% of updates that need a screen recording | Free to $15/user/month | When a written explanation will take 25 minutes and a 4-minute Loom will take 4 minutes, use Loom. Transcripts make it searchable. |
| Notion | Permanent home for decisions, RFCs, retros | $10/user/month | Standups are ephemeral. Decisions made in standups go here so they survive next quarter. |
You don't need all six. The minimum viable stack is Slack plus Linear plus Geekbot. A team of 4 to 12 engineers can run quality async standups for under $25 per engineer per month in tooling. If you already pay for Slack and a tracker, Geekbot adds $2.50.
Loom is the underrated one. We've found teams switch from "let's hop on a call to walk through this" to "I'll send you a 4-min Loom" once they realize the recipient can watch at 1.75x speed during a context-switch. If you're new to it, the Loom for engineering teams playbook covers the exact use cases (PR walkthroughs, design crits, incident postmortems).
The timezone math that decides your format
Async standups only work if there's no expectation of real-time reply. The decision tree is timezone-driven.
- Same timezone or 1-3 hour spread. Synchronous standup is still defensible if engineers actually like it. But run it once a week (Monday), not daily.
- 4-6 hour spread (US East to West, or EU + East Coast US). Async daily standup, posted at each engineer's local 9am. One 90-minute overlap window for blocker resolution.
- 7+ hour spread (US + EU + APAC). Async standup is mandatory. No overlap window exists where all engineers are awake and alert. The blocker channel becomes load-bearing.
The overlap-window math is brutal. A team in San Francisco, London, and Bangalore has a working overlap of zero hours: when San Francisco wakes up at 9am, London is at 5pm, and Bangalore is at 9:30pm. The only "all-hands awake" window is San Francisco 7am to 8am, which is 3pm to 4pm London and 7:30pm to 8:30pm Bangalore. That's not a standup. That's punishment.
Once you accept that overlap is zero, the format frees up. Standups happen on each engineer's local clock. Blockers get resolved within 24 hours, not within the next 15 minutes. Decisions are written, not negotiated live. This is the remote engineering team setup decision most founders avoid until their first West Coast engineer quits.
Sample templates by team type
Different team shapes need different prompts. Here are three that work.
Small startup, 3-6 engineers, weekly cycles in Linear:
*What shipped yesterday?* (PR or ticket link required)
*What are you shipping today?* (Linear ticket IDs)
*Anything blocked?* (cross-post to #eng-blockers if yes)
*What do you need from the team?* (tag the specific person)
Mid-size team, 10-20 engineers, weekly sprints:
*Yesterday:* (3 bullets max, PR links)
*Today:* (3 bullets max, ticket IDs)
*Sprint progress:* on-track / at-risk / blocked
*Blockers:* (or "none")
*Heads-up:* (anything the team should know about: deploys, incidents, planned PTO)
Async-first team with contractors or Cadence engineers:
*Yesterday:* (artifact links)
*Today:* (ticket IDs)
*Blockers:* (or "none")
*Asks:* (named person)
*Rating yesterday's pair:* 1-5, optional comment
The rating line is how Cadence-style daily loops integrate with async standups. It adds 5 seconds and gives the manager a daily signal on engineer fit, preventing six-week mismatches that would have surfaced in a quarterly review.
The four things that kill async standups
Most async standups die in the first 60 days. The failure modes are predictable.
1. The manager replies to every post. This trains engineers to write standups for the manager, not for the team. Within two weeks, posts get longer, more performative, and less honest about blockers. The fix: managers react with emoji, don't reply. Reply only when something needs unblocking and nobody else has stepped up.
2. The deadline is fuzzy. "Post sometime in the morning" means posts trickle in from 8am to 2pm and the channel becomes unreadable. Fix: hard deadline at each engineer's local 10am. Geekbot enforces this automatically. If you're going manual, the deadline is the standup.
3. Nobody reads them. If the standup is write-only, engineers correctly intuit that the ritual is theater and stop investing in the format. Fix: the manager (or rotating "scribe") summarizes the channel into one weekly digest. Two paragraphs. Goes to the eng channel and the founder. Now everyone knows the standup gets read.
4. The format drifts. First week: yesterday/today/blockers/asks. Sixth week: "shipped a bunch of stuff, going to ship more, no blockers, no asks." Fix: pin the template to the channel. Quarterly retro question: "are our standups still useful?" If the answer is no two quarters running, change the format.
The single biggest predictor of async-standup success is whether engineers believe the channel gets read. Everything else (tooling, prompt, cadence) is downstream of that one belief.
When to add or skip a weekly sync
Async standups don't mean zero meetings. Most distributed teams need exactly one weekly sync: 30 minutes, agenda posted in advance, recorded for the engineers in the wrong timezone. It covers disagreements not converging in writing, sprint planning that needs real-time negotiation, and onboarding moments for new engineers in their first 30 days.
Skip it the rest of the time. If you find yourself scheduling a meeting to "discuss the standup updates," you've recreated the synchronous standup with extra steps.
Where Cadence fits
If you're booking an engineer through Cadence to slot into your existing async standup, the on-ramp is short. Every engineer on Cadence is AI-native by default, vetted on Cursor / Claude / Copilot fluency and written-communication discipline before they unlock bookings. They post their first standup in your format on day one. The 48-hour free trial includes two standup cycles, which is usually enough to see whether the engineer's written communication matches your team's bar.
Daily ratings are part of the booking flow. After every working day, you rate the engineer 1-5, which means the standup-rating line we showed earlier doubles as your Cadence feedback loop. If the rating drops below 3 for two days running, the matching engine surfaces a replacement automatically. Weekly billing means a bad fit costs you one week, not three months.
Tiers map cleanly to async-standup expectations: a Junior at $500/week posts standups but escalates more blockers; a Mid at $1,000/week resolves most blockers without escalation; a Senior at $1,500/week unblocks other engineers; a Lead at $2,000/week designs the standup format for the team.
If you're hiring permanent staff instead, the standup channel is one of the best evaluation surfaces during a paid trial week. A candidate's standup quality on day three tells you more about their remote fit than three hours of behavioral interviews. The performance review framework for remote engineers leans heavily on standup artifacts as primary evidence.
What to do this week
If you're starting from scratch:
- Pick the format (yesterday / today / blockers / asks). Pin it to a new
#eng-standupchannel. - Create a separate
#eng-blockerschannel. - Install Geekbot or set a manual 10am-local deadline.
- Run for two weeks. At the end, ask each engineer: "is this useful?" Adjust based on actual signal.
If you already run async standups and they feel like theater:
- Audit your last week of standups. Are blockers being resolved? Are asks being answered? Are PRs being linked?
- Add the rating line if you don't already have it.
- Move blockers to their own channel if you haven't.
- Have the manager stop replying to posts. Watch what changes.
If you need someone to run this for a team that doesn't have a manager yet, book a Senior or Lead Cadence engineer for one week to set up the format, the tooling, and the first two weeks of cadence. They'll hand off documentation by end of week.
Try Cadence: Find a vetted, AI-native engineer who can drop into your async standup on day one. 48-hour free trial. Weekly billing. Daily ratings catch fit problems in days, not quarters. Book in 2 minutes.
FAQ
How long should an async standup post be?
90 seconds to write, 15 seconds to read. Three to five short lines, each linking an artifact (PR, ticket, Loom). Posts longer than 200 words are a sign the engineer is writing for the manager, not the team.
Do async standups replace one-on-ones?
No. Standups handle daily coordination. One-on-ones handle career, feedback, and concerns that don't fit in a public channel. Run both. One-on-ones can be 30 minutes biweekly if the standup channel is healthy.
What if an engineer keeps skipping the standup?
Two missed standups is a conversation. Five is a pattern. The standup is the minimum viable signal that an engineer is engaged with the team; skipping it isn't a process problem, it's an early warning. If you're booking through Cadence, low rating + missed standups triggers an auto-match for a replacement within 48 hours.
Should I record async standups in a doc for posterity?
Slack search is good enough. Don't double-post. If a decision gets made in a standup thread, that decision belongs in Notion or Linear as a separate RFC or ticket, not as a snapshot of the standup itself. Standups are ephemeral by design.
Do async standups work for teams of 30+ engineers?
Yes, but split by squad or pod. One global standup channel collapses under 30 engineers because nobody reads it. Run a standup channel per squad of 4 to 8 engineers, plus a weekly cross-squad digest from each squad lead. The remote engineering career ladder explains how squad lead becomes a discrete rung at this scale.