How to Run Effective Standups: A Tech Lead's Complete Guide

I have seen hundreds of standups over 22 years of building software. Most of them are terrible. Developers recite what they did yesterday like students reading homework aloud. Nobody listens. The meeting runs 25 minutes for a team of six. People leave feeling like they wasted their time, because they did.

But when standups work, they are the most valuable 10 minutes of your day. They surface blockers before they become crises. They create natural accountability. They give you, as the tech lead, a real-time pulse on your team's health. The difference between a good standup and a bad one comes down to how you design and facilitate it.

The Real Purpose of a Standup

Standups are not status reports. If you need to know what everyone did yesterday, read the commit log or check your project board. The actual purpose of a standup is coordination: identifying who needs help, what is blocked, and where work is overlapping or diverging from the plan.

Once you internalize this shift, everything about how you run the meeting changes. The question is not "What did you do?" but "What does the team need to know right now?"

The Three Questions Are Wrong

The classic standup format asks: What did you do yesterday? What will you do today? Any blockers? This format has three problems:

1. It is person-centered, not goal-centered. People talk about their individual tasks without connecting them to the sprint goal or team priorities.
2. It encourages monologues. Each person gets their turn to talk, and nobody else is paying attention because they are rehearsing their own update.
3. Blockers always come last. People bury the most important information at the end, often downplaying it with "I might have a small blocker."

A Better Standup Format

I use a board-focused approach. Instead of going person by person, we walk the board from right to left, starting with items closest to done. For each item in progress:

• Is this on track to finish by its target? Simple yes or no.
• Is anything blocking or slowing it down? If yes, who can help resolve it today?
• Does anyone need to coordinate on this? Dependencies, shared resources, conflicting changes.

This format keeps the conversation focused on the work rather than the people. It naturally highlights items that are stuck. And it takes less time because you skip items that are progressing smoothly.

Strict Time Boundaries

A standup should be 10 minutes maximum for a team of 5-8 people. If yours regularly goes longer, something is wrong. Common causes:

• Problem-solving in the standup. When someone raises a blocker, the team instinctively tries to solve it on the spot. As the facilitator, cut this off: "Let's take this offline. Maria and John, can you sync right after standup?"
• Too many people. If your standup has more than 8 people, split it. Large standups devolve into theater where everyone performs being productive.
• Unfocused updates. When someone starts giving a detailed technical explanation, redirect: "What is the headline? We can dig into details after."

I actually use a timer. It felt awkward at first, but my team came to appreciate it. Nobody wants to be in a 30-minute standup. The timer gives everyone permission to be brief.

Walking the Board: Step by Step

Start from the Right

Begin with items in review or testing. These are closest to done. Ask: "What do these need to get to done today?" Often the answer is a code review or a QA check. By surfacing this first, you create immediate action items. This also ties into good code review practices, since reviews are often the bottleneck.

Move to In Progress

For each item, the person working on it gives a one-sentence status. You are listening for two things: confidence level and implicit blockers. "I am making good progress" is different from "I am still figuring out the approach." The second one needs attention even if the developer does not explicitly ask for help.

Check the Backlog

Quickly scan upcoming items. Is anyone about to finish their current task and need to pull the next one? Are there dependencies between upcoming items that need sequencing? A 30-second look at what is next prevents people from being idle or grabbing work out of priority order.

Handling the "I Have Nothing to Report" Problem

When someone consistently says "same as yesterday, still working on it," that is a signal. It might mean the task is too large and should be broken down. It might mean they are stuck but embarrassed to say so. It might mean they do not understand the standup format.

Pull them aside after standup. Ask: "I noticed you have been on this task for three days. Walk me through where you are." More often than not, you will discover a blocker they did not want to raise publicly. Your job as tech lead is to create safety for people to say "I am stuck" without feeling judged. For more on this, read about building engineering culture.

Remote and Async Standups

For remote teams, video standups work if you keep them short and cameras-on. The visual presence matters for connection even if it adds nothing to the information exchange.

Async standups work for teams spread across more than three time zones. I use a simple bot that asks the team to post their update by a certain time. But async standups lose the real-time coordination benefit. If someone posts a blocker, it might sit there for hours. My compromise: async updates Monday through Thursday, synchronous standup on Wednesday or Thursday to maintain human connection.

What You Should Be Doing During Standup

As the tech lead, your role in standup is not to talk. It is to listen and facilitate. Specifically:

• Listen for risks. A developer says they are "trying a different approach." That might mean the original estimate is blown.
• Connect dots. If two developers are working on adjacent features, point out the potential integration issues before they discover them during code review.
• Redirect tangents. The moment a conversation becomes a two-person technical discussion, park it. "Great topic. Let's solve this right after standup."
• Track patterns. If the same blocker comes up three days in a row, it needs escalation, not another mention in tomorrow's standup.

Common Anti-Patterns to Eliminate

Measuring Standup Effectiveness

You know your standup is working when blockers are resolved the same day they are raised. When team members start coordinating directly without you prompting them. When the meeting finishes in under 10 minutes and people leave with clarity about their day. And when nobody dreads attending it.

If you survey your team and they say standup is a waste of time, do not cancel it. Fix it. The format above has transformed standups for every team I have led. Give it two weeks. The improvement is usually dramatic.