How to Make Standups More Effective (by Fixing What They Actually Measure)
Standups optimise for accountability, not coordination. Here's how to fix the format, the questions, and the information architecture underneath.
By Ellis Keane · 2026-03-19
The standup was invented to solve a coordination problem, and somewhere along the way it became a performance. Fifteen people in a virtual room, each delivering a rehearsed monologue about what they did yesterday, what they're doing today, and whether anything is blocking them. The answers are pre-scripted, the listeners are on mute, and the meeting ends with everyone knowing roughly what they already knew.
"The standup was invented to solve a coordination problem, and somewhere along the way it became a performance." – Ellis Keane
The weird thing isn't that standups are bad – it's that everyone knows they're bad, and we keep doing them anyway, because the alternative (no standup at all) feels like giving up on coordination entirely. That's a false binary, and if you're trying to figure out how to make standups more effective, it's worth pulling apart.
The three questions are a red herring
Every standup guide on the internet tells you to ask three questions: what did you do yesterday, what are you doing today, and are you blocked? The format is so universal – baked into Jira workflows, Slack bots, and every manager's playbook since the Agile Manifesto – that most teams never question whether it's the right frame.
Here's the problem: those three questions optimise for accountability, not coordination. "What did you do yesterday?" is a backward-looking status report. "What are you doing today?" is a forward-looking one. Neither surfaces the information that actually matters for coordination – which is where work is about to collide, where context is missing, and who needs to talk to whom after the meeting.
(And "are you blocked?" is the worst of the three, because blocks rarely announce themselves that cleanly. Last month one of our engineers spent two days building against an API endpoint that had been deprecated in a PR merged the previous morning. He wasn't "blocked" – he just didn't know the ground had shifted underneath him.)
What effective standups actually measure
If you strip away the ritual, a standup has one job: surface information that would otherwise stay trapped in someone's head until it caused a problem. Everything else – the status reporting, the round-robin format, the fifteen-minute timebox – is implementation detail that may or may not serve that goal.
The teams I've seen make standups more effective tend to organise around a different set of questions, even if they don't frame them this way explicitly:
- What changed since yesterday that someone else needs to know about? Not what you did – what changed. A PR merged that affects someone else's work. A design direction shifted in a Figma comment thread. A dependency turned out to be broken. Changes that ripple outward.
- Where is work about to overlap or conflict? Two people touching the same API endpoint. A design change that invalidates an engineer's current implementation. The kind of collision that costs half a day if you catch it now and three days if you catch it Friday.
- What's the most important thing you don't know right now? Not "are you blocked?" but a genuine question about uncertainty. "I'm not sure if the auth migration affects my feature branch" is much more useful than "no blockers" – it invites someone who does know to speak up.
The difference is subtle but structural: the first set of questions measures activity, the second measures risk. Activity is nice to know. Risk is need to know.
The round-robin problem
Most standups go around the room – or around the Zoom grid – and each person talks for 60-90 seconds. This format optimises for fairness (everyone gets equal time) rather than relevance (the most important information gets the most time).
In practice, this means an engineer who discovered a critical API incompatibility yesterday gets the same 60 seconds as someone who spent the day writing tests for a stable module. The API incompatibility might affect three other people's work this week, and it needs a five-minute conversation that the standup format actively prevents because we've got eleven more people to get through.
(What usually happens is the engineering manager facilitates, cuts off conversations that are "getting too detailed," and unknowingly kills the one discussion that would have prevented a two-day integration disaster. I've done this myself, more times than I'd like to admit.)
Some teams fix this by having a facilitator who redirects time toward the items that matter, but that requires a facilitator who actually understands everyone's work deeply enough to identify collisions in real time – which, in a cross-functional team, is a lot to ask of one person before their second coffee.
The async alternative (and why it's only half the answer)
Async standups – Slack bots that ask the three questions and post answers to a channel – solve the scheduling problem and the performance-anxiety problem. You write your update when you're ready, without the pressure of twenty people watching you try to remember what you did yesterday.
But they inherit all the weaknesses of the synchronous format, and they add a new one: nobody reads them. In our experience across a few teams (and I'm genuinely not sure if this is universal or just us), async standup posts get skimmed by the manager and ignored by everyone else. The information goes into a channel that becomes part of the background noise, functionally equivalent to those Slack channels everyone muted after week one.
The teams that make async standups work tend to do two things differently. First, they change the prompts – instead of "what did you do," they ask "what should someone else on the team know about?" which forces contributors to think about the audience rather than performing a status report. Second, they actually cancel the synchronous meeting, rather than running both in parallel. The dreaded double-standup – async post in the morning, live meeting at 9:30 covering the same ground – is more common than anyone wants to admit.
What actually makes standups effective
I'll be honest: we haven't figured out the perfect standup format (and I'm suspicious of anyone who claims they have). But the patterns that seem to consistently produce better outcomes are less about format and more about what information you're trying to surface.
Walk the board, not the people. Instead of going person by person, go ticket by ticket across your project board. This naturally surfaces the work that's stuck, the work that's moving, and the work that nobody's touched in four days. The people involved in each ticket speak to it; everyone else stays quiet without the social pressure of having to say something when there's nothing to report.
Time-box by importance, not by person. If something needs five minutes, give it five minutes. If someone's update is "same as yesterday, no changes," a nod is fine. The goal is for the meeting's time allocation to roughly mirror the actual distribution of risk across the team's work, not the headcount.
Surface the unknowns explicitly. End with a 60-second round of "what's the thing you're least certain about right now?" This catches the problems that don't look like problems yet – the assumptions, the dependencies, the "I think this is fine but I haven't checked" moments that, left unspoken, turn into Thursday afternoon emergencies.
Kill the meeting when it doesn't earn its keep. If the board walk takes two minutes because nothing meaningful changed, end it at two minutes. A standup that always takes fifteen minutes regardless of content is a standup that's been padded to fill its calendar slot. (And honestly, if nothing meaningful changed in 24 hours, that's either a very calm sprint or a signal that people are heads-down on deep work – either way, worth noting briefly and moving on.)
Effective standups measure risk, not activity. Walk the board, give important topics more time, and end the meeting early when the board is quiet.
The measurement problem underneath all of this
The deeper reason standups feel broken is that they're trying to solve a coordination problem with a communication ritual. You're asking humans to manually broadcast state changes that could, in theory, be derived from the tools they're already using. The PR was merged – it's in GitHub. The design changed – it's in Figma. The ticket moved – it's in Linear. The decision was made – it's somewhere in a Slack thread.
The information exists. It's scattered across different tools, and nobody has time to go spelunking through all of them before a 9am meeting. So we do the standup instead, which is a manual, lossy, once-daily sync of information that changes continuously throughout the day.
I'm not going to pitch you a product here – this is a playbook, not a sales page. But I think the industry is slowly moving toward solving this at the tool layer rather than the meeting layer. Whether that's workflow intelligence, better native integrations between your existing stack, or something else entirely, the direction seems clear even if the specific solutions (including ours, honestly) are still being figured out.
The practical advice stands on its own: change the questions, walk the board, time-box by risk, surface unknowns, and kill the meeting when it has nothing to say. If your standups start working better tomorrow, the format was the problem. If they don't – if the real issue is that critical context lives in six different tools and nobody can synthesise it fast enough – that's a different problem, and the standup was never going to solve it.
Let Sugarbug surface what changed across your tools overnight – so your standup can skip the status report and focus on what matters.
Q: How do I make my standups more effective? A: Shift from "what did you do?" to "what changed that affects someone else?" Walk the board instead of going person-by-person, time-box by importance rather than by individual, and explicitly surface unknowns. If nothing meaningful changed, end the meeting early.
Q: Are async standups better than synchronous ones? A: They solve the scheduling problem but inherit the same weakness: the three questions optimise for accountability, not coordination. Async works best when you change the prompts ("what should someone else know?") and actually cancel the synchronous meeting instead of running both.
Q: What should I ask instead of the three standup questions? A: Try: what changed since yesterday that someone else needs to know about, where is work about to overlap or conflict, and what's the thing you're least certain about right now. These measure coordination risk rather than individual activity.
Q: Can Sugarbug help reduce standup overhead? A: Sugarbug builds a knowledge graph across your team's tools – Linear tickets, GitHub PRs, Slack threads, Figma comments – and surfaces what changed overnight. Some teams use it to pre-generate a board walk summary, which means standup becomes a quick review of flagged items rather than a round-robin of status reports.
Q: Should I eliminate standups entirely? A: For small teams with good cross-tool visibility, sometimes yes. For larger or cross-functional teams, a short board-walk format tends to work better than elimination. The goal is to make the meeting earn its time slot every day – and if it consistently can't, that's useful information about your coordination infrastructure.