Why Async Standups Don't Work (And What Distributed Teams Actually Need)

Async standups do not work for distributed teams because they take the worst part of a standup (backward-looking status questions) and remove the only part that made it useful (real-time interaction). The result is a daily ritual where engineers answer three questions nobody reads, posted to a channel that nobody checks, producing a record that nobody can query.

This is not a controversial observation among teams that have tried it. Most teams adopt an async standup bot (Geekbot, Standuply, or a Slack workflow), see engagement drop within 6 weeks, and quietly stop enforcing it. The standup format was not designed to work asynchronously. Forcing it to does not fix the coordination problem. It just moves the problem to a different channel.

Why Async Standups Fail

The daily standup was invented for co-located Scrum teams who were in the same room at the same time. Its format, the three questions, assumes real-time interaction: I say what I am doing, you hear it, you realize it affects your work, we resolve it on the spot. The resolution is the value. Not the report.

When you make the standup async, you keep the reporting but lose the resolution. An engineer types "blocked on API credentials" into a bot at 5pm London time. The person who can unblock them is in San Francisco and does not read the update until 9am Pacific, 16 hours later. By then, the message is buried under 40 other updates in the standup channel. No one acts on it. The blocker persists for another full day.

The failure has three specific causes:

The questions are wrong for async. "What did you do yesterday?" generates a retrospective summary. In a synchronous standup, this summary triggers discussion: someone hears the update and asks a follow-up. In async, the summary just sits there. No one responds to it because there is no expectation of response. It is a report filed to a channel.

The output is not queryable. Standup updates go to a Slack channel or a bot dashboard. They are text posts in a feed. When an engineer in another timezone wants to know the current state of a specific project, they cannot query the standup updates. They scroll. Scrolling is not coordination.

The incentive structure inverts. In a live standup, brevity is valued because you are holding 8 people's attention. In async, brevity means your update gets ignored. But length does not help either, because no one reads long updates in a feed they are already ignoring. There is no format that makes the async standup update consistently useful, because the format was not designed for async consumption.

The Daily Standup's Structural Problems

Even the synchronous daily standup has well-documented problems for distributed engineering teams:

Timezone taxation. Someone always gets the bad time slot. In a team spanning London and San Francisco, the standup is either at 6am Pacific or 5pm GMT. Both are unsustainable. Senior engineers leave companies over this.

Information decay. By the time the standup happens, the updates are hours old. A blocker raised at the standup was actually encountered at 2pm the previous day. The standup did not surface it. It delayed it.

No durable record. What is said in a standup evaporates. The decisions, the blocker resolutions, the context about who is doing what, all of it lives in the memories of the people who attended. Miss the meeting and you miss the information.

Status theater. Engineers learn to craft updates that sound productive without revealing much. "Continuing work on the migration" becomes the default. The standup becomes a ritual of reassurance rather than a coordination mechanism.

Making the standup async does not fix any of these problems. It merely shifts the medium from spoken words to typed text while preserving every structural flaw.

Async Standup vs. Async Governance

The core difference between an async standup and an async governance system is the direction of the information flow.

An async standup asks: "What did you do?" The information flows backward, from the engineer to a report about the past. The audience is a manager or a team channel. The purpose is visibility.

An async governance system asks: "What does the next person need to know?" The information flows forward, from the outgoing shift to the incoming one. The audience is the engineer who will pick up the work. The purpose is continuity.

This is not a semantic distinction. It changes what information is captured, how it is structured, and whether anyone actually uses it. A backward-looking status report does not help an engineer in San Francisco start their morning productively. A forward-looking handoff does.

Governance also implies structure and queryability. Standup updates are freeform text. Governance records are structured: what shipped, what is blocked, who owns what next, when you are back. The structure makes the records queryable. "What is blocking the payments migration?" can be answered from the governance record. It cannot be answered by scrolling through standup updates.

What Distributed Teams Actually Need

If the async standup is the wrong tool, what is the right one? Distributed teams need three things that the standup format, sync or async, does not provide:

A shift handoff, not a status update. The daily artifact should be designed for the person who comes online next, not for a manager reviewing the team's output. This changes the content from "what I did" to "what you need to know." It is a small reframing with a large practical difference.

Queryable records, not a feed. The output of the daily practice needs to be something an engineer can query with a specific question, not something they scroll through hoping to find relevant information. "What is the status of the checkout flow?" should produce a sourced answer, not a direction to check channel history.

Decision capture, not just status. The daily standup captures what people are doing but not why. The decisions that shaped the work, the trade-offs that were made, the alternatives that were rejected, all of this context is lost because the standup format does not capture it. A governance system captures decisions alongside status, creating a record that is useful for weeks, not just for the next morning.

The teams that have successfully moved past the standup (sync or async) have built some version of this system. The specific tool varies. The practice is consistent: structured, forward-looking, queryable handoffs that replace the backward-looking status ritual.

Common Questions

We just set up Geekbot. Should we rip it out?

Not immediately. Run it alongside a structured handoff practice for two weeks. Let the team experience the difference between answering "what did you do?" and writing "what does the next shift need?" Most teams naturally migrate to the handoff format because it is more useful on the receiving end.

Can we fix the async standup by changing the questions?

Changing the questions helps but does not fix the structural problems. You can replace "what did you do yesterday?" with "what does the next shift need to know?" but you still have a feed-based output format, no queryability, and no decision capture. The questions are the easiest thing to change. The harder and more important changes are structure, format, and queryability.

Why do async standups work for some teams?

They work adequately for single-timezone teams where the standup is a lightweight check-in, not a coordination mechanism. If everyone is online at the same time and can resolve issues in real time, the async standup is just a convenient way to share status without a meeting. It fails specifically for timezone-split teams where the async standup needs to serve as the primary coordination mechanism.

Is "async governance" just a buzzword for better documentation?

No. Documentation is static and backward-looking. Governance is dynamic and forward-looking. Documentation tells you how the system works. Governance tells you what is happening right now, who owns what, and what was decided today. They complement each other but solve different problems.