How to refactor meetings as they grow with the rule of eight
Tags: agile, leadership, management
Published: 2022-04-03 18:14:30

---
title: How to refactor meetings as they grow with the rule of eight
published: true
date: 2021-04-30 00:00:00 UTC
tags: agile, leadership, management
canonical_url: https://www.rubick.com/the-rule-of-eight-for-strong-decision-making-meetings/
---

A rule of thumb is that **a meeting with more than eight people isn’t a decision-making meeting**.

When you have more than eight participants, you either need to change the format of the meeting, or you need to restructure the participants (and you usually want to do some deeper work on communication and organizational structure).

## Meetings devolve towards dysfunction

A common example that illustrates this point is what happens with a company's main leadership group. I've seen this happen a few times now:

*   You start with a small leadership team of four or five people. 
*   As the company grows, you add more leaders. 
*   Soon the group grows to twelve people.
*   The amount of substantial, real decision-making goes down over time, and the meetings feel like a waste of time.

## Splitting meetings in two may not work

The way most people handle meeting growth is to view it as a meeting problem. 

There are too many people in the leadership meeting? Split the meeting into two groups, right?

*   An executive meeting (for a smaller group of leaders)
*   A leadership meeting (for all leaders in the company, including the executive team)

While straightforward, this doesn't usually produce the results you would expect.

## Problems with just splitting meetings

Why doesn't this work? Let's use the **rule of eight** to analyze this situation. Remember, **a meeting with more than eight people isn’t a decision-making meeting**.  

With that in mind, here's what we will observe:

*   The executive team remains effective, because it is under eight people. 
*   The leadership team is still a large group, so it’s not a decision-making body. But often that isn’t explicitly decided upon, and the group continues to try and use the meeting as a decision-making body.
*   Having two meetings is more complex than one, and there is less "shared state" between the two meetings, so everyone gets confused because information isn't being passed well between the two meetings. 
*   The result is usually a more effective core executive team, and a more confused larger leadership team.

It’s not that this structure is bad (it’s very common, and something that can work). It’s that the expectations for this structure are unrealistic. The leadership meeting isn’t going to be a decision-making group. 

## What are some better ways to design your meetings?

It's better to do the work to deeply restructure the communication paths and underlying teams.  

In this example, you have two choices that would be better:

* Make the leadership team meeting a **status or announcement** type meeting.
* Structure the leadership teams into smaller **decision-making** bodies.

I tend to favor the latter approach. You want substantitive, impactful decision-making to be happening throughout the company. If you don't design it that way, people will add the extra meetings anyway to get things done. You'll end up with an ad hoc, informally-specified, parallel version of what you're designing. This results in twice as many meetings, making the organization much less effective. 

You could divide the leadership team into several smaller leadership teams, each focused on a part of the business. For example, a GTM and Product leadership team. Each of these meetings could be under eight people, allowing them to be decision-making meetings. 

Some leaders won’t completely fit into one or the other group. Do your best to align them with the parts of the business where they'll do the most good. For example, you might have a head of security. Security is tightly connected to the product, but also highly involved in the sales process. You might decide to put them in the GTM meeting, because that optimizes for the sales team being effective. Or you could decide to have them attend the Product leadership meeting. Choose based on which is more critical.

## Design your communication pathways

The important thing is to then think about the communication needs of these groups. You might decide to share the notes from these meetings to other leadership teams, or publish them on the wiki. You could have some sort of weekly communication coming out of each meeting. Or have a short sync meeting between the two occasionally.

## Other examples of redesigning meetings

Here are a couple of other examples of this rule in practice: 

*   You have a managers meeting, and you go from having four managers within your department to five, six, seven, and eight managers. As you approach eight managers, you should anticipate needing to split the group.  \
\
-> I would usually divide this into two managers meetings, each led by a different leader. I might lead one of those meetings and have a director lead the other and report to me.  

*   You’re working on a project with a lot of stakeholders. They’d all like to attend your weekly meeting, where you’ve typically done a lot of your problem-solving. At first it’s easiest to just add a few people to your existing meeting. But when the group gets too large, it becomes unwieldy.  \
 \
-> I would typically make a list of who the problem-solvers are, and who the stakeholders are, and either move the stakeholders to receive status communication, or give them good notes from the meeting. Or have a separate stakeholders meeting, where we share status and solicit feedback (That can be larger than eight people). One thing to look at in this situation is why there are so many stakeholders, and if that truly makes sense. I’ve seen times when there were eight stakeholders and two engineers working on a project. That's something to squint at. 

## It's not impossible to make decisions in larger groups

Note that it’s not impossible to make decisions in larger groups, it’s just harder, and requires more structure. Some techniques you can use are breakout rooms, polling, simultaneously editing a shared document, or approaches that use a lot of parallelism like sticky notes and grouping.

_Image by <a href="https://pixabay.com/users/geralt-9301/">Gerd Altmann</a> from <a href="https://pixabay.com/">Pixabay</a>_