I’ve been participating in software standups every day for over a decade, and over the past two years, leading them, too. Here’s how I run the best standup meetings that I can.

Guiding Principle: Physically Stand

Standups got their name because people physically stood up during them; use that as a guiding principle.

I don’t stand up, nor do people on my team. The idea is to keep the meeting tight. Standups shouldn’t be long. They should not be something you can step away from for ten minutes to flip the laundry.

Meetings are expensive. We should try to optimize them.

Counterpoint: Meetings are Expensive!

Some of the thought leaders I admire are against all synchronous meetings. Should we do standups at all?

Perhaps at Basecamp, your team is all strong remote-first seniors who know how to ship or unblock themselves. My experience on the mortal plane is that we need regular touchpoints. Again, we should try to optimize them.

Meet Daily

If you’re going to meet, I think that it’s vital to meet every day.

This comes from Extreme Programming: if something is good, we should do it all the time. If “checking in” with teammates is important, we should do it daily. No consulting the calendar to see if it’s Standup Day. No pinging teammates to see if they’re free to meet. It’s always standup day, and when it’s time for standup, everybody’s there.

Meet Earlier

It’s better to meet earlier in the day.

I try to meet in the first hour of the day in whatever timezone overlap I have available. So, if I have programmers in CST and EST, we meet at the start of the later business day, 9 AM CST.

On all teams, but especially those with junior engineers, it’s better to get problems on the table early, so we can do, defer, delegate, or decline them. I think morning is time when people are fresh, and also not deep into a stream of work.

Everyone Attends, Everyone Speaks

Everyone attends standup, and everyone speaks.

We don’t skip somebody who didn’t show up; we send them a message and wait for them for a reasonable amount of time. Everybody reports. There’s nobody at the meeting who doesn’t report.

Break the Ice

I like to take time to break the ice— be social, catch up, and read the room.

Programming work, and especially remote work, can feel robotic. Standup is sometimes the only time I get to see people on my team. So we take some time, 5-10 minutes, to check in.

“How are you doing?” “What’s going on with you?” I think this is a crucial way to remember that we’re humans and not status-reporting robots.

I wait for a lull in the conversation around ten minutes before pivoting to formal standup.

Go Around the Circle

Next, we go around the circle, in random order, time-boxed, following a loose format.

The random order is key. Without it, a dynamic will develop where the leader speaks first, or the junior dev speaks last, or the person with the hottest issue grabs the mic and doesn’t let it go.

Time-boxed presentations are important. Use a timer if needed. Don’t let people dominate.

A format is essential. I’ve always preferred “Yesterday, Today, Blockers.” Blockers are important because some people will not emphatically say “I’m blocked and need help” unless they are encouraged to do so.

I think it’s important to model informative, impromptu, and actionable reports at standups. It takes practice.

Don’t Code!

Avoid programming during standup. Not while others are talking, and also not taking time to dig into live-coding problems.

If you’re keeping the meetings short, you don’t have much time, and people reporting on what they’re doing is more important than coding.

More importantly, pairing or mob-programming is unlikely to be relevant to everyone at the meeting. Schedule a breakout with the relevant people.

Keeping your hands off the keyboard is challenging for many. You’ll think: “I could just answer that now, or fix it now.” Very often, that isn’t true. And it can be morale-crushing watching somebody rifling through a codebase during a team check-in. Don’t do it.

Encourage Good

I like to see a live feature demo during standup.

If you’re building something cool, show it off! Send us a link. Ask for feedback. Great teams have a “Look at this cool thing I built” culture that you can sense through frequent demos.

If you’re doing the demo, take a minute beforehand to get everything set up. Screen sharing while you log into the VPN is not ideal.

Leftover Ideas Go to the “Parking Lot”

After reporting, we hold a time we call “Parking Lot,” where people can bring up issues or questions to discuss.

This is the time to pull a thread or expose something thorny.

Conclusion

I’ve had the pleasure of writing about standups a few times before:

These are guidelines; follow them all, and you’ll have a standup meeting that works.