The daily standup is one of the most contested rituals in software development. Ask ten engineering managers and you’ll get ten strong opinions — some swearing by them, others convinced they’re pure overhead. When distributed and hybrid teams became the norm, we started asking a different question: what is a standup actually for?
The answer shaped how we approach async communication in ways that go beyond just moving a meeting to a message thread.
What a Standup Is Actually Trying to Do
The official purpose of a daily standup is to surface blockers and coordinate work. The unofficial purpose — equally important — is social cohesion. Seeing your teammates, even briefly, builds the low-level connective tissue that makes collaboration feel human.
Async standups handle the first purpose well. They often handle the second poorly. That distinction is worth holding clearly, because conflating them leads teams to either abandon async standup attempts (“it doesn’t replace the real thing”) or go fully async and then wonder why the team feels distant.
The Mechanics That Make It Work
Async standups only work if the format creates genuine signal rather than compliance theater. A few patterns that make a difference:
- Keep the prompt tight. Three questions: what did you complete, what are you working on today, what’s blocking you. Any looser and updates become status reports no one reads.
- Set a clear submission window. Updates posted within the first ninety minutes of the workday (adjusted for time zones) ensure people are synced before deep work starts, not catching up at 4pm.
- Require a response to blockers. If someone posts a blocker, the team lead or a relevant teammate should respond within two hours. If blockers consistently go unacknowledged, the format loses credibility fast.
- Normalize brevity. One sentence per prompt is fine. The culture should reward useful information density, not thoroughness for its own sake.
What It Changed Beyond the Standup
The more interesting shift was how async standups changed communication norms more broadly. Once teams built the habit of writing concise status updates, they got better at written communication generally — more precise GitHub comments, better ticket descriptions, clearer Slack messages. The standup became a daily exercise in the skill of communicating clearly in text.
We also found that async updates created a searchable record. When a stakeholder asks why a feature took longer than expected, the daily update history tells the story: the blocker that appeared on day three, the scope change on day seven. That record has genuine value that a spoken standup produces nothing of.
When to Keep Synchronous Standups
Async works well for steady-state work. It works less well for crisis situations, complex cross-team dependencies, or onboarding new team members who need more real-time orientation. Teams navigating an incident or a hard sprint crunch often benefit from a brief sync-first standup during that period, then returning to async when things stabilize.
The real lesson isn’t that async is better than sync. It’s that teams are better served by intentional communication design than by inherited defaults. Whether the standup is synchronous or async, it should be doing something specific — and the team should be able to articulate what that is.
If your current standup can’t answer that question, that’s where to start.