How many meetings should I have is an important question that programmers don’t spend a lot of time thinking about, except to complain that we’re having too many. We’re pretty sure managers should be having a lot, and programmers only a few. But how few?

  • We know that if programmers have zero meetings then they get to build stuff that no one will ever use.
  • We also know that if they have too many meetings then they don’t get to build stuff.

There’s a correct number in between there, and SCRUM has a good answer for that.

3 hours.

The monday meeting trap⌗

Every middle sized company I’ve ever worked in falls into the Monday Meeting Trap.

This is the giant cross-functional meeting on Monday where everyone sits in a big room and talks about their week. If you’re lucky you can disassociate while swirling a luke-warm cup of Kuerig coffee. If you hate this time, you give your update in two minutes and you pride yourself on this fact, and then you seeth at the people who take ten minutes to have a conversation on a topic that ony two people in the room can participate in.

This meeting happens because the big boss loves it. They can participate in every conversation, so they happily stay aware the entire time. If you ask them why you have to be there, they will talk about synergies and cross-functional knowledge. And they’re not wrong, but this meeting is the wrong way to accomplish that.

The Monday Meeting is bad.

Additive meetings⌗

Meetings grow like weeds, and you have to actively stamp them out to prevent them from strangling your team’s productivity.

Meetings accumulate. Especially when managers have too-few direct reports and they need to occupy themselves.

You keep being added to meetings.

Every small meeting somehow finds two other managers there, people who believe they need to “keep their fingers in the pie” or some other equally disgusting malapropism.

You want a small meeting with your programming team about technical issues? Somehow a representative from product is there, and they’re asking for an agenda. I quite like product managers, but they don’t need to be in every room.

So where are you now?⌗

You have your monday meeting at two hours, a daily half hour meeting with your manager and team, a couple of weekly 1-on-1s, and a couple cross-functional meetings you’ve been added to because your manager wants to get to know them.

You are at ten hours of meetings.

Ten hours of meetings is always the wrong number.

Ten hours of meetings is always the wrong number⌗

Paul Graham’s 2009 piece of required reading, “Maker’s Schedule Manager’s Schedule”, should clue you in to where the problem is.

To be more specific, if you have ten hours of meetings then something has gone wrong.

There are three scenarios.

  1. You’re a manager. If you only have ten hours of meetings then you don’t know what’s happening in your world, and decisions are being made about you without you.
  2. You’re a programmer. Not only are you spending ¼ of your week in meetings, you are destroying the productivity of the remaining 30 hours.
  3. You’re a programmer with a couple direct reports and some project management duties. You are being set up to fail. You are in a classic spot where your time is split ½ as a programmer ans ½ as a manager and ½ as an architect. This is a traditional “promotion” for good programmers in companies that don’t have a clear individual contributor track and enjoy burning out good programmers.

I’ll admit to a giant hole in my theory: I have no experience at the high end architect level. Ten hours of meetings might be about right for a very senior individual contributor.

Scrum to the answer, surprisingly⌗

How many meetings?

This is a feature of Scrum that I actually like. It has defined meetings with recommended lengths. Plus, with a bit of optimization to remove all that silly stuff that Scrum loves, we can hit a good target.

If you have a one-week sprint (which is an underrated sprint length), your week looks like this:

  • Five standups at five minutes each. I will fight anyone who says 15 minutes is acceptable.
  • One demo at a half hour. Don’t schedule it for an hour just because it fits neatly into your schedule.
  • One retro at a half hour. Just do the three questions, and don’t play silly sailboat games.
  • One planning at an hour. Use tee-shirt sizing: small, medium, large, or split into smaller tasks.

Two and a half hours of meetings. And every meeting is meaningful to all participants.

That is beautifull.

That leaves plenty of time for an additional “lunch-and-learn” or a “cross-team-what-are-you-doing” meeting or two, and you still won’t hit productivity trouble.

3 hours⌗

3 hours.

Scrum also solves the problem of people adding you to their meetings, or adding themselves to your Scrum meetings.

Scrum has a well-defined process with pre-defined meeting agendas, and you, as a simple engineer, can weaponize that. A kingdom-building director wants to join the daily stand-up? Scrum® says they can only watch, not interrupt. We have an agenda, and Scrum Best Practice® says not to change it. This isn’t you, the engineer, saying no. This is Scrum®.

3 hours is the right number.