How to run a standup that people don't dread
Most standups fail for the same three reasons. Here is a format that fixes them, plus what to do when your team has grown past the point where going round the room works.
The daily standup is the most widely adopted practice in modern team management and one of the most consistently disliked. That combination should tell you something: the idea is sound, and the usual implementation is not.
The original intent was narrow. Fifteen minutes, standing up so nobody gets comfortable, three questions, and the specific goal of surfacing blockers early enough to do something about them. What most teams have instead is a twenty-five minute seated meeting where seven people take turns describing their week to a manager while the other six wait for their turn and think about something else.
This guide covers why that happens and what to do instead.
Why standups decay
Three failure modes account for nearly all of it.
It becomes a status report to one person. The tell is easy to spot: everyone speaks to the manager rather than the team. Once that pattern sets in, the meeting is no longer coordination — it is serial one-to-one reporting conducted in front of an audience, and the audience is bored because none of it concerns them. Every person present is paying the full cost of the meeting for a few seconds of relevant content.
It becomes a memory test. Nobody has a reliable record of what they did, so each person reconstructs it live. Recent and dramatic work gets reported; the task that has quietly not moved for three weeks does not, because you do not remember to mention the thing you have not been doing. This is precisely the item the meeting existed to catch.
It becomes problem-solving. Someone mentions a blocker, two people start debugging it, and the other five watch for eleven minutes. This one is the most frustrating because it comes from good intentions. The blocker is real and the people are being helpful. They are just doing it in front of an unnecessary audience.
A format that holds up
The fix is to change what the meeting is for. Instead of "everyone reports", make it "we look at the work together". The distinction sounds like semantics; in practice it changes the whole dynamic, because attention is on a shared artefact rather than on whoever is speaking.
Put the work on a screen
Do not go round the room. Pull up the actual list of what the team is doing and walk the list, not the people. This single change fixes the memory problem — nobody has to remember anything, because it is written down — and it fixes the reporting dynamic, because everyone is looking at the same thing rather than at each other.
If you use TIBLR, Meeting Mode does this automatically: it groups the team's tasks into what completed since the last sync, what is blocked, what has not moved, and what is in flight. Any tool that lets you filter by recent activity will do the same job; the point is that the agenda is generated from reality rather than assembled from recollection.
Lead with blockers
Reorder the meeting so blocked work comes first. This matters more than it sounds, because blocked work is the only category where being in a room together actually helps. Completed work is nice to acknowledge but does not need a meeting. In-progress work needs a nod. Blocked work needs people.
Leading with it also means that if the meeting runs long and gets cut short, the part that got covered was the part that mattered.
Timebox to the decision, not the discussion
When a blocker turns into a debugging session, stop it and name the follow-up: who is going to talk to whom, and by when. This is the single highest-leverage intervention available to whoever runs the meeting, and it is uncomfortable the first few times because it feels like you are cutting off someone being helpful. Do it anyway. Two people solving a problem live in front of five spectators is an expensive way to solve a problem.
Ask about the quiet items
Somewhere near the end, look at whatever has not moved in the past week and ask about it directly. Not accusingly — the usual answer is entirely reasonable, and often the honest answer is "I have not had time and I am not going to". That is a useful thing to learn, and it will not surface on its own.
This is the part most standups skip, and it is where most of the value is. Work that is actively going wrong tends to be noisy. Work that has quietly stopped is silent, and silence is easy to mistake for progress.
What to do as the team grows
The go-round format breaks somewhere between six and eight people. The maths is unforgiving: at ninety seconds each, eight people is twelve minutes of talking before any discussion, and ninety seconds is optimistic.
You have three reasonable options.
Split the meeting. Two standups of four, run by whoever is closest to that work. The cost is that cross-group awareness drops, which you can mitigate with a short written summary.
Go asynchronous. Everyone updates their own work before a cutoff time; the meeting only happens if something is blocked. This works well for distributed teams and requires genuine discipline about writing updates a colleague can act on. Our guide on async status updates covers how to write those.
Walk the work, not the people. Keep everyone in the room but stop going round. Look at the blocked and stale items only, which is typically five or six tasks regardless of team size. This scales further than the other two and is usually the first thing to try.
Reduce the frequency before you improve the meeting
One more option deserves stating plainly, because it gets skipped: many teams that meet daily do not need to.
Daily standups came from contexts with genuinely daily coordination needs — a shared codebase, tight iterations, work that regularly steps on other work. Plenty of teams have adopted the ritual without the underlying need. If your standup consistently produces no blockers and no coordination, that is not a sign you are running it well. It is a sign it is not needed at that frequency.
Try twice a week. If nothing breaks, you have recovered three meetings a week for every person on the team, which is a substantial return for a change that costs nothing.
The test
A good standup surfaces at least one thing that someone did not already know, and produces at least one action that would not otherwise have happened.
Run yours for two weeks and count. If most days produce neither, the format is not the problem — the frequency is, or the meeting is. Both are fixable, and both are cheaper to fix than continuing to hold a meeting nobody benefits from.
TIBLR's Meeting Mode builds the agenda from your team's live tasks — completed, blocked, stale, and in progress — so nobody has to prepare. It is free to use.
Keep reading
How to run 1:1s where the action items actually get done
Most advice about one-on-ones is about the conversation. The conversation is rarely the problem — the fortnight afterwards is. A practical structure for 1:1s that close the loop, with agenda templates and the questions worth asking.
ReadOKRs for small teams, without the ceremony
Most OKR advice was written for companies with a thousand people. Here is what actually transfers to a team of fifteen, what to skip, and how to write key results that are measurable without being trivial.
ReadWriting async status updates a colleague can actually act on
Distributed teams fail at handoffs, not at working. A practical format for written updates that survive an eleven-hour gap, and the specific habits that make them worth reading.
Read