The daily standup is the most cargo-culted ritual in modern software teams. Somewhere along the way we decided that standing in a circle, going around the room, and reciting yesterday-today-blockers was synonymous with being agile. In practice, most of the standups I have sat through over two decades of building regulated payments systems were a quiet tax on attention that produced very little of the coordination they promised.
I am not against synchronization. I run engineering for a fintech business where a missed dependency between the ledger team and the onboarding team can mean a compliance deadline slips. I care deeply about coordination. What I have learned is that the standup, as it is usually practiced, is a poor instrument for it. Below is why I think it fails so reliably, and the concrete set of practices I have replaced it with.
Standups Become Status Theater
The original intent of the standup was peer coordination: a team self-organizing by surfacing what each person needed from the others. What it almost always degrades into is status reporting aimed at the most senior person in the room. The moment a manager is present and listening, the round-robin stops being a conversation between engineers and becomes a performance for an audience of one. People describe their work in the most favorable framing available, blockers get softened into mild inconveniences, and nobody admits they spent yesterday lost in a refactor that went nowhere.
This is not a character flaw in your team. It is an entirely rational response to the incentives the format creates. If you are asked, in front of your peers and your boss, what you did yesterday, you will optimize for sounding productive. The information that actually matters for coordination, the messy uncertainty and the half-formed worries, is precisely the information the format punishes you for sharing. So it stays unsaid until it becomes a missed deadline.
The Hidden Cost of the Interruption
Engineering work is fragile in a way that most meeting schedulers do not appreciate. Getting into a state where you are holding a complex problem in your head takes time, and that state evaporates the instant you are pulled out of it. A standup scheduled at 10:30 does not cost fifteen minutes. It costs the productive morning hour before it, because nobody wants to start something deep that they will have to abandon, and it costs the reassembly time afterward.
When I have actually measured this, the real cost of a daily synchronous standup for a team of eight is closer to ninety engineer-minutes per day than to the fifteen on the calendar. Over a quarter that is a meaningful fraction of a person. The question I started asking was not whether the standup was worth fifteen minutes, but whether it was worth a headcount of coordination overhead. For most teams the honest answer is no.
A meeting that interrupts deep work has to clear a far higher bar than its nominal length suggests, because you are not paying for the meeting, you are paying for the focus it fragments on either side.
A Daily Cadence Rarely Matches the Work
The daily rhythm is arbitrary. It comes from a sports metaphor and a particular reading of early agile literature, not from any property of how software gets built. Most engineering tasks do not change state in interesting ways every twenty-four hours. A meaningful piece of work might sit in the same state for three days while someone wrestles with an edge case in payment reconciliation, and then change state four times in a single afternoon when the fix lands.
Forcing a daily report onto work that moves at an irregular pace generates noise. On the slow days people invent updates to have something to say, which trains everyone to tune out. On the fast days the important transitions happen between standups anyway and get communicated through other channels. The cadence that actually serves coordination is event-driven: you sync when something changes that another person needs to know about, not when the clock says it is 10:30.
Make the Default Asynchronous and Written
The single highest-leverage change I made was to move the routine status surface to writing. Each team keeps a running thread, in our case a dedicated channel, where people post when they have something worth posting: a task moved, a dependency emerged, a decision was made, a risk appeared. There is no fixed time and no round-robin. The expectation is contribution when there is signal, not attendance at a ritual.
Writing forces a clarity that speaking does not. When you have to type out what is blocking you, you frequently solve it in the act of describing it, which is the rubber-duck effect operating at the level of team process. Writing is also searchable, durable, and respectful of people in other time zones and on other schedules. Six months later, when an auditor asks why a particular control was changed, the reasoning is in the thread rather than lost in the air of a room.
- Post when state changes, not on a timer, so the signal-to-noise ratio stays high.
- Lead with the thing another person needs to act on, not a chronological recap of your day.
- Make blockers loud and specific, naming the person or team who can unblock you.
- Keep decisions and their rationale in the same thread so the record is self-explaining.
Surface Blockers Without an Audience
The part of the standup worth preserving is the blocker. Everything else is reporting; the blocker is the one moment where coordination actually has to happen. But the standup is a terrible place to raise a real one, because admitting you are stuck in front of the whole team carries a social cost, and because the people who can help are rarely the ones in the room with the authority to reprioritize.
I want blockers raised the moment they appear, routed directly to whoever can resolve them, and visible to a manager who can clear a path if escalation is needed. None of that benefits from waiting until tomorrow morning and announcing it to eight people, six of whom cannot help. We treat a blocker as an interrupt with a clear owner, not as an agenda item. The norm I push hardest is that raising a blocker early is a sign of good judgment, never of weakness, and I model it by raising my own in the same channel.
Keep One Real Synchronous Touchpoint
Going fully asynchronous would be a mistake, and I want to be clear that I am not arguing for that. Humans need to see each other think, to feel the texture of a disagreement, to build the trust that makes the written channel honest in the first place. What I have found is that you need far less synchronous time than the daily standup implies, and that the time you do keep should be used for things writing handles badly.
We run one substantive synchronous session a week per team. It is explicitly not a status meeting, because status now lives in writing and everyone has already read it. Instead it is for the things that genuinely need real-time bandwidth: working through an architectural fork, debating a tradeoff with the compliance team in the room, surfacing the vague unease that someone could not quite put into a written post. An hour spent well on those questions is worth more than five rushed fifteen-minute rounds.
Replace the Ritual With Visible Flow
A great deal of what the standup pretends to provide is simply visibility into the state of the work, and that is a problem better solved by making the work itself visible than by asking people to narrate it. If your board genuinely reflects reality, a manager can see at a glance what is in progress, what has stalled, and where the queue is backing up, without anyone reciting it aloud.
The discipline this requires is keeping the board honest, which is its own cultural project, but the payoff is large. When the state of the work is ambient and trustworthy, the conversation shifts from what is everyone doing to why is this item stuck and what does flow look like this week. We watch cycle time and work-in-progress far more closely than we watch attendance, because those numbers tell us where coordination is actually breaking down, which is exactly what the standup was supposed to do and almost never did.
When Standups Do Make Sense
I would be dishonest if I claimed the synchronous daily standup never has a place. There are conditions under which it earns its cost, and it is worth naming them so you can tell whether you are in one. A team that has just formed and has not yet built trust benefits from the forced daily contact. A team in the middle of a genuine incident, where the situation changes hour to hour, needs tight synchronous loops until it stabilizes. A team co-located in a single room where the standup is a thirty-second huddle rather than a calendar event pays almost nothing for it.
The failure mode is not the standup itself; it is running the standup on autopilot long after the conditions that justified it have passed. Most teams adopt it when they are new and anxious, then keep it for years out of habit, never noticing that the trust now exists, the work has settled into a rhythm, and the meeting has quietly become the status theater I described at the start. Treat the daily standup as a temporary scaffold, not a permanent fixture, and take it down when the building can stand on its own.
Conclusion
None of this is a rejection of coordination, which I value as much as anyone running a regulated engineering organization must. It is a rejection of the assumption that a daily synchronous recital is the only or even a good way to achieve it. Move routine status to writing where it is clearer and durable, raise blockers as interrupts routed to whoever can resolve them, keep one real synchronous hour a week for the conversations that deserve real-time bandwidth, and make the work itself visible enough that nobody has to narrate it. Then watch your cycle time rather than your attendance, and be willing to bring the standup back temporarily when a new team or a live incident genuinely calls for it. The goal was never the ritual; it was a team that knows what it needs from itself and gets it with the least friction possible.