Quick answer
If you are running a distributed engineering team with more than one timezone and more than four people, kill the daily standup meeting. Replace it with a written daily post in Slack or Linear, due by 11 AM local. Keep one short synchronous touchpoint each week — typically a 30-minute team sync — and reserve real-time calls for incidents, decisions, and pairing. That is the entire playbook.
There are a few cases where the daily meeting still earns its cost. New teams in their first two weeks. Incident mode. Cross-functional pairs that need real-time alignment. Any timezone with fewer than two people. We will get to those.
| Dimension | Sync standup | Async standup |
|---|---|---|
| Cycle time impact | Neutral to negative | Measurably positive |
| Context-switch cost | ~23 min per person, per day | Near zero (read on your own break) |
| Fairness across zones | One zone always loses | Equal — everyone posts on their schedule |
| Blocker resolution speed | ~15 hours (one cycle) | ~2 hours (in-channel) |
| Written record | None unless someone takes notes | Searchable by default |
| Junior visibility | Crowded out by louder voices | Equal posting surface for everyone |
If you want the full picture — including the math, the template, and the cases where the daily meeting still earns its cost — keep reading.
What a daily standup actually costs
Six engineers. Fifteen minutes a day. Five working days a week. Forty-eight working weeks a year. That is 360 person-hours annually spent inside the standup meeting itself. At a $150,000 fully-loaded salary, each engineer's hour is worth roughly $100. Six engineers in a 15-minute meeting costs you $150 every working day. Multiply by 240 working days and you have $36,000 a year in salary time — before you count the meeting's second-order cost, which is larger than the first.
The second-order cost is the context-switch tax. Paul Graham's essay on the maker's schedule names the mechanism: knowledge work runs on long, uninterrupted blocks, and any meeting placed inside one shatters the block on either side, not just for its own duration. Gloria Mark's widely-cited research at UC Irvine puts the typical recovery time from an interruption at about 23 minutes. Cal Newport, in Deep Work, makes the same point in book form. Tom DeMarco was writing about it in Peopleware in the eighties.
Apply that to your standup. Six engineers, each losing 23 minutes of focus on either side of the meeting, is roughly 4.6 person-hours of unrecoverable productive time per day. That is another $460 a day, $110,000 a year, in lost effective output. The standup's real annual cost to a six-person engineering team is north of $145,000.
The painful version of this calculation: schedule the standup at 9:30 AM and you have killed the first deep-work block of every engineer's morning. Schedule it at 2:00 PM and you have killed the afternoon block. There is no time of day where a 15-minute group meeting is free, because there is no time of day where the surrounding 90 minutes are worthless.
Run the actual number for your own team in our meeting cost calculator. Punch in your headcount, salaries, and meeting cadence. The number is usually worse than people guess.
The replacement ritual
The replacement is a written daily post, due by 11 AM in each person's local time. Three sections: what you did yesterday, what you are doing today, and what is blocking you. Posted to a shared channel — Slack, Discord, or threaded under your team's Linear cycle. Read by everyone, on their own schedule, with no expectation of immediate response unless the post calls out a blocker.
The 11 AM cutoff matters more than it sounds. Earlier than that and you force everyone to break their morning focus to file paperwork. Later than that and your Asia-Pacific colleagues will not see anyone else's update until their next working day. 11 AM local hits the natural break before lunch in every zone and gives the post-lunch reader something to land on. GitLab's public handbook, which is the canonical async-first reference, has been running variants of this cadence for over a decade.
One ritual that is worth adding: each post ends with a one-line "focus for today", naming the single thing you are trying to ship by end of day. It forces you to commit publicly to one outcome instead of listing five hopes. The act of writing it improves the day before anyone else reads the post. Doist, in their writing on async-first culture, calls this a "north star sentence" for each working day. They are right.
Keep one synchronous touchpoint per week. A 30-minute team sync on Tuesday or Wednesday, where you cover anything that genuinely needs real-time discussion: decisions, design tradeoffs, retros, demos. Everything else lives in the written stream. That weekly call is the cheapest meeting on your calendar because it has a real reason to exist — which is the test every recurring meeting should pass.
The template
Copy this into your team's channel pinned message on day one. It is short on purpose. The longer the template, the less likely people are to actually post it.
**Daily update — [Your name] — [Date]** *Yesterday* - Shipped X - Reviewed PR Y - Investigated Z *Today* - Finishing X follow-up - Pairing with @colleague on Y at 2 PM - Writing the design doc for Z *Blocked* - Need review on PR #123 (cc @reviewer) - Waiting on staging access from @ops *Focus for today* - Ship the X migration to staging
Three formatting notes that materially improve readability across a 20-person channel. First, bullet points only — no paragraphs. Async readers scan; they do not read. Second, tag people in the blocked section with their actual handle so they get a notification. Third, the focus line goes at the bottom, not the top, because the act of writing yesterday and today should clarify what the focus actually is.
If your team uses Linear, the equivalent ritual is to post the same content as a comment on your current cycle or roadmap item. The advantage is threaded visibility to whoever cares about that workstream. The disadvantage is the post is buried unless you also cross-link from a channel. Most teams that try Linear-only end up with a channel mirror anyway. Start with the channel.
When the meeting still wins
The async ritual is the default. The synchronous standup is the exception. Here are the exceptions, listed in order of how often they actually apply.
First two weeks of any new team. When a team is forming, the cost of low-bandwidth communication is much higher than the cost of meeting time. Run a daily 15-minute call until everyone has worked together long enough to trust each other's written shorthand. Two weeks is usually enough. Four weeks if there is a new manager or a major composition change. Beyond that, you are using the meeting as a crutch.
Incident mode. When something is on fire, async is the wrong tool. Open a war room. Stay on it. The async ritual pauses for the duration of the incident and resumes the next working day. Write the post-mortem async, review it in a single meeting, log the actions in the issue tracker.
Cross-functional pairs needing real-time alignment. Two people working on a tightly-coupled handoff — for example, a backend engineer and a frontend engineer building a feature against a shared contract — benefit from a short daily sync, just the two of them. That is a pairing slot, not a team standup. It does not need the other four engineers in it.
Timezones with fewer than two people. A team where one person sits in Sydney and the other five sit in Berlin has a structural problem the async ritual cannot fix. The lone Sydney engineer will never get a same-day blocker response from Europe and will feel isolated. Either add a second person to that zone, or schedule a weekly one-on-one with the manager that explicitly compensates for the gap. The standup is not the right lever here either way.
Teams with junior-heavy composition. If more than half your team is in their first two years of engineering, the async ritual demands writing skills they may not yet have. Keep the daily call until the team has matured. Replace it gradually — three days a week sync, two days written; then two days sync, three written; then one. The transition takes a quarter, not a sprint.
Common objections and the answer
"I'm a manager and I need visibility into what my team is doing." You will have more visibility, not less. Written posts are searchable, durable, and comparable across weeks. The standup gave you fifteen minutes of self-edited verbal updates that you forgot by lunch. The async stream gives you a written record you can review on Friday afternoon and a leading indicator — post completion rate — for who is engaged. The visibility argument is the strongest argument for async, not against it.
"Junior engineers need the face time." They need face time with their mentor, not with five other people they will exchange one sentence with. Replace the standup with a recurring 30-minute weekly one-on-one and a 20-minute weekly pairing slot. That is more focused attention than the standup provided. The face time argument is real; the standup is just a bad implementation of it.
"Different timezones make async unfair." The opposite is true. Synchronous standups force one zone to wake up early or stay late. The async ritual lets everyone post at 11 AM their local time, which is the same effective cost everywhere. The team in Sydney is not penalised for being in Sydney. The team in San Francisco is not penalised for being in San Francisco. Look at the fairness table at the top of this guide.
"What about team cohesion? Standups build culture." Standups do not build culture, they perform it. Culture comes from shared work, shared wins, and shared losses. Replace the standup with a weekly 30-minute team sync that has an actual purpose — a demo, a retro, a planning slot — and a monthly team social. That is more cohesion than a daily 15-minute status round-robin produces.
"My team's posts will become low-effort copy-paste." Some will. That is information. A consistently low-effort post means the engineer is disengaged, blocked, or running on fumes — all things you want to know. Treat the post quality as a leading indicator and act on it. The standup hid the same signal because verbal updates are even easier to phone in.
Tooling
The tooling stack for an async-first team is small. Most of it you probably already have. Below is what we recommend and why.
The channel. Slack with a daily reminder bot, or Linear with threaded cycle updates. Start with Slack — every team has it, the friction is zero, and the search is good enough. Move to Linear if you find your team referencing posts inside issue threads more than inside channel scrollback.
The weekly sync. A single 30-minute meeting with a written agenda, run on the same day every week. Use our meeting scheduler to find the overlap window where the most teammates are inside business hours. Lock that slot for the rest of the year. Do not let it drift.
The meeting budget. Run a quarterly audit on every recurring meeting your team owns. For each one, run the cost through our meeting cost calculator — headcount, average salary, frequency, duration. Anything over $20,000 a year needs a written justification that survives a five-minute conversation with a sceptic. Anything that does not gets cut.
The async comms baseline. If you are new to running an async-first team, our async comms guide covers the wider posture: response-time expectations, when to write versus when to call, and the document-first decision-making pattern that makes the rest of this playbook possible.
The focus block. Once the standup is gone, the next bottleneck is calendar fragmentation. The pomodoro timer is useful for individual contributors who want to enforce their own focus blocks. For team-level calendar defence, an AI calendar assistant is worth trying.
Metrics to track once you switch
Do not switch and then look away. The async ritual is a behaviour change, and behaviour changes regress unless you measure. Track three metrics for the first quarter, then review.
Cycle time. Median time from PR opened to PR merged. This is the cleanest single number for engineering throughput, and it is the one that should move within two to four weeks of the switch. If it does not, your team is not actually reclaiming the focus blocks — they are filling them with something else. Find out what.
PR review latency. Median time from review requested to first substantive response. The async standup makes blockers public, which should pull this number down. If it goes up, your team has stopped reading each other's posts. That is fixable with a pinned channel and a manager reminder; do it before three weeks pass.
Async post completion rate. Percentage of working days each engineer posted by 11 AM local. Aim for 90% as a team average over a quarter, with no individual below 70%. Below that and either the ritual is the wrong fit for your team, or you have a personnel issue masquerading as a process issue. The metric tells you which by surfacing the pattern. Do not name and shame in public; use the data in one-on-ones.
A note on what not to track. Do not track post length. Do not track post sentiment. Do not run any kind of automated quality scoring on the posts themselves. The ritual works because it is low-stakes; the moment you instrument the content, you turn it into performance theatre and the underlying signal evaporates.