Daily standups were supposed to improve coordination.
In practice, they often became a ritual that burns engineering time without giving much back. The old 15-minute promise sounds harmless, but in most real teams it becomes 30 minutes, 1 hour, or even 1 hour 30 minutes once the conversation starts and people wait their turn.
Strictly speaking, "daily" is the cadence and "standup" is the ceremony. In practice, people just use "daily" as shorthand for the meeting itself.
That is where the math gets ugly.
Why it used to make sense
Standups were useful when teams had poor visibility and weak async tooling. They helped surface blockers, expose dependencies, and give managers a quick snapshot of progress.
The problem is that many companies kept the ceremony long after the reason for it weakened.
Today, engineers already have:
- ticket boards
- pull request summaries
- commit history
- Slack updates
- AI-generated status recaps
If the status already exists in the system of record, forcing the whole team into a synchronous update ritual is usually redundant.
The real cost
The meeting itself is not the full cost. The expensive part is the context switching before and after it.
Let’s make the assumptions explicit:
- 5 workdays per week
- one daily standup every workday
- everyone attends
- the realistic range is 30 minutes to 1 hour 30 minutes per day
Cost per engineer
If the daily lasts 30 minutes:
- per week:
2.5 hours - per month:
10.8 hours - per year:
130 hours
If the daily lasts 1 hour 30 minutes:
- per week:
7.5 hours - per month:
32.5 hours - per year:
390 hours
A single engineer can lose 130 to 390 hours per year to a ritual that is supposed to save time.
Visualizing the waste
The charts make the hidden tax easier to see.
6-person startup
If the team has 6 people:
-
30 minutes per day =
780 hoursper year -
1 hour 30 minutes per day =
2,340 hoursper year
That is roughly 0.4 to 1.1 full-time work-years every year.
300-person company
If the company has 300 people:
-
30 minutes per day =
39,000 hoursper year -
1 hour 30 minutes per day =
117,000 hoursper year
That is roughly 18.8 to 56.3 full-time work-years every year.
What AI changed
AI did not remove the need for communication. It removed a lot of the manual work that used to justify the meeting.
Teams can now get:
- better summaries
- faster blocker detection
- cleaner async updates
- more visible project state
So the daily often becomes a low-value repetition of information people already have.
What should replace it
Not silence. Better communication.
For most teams, that means:
- async updates in Slack, Linear, Jira, or Notion
- clear ownership
- visible blockers
- short syncs only when a real decision or dependency needs conversation
If the team still needs a live meeting, it should be because it is solving something that cannot be solved async.
Reading yesterday’s task list is not that.
The rule I would use
- keep a daily only if it consistently removes blockers faster than async communication
- otherwise, replace it with written updates or a few syncs per week
- reserve live meetings for decisions, incidents, and real collaboration
Bottom line
Daily standups made sense when information was hard to see.
In the AI era, they are often just a recurring tax on engineering time.
If the meeting cannot prove its value, it should not survive by habit.
Top comments (6)
The context switching cost is the buried lead here. The meeting is 30 minutes but the real tax is the 20 minutes of ramp-up time you lose before and after. That’s what the math usually misses. Where I’d push back a little: standups aren’t dying, they’re just clarifying what they’re actually for. The useful ones aren’t status recaps - they’re the five minutes where someone surfaces a blocker that would have taken two days to route through Slack. AI can’t do that part yet.
I completely agree on the context switching cost. That's the real hidden killer I wanted to highlight in the post. The 30-minute calendar block is just the visible part. The 15-20 minutes of mental ramp-up before and after is what actually destroys deep work flow.
Where I'd gently push back is on the idea that "standups aren't dying, they're just clarifying their purpose."
I've seen the magic of those "five minutes to surface blockers" happen. But I've also seen it work even more effectively in an async way lately. A well-written Slack thread, an AI-generated summary of yesterday's PRs and blockers, plus a quick "raise hand" reaction from the team often surfaces the same blocker in under 90 seconds, without forcing 8-12 people to stop at the exact same time.
The blocker conversation is still 100% human and irreplaceable. But the ceremony around it (fixed time, video on, round-robin) is what is becoming optional in the AI era. We're already using AI to automatically flag risk patterns in tickets and PRs. The remaining human part doesn't need a daily synchronized meeting to happen. It just needs a fast, low-friction channel.
So yes, standups aren't dying. The low-value version is. The high-value version is evolving into something lighter, async-first, and AI-augmented.
Curious to know how your "swarm needs + clear commitments" format is working for your remote team. What has been working well for you?
The clarifying-purpose framing is where a lot of teams land - they say the standup is now for blockers only, but then it becomes a status meeting with a different name. The format survived but the outcome did not change. The async-first teams I have seen work well just eliminated the ceremony entirely and kept the escalation channel. Less about dying and more about defaulting to the wrong form.
I agree with the core point, for many teams, the traditional standup has become low-value status reporting. That said, for remote teams, regular touch points still matter. We’ve shifted our approach to focus on risk, swarm needs and clear commitments, which has made the conversation far more useful than a simple round-robin update.
I completely agree. In multiple companies where I’ve worked both as a software engineer and as a consultant, I’ve grown tired of explaining that useless bureaucratic processes don’t just cause performance loss; they also shift the team’s focus away from what truly matters: solving the customer’s problems and driving business value.
Software engineers need to stay focused on delivering solutions, not on constantly delaying real work because of empty process rituals. I often cite the daily standup as a classic example, but there are many other practices in our day-to-day that, in my opinion, should be challenged or removed when they fail to deliver genuine value.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.