The daily stand-up has a reputation problem. People hate it. Every “how to improve your stand-ups” article gets comments from engineers saying they’d rather just read a Slack message. Managers love it because they think they’re getting status updates. Nobody actually likes the thing that’s supposed to synchronize the team.
The reason is simple: most stand-ups have mutated into exactly what they were designed not to be.
What a Stand-Up Is Supposed to Be
Fifteen minutes. Everyone in the room (or video call). Three things: what did I finish yesterday, what am I working on today, is anything blocking me. That’s it. The purpose is synchronization. The team knows what’s happening. Blockers surface so someone can help. It’s quick. You’re out.
It’s not a status meeting. You’re not reporting to a manager. You’re not giving a performance update. You’re not justifying your time. You’re not going into depth on anything. You’re not solving problems. You’re just establishing: here’s the work, here’s the blockers, here’s the synchronization point.
The beauty of this design is that it’s low-stakes and fast. You can be honest without worrying that you’re sounding unproductive. “I blocked on the database schema yesterday, still working on that, needs a review from the architect.” That’s useful information. If the standup was a status report, you’d phrase it differently: “Made good progress on the database work yesterday, continuing today, schema design is being reviewed.” Same facts, but one is honest and one is performance.
How They Drift
The first way is the obvious one: the manager joins. Now you’re not synchronizing. You’re reporting. Everyone’s language changes. “I completed five points yesterday and I’m picking up the next story” sounds better than “I debugged for three hours and didn’t figure out why the cache is failing.” Suddenly you’re curating information instead of being straight about what’s happening.
The second way is deeper. The team starts treating it as a management tool instead of a synchronization tool. Someone raises a blocker and the manager says, “Have you tried X?” or worse, starts questioning the approach. Now blockers are expensive to surface. You need a solution ready before you mention the problem. So people stop naming blockers. The stand-up becomes a list of accomplishments instead of a place where problems surface.
The third way is that the stand-up stretches. It was supposed to be fifteen minutes. But someone gives a detailed update. Someone else asks a question. Someone solves a blocker live in the standup because they happened to have the answer. Before you know it, you’re thirty minutes in. Now stand-ups feel expensive. People dread them. They start tuning out.
And then there’s the remote version, which is its own special kind of broken.
The Remote Problem
In-person stand-ups are naturally bounded. You’re all in a room. Fifteen minutes is fifteen minutes. Someone notices when it’s been twenty and wraps up. There’s a social pressure to be brief.
Remote stand-ups don’t have that boundary. People call in at different times. Someone’s video isn’t working. Someone’s typing in Slack instead of speaking. The whole thing becomes slack and weird. Some teams have responded by going async—everyone posts their status in a Slack thread. It’s efficient until it isn’t: nobody reads the thread, blockers don’t surface, you’ve got a document of status updates and no synchronization.
The teams that do remote stand-ups well have built in the discipline that physical proximity used to provide. They have a start time and an end time. Everyone is present or async only, not half-present. If someone is remote, everyone is on video—no “person in the room and person on the call” dynamic. The facilitator—usually the Scrum Master—actually keeps it short. They interrupt if someone goes too long. “Great, so you’re blocked on the schema review, got it, next person.”
What Actually Works
In-person: Meet at the same time and place daily. Fifteen minutes, hard stop. No managers. The team runs it. Someone’s blocking, someone else unmutes and offers to help after standup. You’re out in fifteen minutes, everyone knows what’s moving.
Fully remote: Synchronous stand-up via video at the same time daily. Fifteen minutes. Everyone on video. Same format: what did I do, what am I doing, what’s blocking me. Someone’s blocking, you note it and follow up after standup. Hard stop at fifteen minutes. The discipline is all you have to keep it bounded.
Hybrid (or async): This is where it gets tricky. If you have people in different time zones or on genuinely different schedules, synchronous doesn’t work. You can do async. Everyone posts to Slack by 9 AM. Everyone reads everyone else’s status by 9:15 AM. If there’s a blocker, you tag the person and follow up.
This works if your team actually reads the thread and responds quickly to blockers. Most teams that try this end up with everyone posting a three-minute video that nobody watches, which defeats the purpose entirely.
A better hybrid approach: do a short synchronous standup once a week, where people can ask clarifying questions. Do async status posts the rest of the time. You get the synchronization of a real standup at least once a week, and people can handle their own schedule the rest of the time.
The Facilitator Matters
A good standup has someone who actually runs it. Ideally, this rotates—it’s not the same person every time. But when it’s happening, that person’s job is to keep it moving. If someone goes into depth, gently interrupt: “Got it, you’re working on X and blocked on Y. Noted. Next?” If the manager asks a clarifying question, it’s fine. If the manager starts asking “why did you structure it that way,” you’re drifting into a meeting that isn’t a standup.
The facilitator also owns following up on blockers. If someone says they’re blocked, the facilitator doesn’t solve it live. They note it and own making sure the blocker gets unblocked—either by pairing people up after standup, or by routing it to whoever needs to know.
The Real Problem
Here’s what actually kills standups: they become a ritual instead of a tool. The team is doing standups because “that’s what Agile teams do,” not because standups are useful. So the team optimizes for going through the motions instead of being honest.
If your standups are fifteen minutes and useful, keep doing them. If they’re thirty minutes and nobody’s attention is in the room, maybe you’ve drifted. If they’re happening but blockers aren’t actually getting unblocked, maybe the standup is the wrong tool.
Some teams skip daily standups and do twice-weekly syncs instead. Some teams do async status with a weekly sync. Some teams have found that their standups work better at the end of the day instead of the beginning. The format matters way less than whether the team is actually synchronized and blockers are actually surfacing.
The standup was designed to be fast, low-stakes, and honest. The moment it becomes expensive, high-stakes, or a performance, it’s broken. Your job—whether you’re running them or in them—is to keep them in that original state.