A standup meeting has one job: help a team coordinate quickly by surfacing what is happening, what is blocked, and what depends on whom. It has become a punchline in a lot of workplaces because it drifts from that job into a daily status report read aloud to an audience that mostly is not listening. Run correctly, it is one of the cheapest, highest-value meetings a team has. Run poorly, it is fifteen minutes of theater repeated every single day.
What changed in 2026
- Async standups became the default for distributed and hybrid teams, with a written update posted in a shared channel replacing the live call for teams spread across time zones.
- AI meeting-note tools now summarize standup updates automatically in some tools, reducing the manual overhead of tracking who said what, though teams still need to actually act on the blockers surfaced.
- More teams shortened the format further, moving from a strict three-question script toward a lighter "blockers and dependencies only" format once a team has enough shared context that full status updates add little value.
The classic three-question format
The traditional standup asks each person three questions: what did you do since the last standup, what will you do until the next one, and what is blocking you. This format works well for newer teams or teams without another way to track daily progress. Its main risk is drifting into a narrated to-do list that provides little coordination value once a team already tracks work in a shared board or ticketing system.
When to switch to a blockers-only format
Once a team has a reliable, visible source of truth for task status — a shared board, a project tracker — the first two questions (what you did, what you will do) become redundant with information already visible elsewhere. At that point, shifting standup to focus almost entirely on blockers and cross-team dependencies keeps the meeting short and prevents it from becoming a live narration of a tool everyone can already see.
Standup format comparison
| Format |
Best for |
Typical length |
| Live three-question standup |
Newer teams, no shared tracker |
10-15 minutes |
| Live blockers-only standup |
Established teams with a visible tracker |
5-10 minutes |
| Async written standup |
Distributed teams, different time zones |
No live time, read async |
| Hybrid (async update + live for blockers only) |
Larger or partially distributed teams |
5 minutes live |
How to run one well
- Time-box it strictly — 15 minutes for most teams, less for smaller ones. A hard stop forces people to keep updates relevant.
- Keep it standing or otherwise physically or socially uncomfortable to prolong. The literal "stand up" origin of the format exists for this reason.
- Move problem-solving out of the room. If a blocker needs real discussion, name it, assign an owner, and take it to a separate conversation.
- Rotate or designate a facilitator to keep the pace moving and gently redirect tangents.
- Revisit the format periodically. A format that worked for a five-person team may need to change at fifteen people — do not run it on autopilot indefinitely.
Common mistakes
- Letting standup become a status report to a manager rather than a coordination tool for the team itself.
- Solving problems live, turning a 15-minute meeting into a 45-minute one for everyone, most of whom are not involved in the problem.
- Running it at a fixed time that ignores time zones on a distributed team, forcing someone to attend at an unreasonable hour.
- Never revisiting the format even after the team size or work style has clearly outgrown it.
Standups are one input into broader team health; pairing a tight standup with a regular retro covers both the daily coordination and the periodic process improvement that standups alone do not address.
FAQ
How long should a standup actually take?
Fifteen minutes is a reasonable ceiling for most teams; smaller or more experienced teams can often run it in five to ten.
Is async standup as effective as a live one?
For distributed teams, often yes — the core value (visibility into blockers and dependencies) transfers to a written format. What is lost is the informal social coordination a live meeting can provide, which some teams replace with a separate lightweight sync.
Should standup include the manager?
It can, but the meeting should not become a status report aimed primarily at the manager — that shifts the purpose away from peer coordination and tends to make updates more guarded.
What if standup keeps running long no matter what?
Usually a sign the format needs to change — move to blockers-only, split a large team into smaller pods, or move detailed updates to an async channel.
Where to go next