A decent number of engineers I’ve worked with seem to tolerate stand-ups at best. This paper has a similar conclusion.

It’s true that stand-ups can suck. I think this is because everyone—team members and team leads—don’t know why they’re doing stand-ups. I definitely didn’t for a long time.

Today, I want to share some thoughts and tactics I’ve accumulated over the past few years.


Why Stand-Ups Suck

Lots of people (me included) started doing stand-ups when we joined a team that did stand-ups. We were indoctrinated into the standard stand-up ritual:

  1. What did you do yesterday?
  2. What will you do today?
  3. Any blockers?

In particular, everyone is focused solely on giving their three answers. People tunnel in on this.

I’ve had days where I couldn’t remember what I had just done the day before. I’ve seen someone who would take notes to prep for stand-up. These things all miss the point of these questions, and indicate that there’s something broken here.

The main reason stand-ups suck is that people don’t know why they’re doing stand-up.

People are focused on answering the questions, but they don’t know why those answers (or the questions) are important. If you don’t know why you’re doing something, of course it’s going to suck.

So, before we keep going: what do you think the purpose of a stand-up is?

A To B

I first started grappling with bad stand-up meetings a few years ago, when I started running my own. They were bad, and I was also in a phase where I was heavily questioning every process that I used.

This led me to Scrum. It was a helpful book for me, though I’d suggest getting your company to buy you a copy rather than buying it yourself (it’s useful but not terribly exciting).

One of the key points is, essentially: getting from A to B in business is similar to getting from A to B in day-to-day life.

And how do we get from A to B? We have a rough idea of where we’re going, take a few steps, then reevaluate.

A decent amount of the time, we’ll still be on track. So all is well and we keep going.

Sometimes we realize we got off track. We might’ve taken a turn too early, forgotten to get off at our stop, etc. When this happens, we course correct and figure out how we get to our destination.

Status Updates Are Means, Not Ends

Now, let’s come back to the purpose of stand-ups. If you said that the purpose of the stand-up meeting is to have a status update, you’re both right and wrong.

Status updates are an important part of the stand-up meeting. But they aren’t the goal of the meeting. They’re just the start.

The purpose of stand-up is to (re)evaluate the progress we’ve made towards our goal.

This involves:

  1. Figuring out where you are right now.
  2. Figuring out what you need to do next.

Where We Are Now

The status update is how we figure out where we are. That’s why standard stand-up questions involve saying what you did yesterday and what you’re doing today. You’re telling your team, “Hey, here’s the progress I’ve made so far.”

This is the easier part.

What We’re Doing Next

To figure out what to do next, we need to know (a) what’s left to be done and (b) what should be done first. That’s why we ask questions like:

This is easy to say, but not always that easy to do. I think there are two main things that can make it hard to figure out what to do next.

One, your project is complex. It’s big, has lots of moving parts, and/or requires lots of coordination.

Two, your team either doesn’t know how to think about what comes next or isn’t thinking about what comes next. A lot of the time, this happens because people are thinking as individuals and not teammates.

Again, you can’t just magically flip a switch to solve these problems. However, if you’re having stand-up problems, you’ll probably want to evaluate those two things.

This is especially true if you’re the team lead—you’re the one who needs to figure out how to make this happen!

Teams, Not Individuals

A significant part of the challenge is that each team member is often thinking as an individual, not as a team.

They’re thinking about what they did and are going to do. They’re not thinking about how either their or someone else’s progress affects the team as a whole.

To some extent, this is okay. You wouldn’t expect someone brand new to a team to know what’s going on. This often also isn’t each person’s explicit responsibility.

That said, if an experienced member of the team is paying zero (or close to zero) attention, I think that’s a problem. If awareness is too low, I’d even go as far to say that that person shouldn’t be promoted.

In Summary

Okay, let’s combine all these theory elements.

The purpose of stand-up is for a team to figure out how it’s going to reach the milestones and goals that it’s currently working towards. Often, this means closing out projects.

To do this, the team has to understand where it is and what it should do next. This starts with a status update, which is then used to evaluate and prioritize remaining work.

Finally, this isn’t done in a vacuum. Each person should be considering how the team’s progress is affected by each other person’s progress. Strong teams know how to course correct on their own.


I know—these are some lofty goals. I suspect it takes quite a bit of maturity, experience, motivation, and social awareness to accomplish this. I’m not a wizard; I’ve never fully accomplished this myself.

There are also a number of factors I’ve completely ignored: human factors. How people feel about one another, whether or not they’re hungry/tired/stressed, if people are feeling shy, etc.

The best recommendation I can give is to try things out. Here are a number of tactics I’ve experimented with—I recommend mixing and matching so you can find something that works for you.

Ask Meaningful Questions

There is only one question I always ask: What are you working on today?

From that question, I often have enough information to extrapolate where someone is and what obstacles I expect them to run into. When I don’t have enough information, I use follow-up questions to focus on the specifics that I need to know about.

I find asking what someone did the previous day to generally be a waste of time.

One, I already remember or I can just look at our task management board.

Two, I can extrapolate from what they’re doing today.

Three, if they reached a checkpoint or milestone (like closing out a feature), this info is always volunteered spontaneously.

I don’t dig into blockers unless I suspect there might be a blocker. Most commonly, this happens when:


Very commonly, people will say that they’re working on X or that things are fine during stand-up. This gives you almost no information.

Building feature X might involve five main steps. If someone tells you they’re working on X, you have no idea where they actually are.

Maybe they’re chugging along just fine. Maybe they aren’t sure how to start. Maybe they’ve gotten blocked on step two and (intentionally or not) aren’t bringing it up.

You need more information, and the way to get that is to probe a little bit. This is especially important when someone isn’t yet able to accurately evaluate their progress.

Some ways I like to probe:

Sometimes, when probing, I’ll discover that someone is stuck or completely unaware of something. This is good because I gained information. Remember, the goal is to gather information, not to make someone feel bad.

I handle those situations by either explaining / providing direction (if appropriate) or by making a mental note to follow up on it again later.

Instant Demo

When someone completes a feature or reaches a significant milestone, I like to do an instant demo.

To do this, I just try out that feature on the spot. This accomplishes a number of things:

Asynchronous Stand-Ups

Early on, I tried async stand-ups over slack. For my team, this actually sucked.

People were focused on giving status updates, not the big picture. There were days when I wasn’t even sure if people were reading everyone else’s messages.

Additionally, it hurt team cohesion. For my team, having some face-to-face time each day was important (even if they didn’t recognize this).

I could see async stand-ups working with teams who are more disciplined and mature about keeping stand-ups effective.


Sometimes, I focus the stand-ups on our in-flight features or projects, rather than on the progress everyone’s made. It’s a subtle shift, but people think differently when they’re asked how feature Y is going.

This is especially useful on more complex projects that involve coordination. Focusing on the project progress nearly forces this coordination to happen during stand-up, if it isn’t already happening.

Focusing at the feature level is also very helpful if someone is officially on the hook for that project. You can let them run a mini stand-up, just for people working on that feature.


Hopefully, this has given you a lot of food for thought on how to modify your stand-ups!

If this interests you, I’d recommend taking a look at some other articles out there on stand-up practices. I skimmed a few—while it seems like most of them miss the purpose of stand-up, they do dive into other interesting tactics (such as what time to hold stand-ups).