And I say this as someone who has run hundreds of them.
Every morning, across thousands of companies, developers stop what they’re doing, join a call, stare at their cameras and take turns reciting three sentences nobody actually listens to.
“Yesterday I worked on the login feature. Today I’ll continue. No blockers.”
Fantastic. Revolutionary. Truly essential information.
I’ve been a Technical Lead for years. I’ve sat in standups that ran 45 minutes because someone decided it was also a good time to debug a production issue live. I’ve watched senior engineers mentally check out the second the first person starts talking. I’ve seen the same “no blockers” repeated six times in a row by people who absolutely had blockers. They just didn’t want to talk about them in front of everyone.
The daily standup is one of those practices that sounds good in theory, survives entirely on ritual and drains more energy than it creates. And yet it persists. Every day. At 9:30am. Whether the team needs it or not.
Where the Standup Actually Came From
Before we tear it apart, let’s be fair about where it started.
The standup was popularised by Scrum, one of the most widely adopted frameworks to come out of the Agile movement. The idea was genuinely sensible. Instead of long, formal status meetings that consumed half the working day, teams would gather briefly, on their feet and answer three questions. What did I do yesterday? What am I doing today? What is blocking me?
Fifteen minutes max. Then back to work.
In that original context, it made sense. Small teams, high trust, everyone working on related pieces of a shared problem. The standup kept people connected without consuming their day.
But that’s not what most standups look like today.
Today the standup has been copied from those small, co-located Agile teams and pasted onto every type of team imaginable. Large teams. Distributed teams. Teams working on completely separate features with no real dependency between them. Teams where half the members are in different time zones. Teams where the “daily” standup happens three times a week because nobody wanted to admit it should just stop.
The format survived. The context it was designed for didn’t come with it.
Let’s Talk About What Actually Happens
The original purpose was simple: keep the team aligned, surface blockers fast and avoid long meetings. Fifteen minutes, standing up, done.
What it became is a performance.
People spend time preparing what to say instead of actually working. They word things carefully to avoid follow-up questions. They wait politely through updates that have nothing to do with them. They mentally calculate how long they have to stay engaged before it’s socially acceptable to look at their screen again.
An Atlassian study found that the average employee attends 62 meetings per month and considers more than half of them a waste of time. Standups, when run badly, are the most consistent offenders. Not because they’re long but because they happen every single day. Five days a week. Fifty weeks a year.
That’s 260 standups a year. At 15 minutes each, that’s 65 hours. For a team of 8, that’s 520 hours of collective time, every year, spent on a meeting that most people would describe as “fine” at best.
And what do most teams actually walk away with? Nothing they couldn’t have gotten from a Slack message sent the night before.
The “No Blockers” Lie
Here’s something I’ve noticed across every team I’ve been part of or managed. The more dysfunctional a team’s communication, the more confident people sound in standups.
“No blockers!” from someone who has been stuck on the same ticket for three days.
“On track!” from someone who quietly hasn’t touched their task since Monday.
“Just waiting on a review” from someone who submitted a PR two weeks ago and hasn’t followed up once.
The standup doesn’t surface blockers. It creates a theatre where admitting problems feels uncomfortable because you’re doing it in front of your entire team including your manager. There’s social pressure to appear productive, to seem like you have things under control and to avoid the follow-up questions that come when you say something went wrong.
So people stay quiet. And they stay stuck.
Real blockers get raised in DMs, in side conversations and in 1-on-1s. Anywhere except the place specifically designed to surface them.
I once managed a developer who gave the exact same standup update for nine consecutive working days. “Working on the payment module, no blockers.” On day ten, I asked him directly. Turns out he had been completely blocked by a third-party API issue since day two but didn’t want to say so because he thought he should have been able to figure it out himself.
Nine days. Lost. Because the standup created a culture of performance instead of honesty.
The Meeting That Became a Report
Here’s the other thing that happens to standups over time. They gradually stop being for the team and start being for management.
This shift is subtle but devastating. When the standup is genuinely for the team, the conversation is horizontal. Engineers talk to each other, flag real dependencies and help each other unblock. When it becomes a report to management, the conversation becomes vertical. Everyone faces the manager and tells them what they want to hear.
You can tell which version you’re in by a simple test. When was the last time one engineer’s standup update directly changed what another engineer did that day? If you can’t remember, your standup is a reporting mechanism wearing an Agile hat.
Reporting to your manager daily is not inherently wrong. But it should be called what it is and designed accordingly. It should not consume the whole team’s morning to achieve what a written update would do more efficiently.
So What Actually Works?
I’m not saying kill all communication. I’m saying the format is broken for most teams running it.
Async standups via tools like Geekbot, Slack or even a simple shared doc let people update when it’s actually convenient, not when someone else decided 9:30am was the right time for everyone. Written updates force clarity. You can’t ramble in a text field the same way you can on a call. And crucially, people can write their update when they actually know what they’re doing that day, not at the moment they’ve just switched on their laptop.
By 2026, this has gone further. A new category of tools (Stepsize, Steady and others) auto-generates standup updates by pulling directly from your GitHub commits, Jira activity and pull request history. The developer does nothing. The update writes itself from what they actually did. That alone should tell you something about what most written standup updates were always supposed to contain but didn’t.
Written async updates also create a record. You can scroll back and see exactly what someone said they’d do and what actually happened. That’s more useful than trying to remember what was said in yesterday’s call.
Reserve actual synchronous time for things that genuinely need live discussion. Complicated technical decisions that require back and forth. Blockers that need two or three specific people to solve together. Team retrospectives. Planning sessions. Not daily status updates.
When I moved my team to async standups on Monday, Wednesday and Friday with one live sync on Friday afternoon, the complaints stopped within two weeks. People had their mornings back. More importantly, the quality of the written updates was better than what we were getting in the live calls because people actually thought before they typed.
The Control Problem Nobody Wants to Name
Standups persist not primarily because they work but because they make managers feel informed and present.
This is the honest version of the conversation that almost never happens. When you can’t physically see people working, especially in remote or hybrid setups, watching them appear on camera for 30 seconds and speak about their work creates the feeling of oversight. It’s not the same as actual oversight but it feels like it.
This is a management problem, not a team problem. And solving it by making eight engineers stop work twice a day to perform productivity is a poor trade.
The best technical managers I’ve worked with didn’t need daily standups to know how their teams were doing. They knew because they reviewed code, read pull requests, had real 1-on-1s and created an environment where people told them things. The standup was a backup mechanism they could drop without losing any real visibility.
The managers who cling hardest to daily standups are usually the ones with the least visibility into what their team is actually doing. The meeting makes them feel like they’re in control of something they’re not really tracking.
When Standups Are Actually Worth It
To be balanced: there are situations where a daily standup genuinely earns its time.
A small team of three to five people working on an urgent, tightly coupled piece of work where daily coordination prevents duplication and catches integration conflicts fast. A team in a sprint where things are genuinely moving quickly and direction can shift day to day. A team that has just formed and needs to build shared understanding before they can work more independently.
In those specific situations, the standup serves its original purpose. It’s short, everyone benefits from being there and the conversation is actually between the team members rather than directed at a screen.
The problem is that teams keep running standups in the same format long after those conditions have disappeared. The urgent project ended. The team grew to twelve people. Half the work is no longer interdependent. The standup format never got updated to reflect the new reality.
The Question You Should Ask Your Team
Try this. In your next retrospective, ask everyone to write down honestly whether they think the daily standup is worth the time it costs. Anonymous responses.
I’ve done this with three different teams. The results were consistent. The majority said they would prefer something less frequent or async. A small number said it was fine. Nobody said it was one of the most valuable parts of their week.
That result alone should tell you something.
The standup isn’t broken everywhere. But in most teams running it today, it is a habit that outlasted its usefulness. Keeping it because “that’s what Agile teams do” is not a reason. It’s just inertia dressed up as process.
If your standup disappeared tomorrow, would your team fall apart or would they quietly breathe a sigh of relief?
That answer tells you everything you need to know.
I’m not anti-meetings. I’m anti-meetings that could have been a message. If your daily standup is genuinely useful, keep it. But if you’re running one out of habit because it’s what the framework said to do, it might be worth asking whether the ritual is serving the team or just surviving it.