The Daily Developer
The Daily Developer
The one about standup meetings
0:00
-3:29

The one about standup meetings

Ah, yes, the standup meeting. Love them or hate them, there’s a 100% chance you’ve encountered this in your career.

Most standups are done very poorly. They often feel like useless checkins designed to ensure that you’re around and paying attention. The worst feel like an enforcement of attendance at work - a virtual version of “butts in seats” type of management.

However, when done well, they are essential to keeping a high performing team making progress every day.

The goal of a standup meeting is to optimize the probability that we hit our goals.

So: it’s an optimization of probability. From both sides, we must acknowledge that merely setting goals does not mean we will reach them. And many times a poor standup meeting process will sort of forget about the goals and “focus on the process”. (I do have an opinion on focusing on processes over goals, but for the sake of argument, let’s assume setting goals is a good practice. Crazy idea.)

Standups, done well, should act as milestones. Rather than "what are you working on", a small tweak in language could be: what did you do since the last standup? what do you intend to do before the next standup?

Instead of viewing these as meaningless “check-ins”, view them as a perpetual way to course correct. (If you think you don’t need to course-correct, or you think that nobody else can help you with such an exercise, or that managers should butt out of your work, you haven’t seen shit.)

When you treat standups as milestones, you provide the opportunity to revise your estimates. If that feature will take twice as long, you have a professional responsibility to disclose that to your team. Holding a standup meeting is a time-proven way for your team to learn about these disclosures and updates without relying on each team member to proactively send out such an update to everyone involved. It just happens at standup.

Standup is an expensive meeting. It follows that you should be as succinct as humanly possible. Literally nobody enjoys hearing you explore your current approach out loud in a stream-of-thought manner, meandering through your architecture decisions and explorations.

AFTER standup is the time to dive deep into technical details. Don’t waste everyone’s time by using up a ton of oxygen.

And be positive. Remember to thank anyone who’s helped you and take every opportunity to reinforce good practices that you see elsewhere.

It’s so embarrassingly common to see this done poorly.

If you master the art of the effective standup, you will earn the respect of your colleages and manager. I guarantee the leadership of your team will sit up and take notice.

0 Comments
The Daily Developer
The Daily Developer
Meditations for software developers
Listen on
Substack App
Apple Podcasts
RSS Feed
Appears in episode
Dave Paola