I am seeing the magical number seven, plus or minus two, being misapplied to team sizes with increasing regularity. The frequent use of George Miller’s famous paper is often accompanied by a common misunderstanding. Lots of people are saying; “Your team should be between 5 and 9 people”, or “Teams should contain 7 people, plus or minus 2”.
Let’s deal with these two problems in turn.
Five is not the Minimum
There is no concept of a lower-limit in Millers magical number seven. The range of five to nine is used to describe the maximum number of chunks people can hold within their short-term memory. Using the lower value as a minimum team size is a logical error. Applying it back to the original paper, it would suggest that if you encoded a message in less than five chunks, you wouldn’t be able to hold it in your short term memory. That would be ridiculous.
Memory is not People
While Miller’s paper is titled The Magical Number Seven… it isn’t really magic. The number seven will not solve your problems, isn’t lucky, and may not supply you with the right team size. Applying a number from a study on memory as a limit to the size of a team is a strange thing to do. I can fit six eggs in a normal egg box, so does that mean my car should have six wheels? These things are not related.
The only time it would be appropriate to restrict the team size based on short-term memory would be to make it easier for someone to remember their names the first time they were introduced. It has little to do with the work the team will undertake.
So what is a good team size for you?
To answer this question, we need to stop fixating on studies on memory and start looking for studies on teams.
Let’s first get the number seven (plus or minus two) off of the table as a “this is a good team size for everything” number. To do this, we’ll use another famous study, which gave us the Ringelmann effect. The study found that once you reach five team members, adding more team members can result in diminishing returns. As team sizes grow, individual contributions drop. This suggests there is a maximum team size – but it definitely isn’t nine, it is probably more like five or six.
What about a lower limit? An individual working alone can be quite effective in solving some problems. One study published in the Journal of Personality and Social Psychology found that groups of three to five can consistently outperform the best individuals working alone. So it is likely that the minimum team size should be greater than one.
There are three famous graphs relating to team size based on data collected by QSM Inc. They have a wonderful amount of data about projects of many sizes, teams of many sizes, and some indication of productivity, project duration, and total effort.
I won’t publish all of the graphs, as I don’t have permission, but the story goes like this.
For productivity and total effort categories, smaller is better. The smallest team size (1.5 to 3) performs best with team sizes of 3 to 5 coming in second, and team sizes of 5 to 7 coming in third. If you continue into larger team sizes, the difference becomes very noticeable.
When it comes to schedule, the teams of 3 to 5 and the teams of 5 to 7 marginally outperform the team of 1.5 to 3 people. Once again, going higher than 7 causes problems – problems often attributed to the increasing number of communication lines needed to keep things running smoothly. Beware though… if you want to save a couple of months, one seriously savvy person making strong decisions about features will give you a bigger boost than adding three or four developers. This is important, because you might be tempted to hit the team size of 3 to 5 to get a good score across all three vectors; good productivity, good total effort, good time-line. Before you do this, consider the smaller team size, with a good bit of product management thrown in to ensure the right things are selected for development.
So it is probably best, in general, to have teams sized between two and five people. I say “in general” because it depends. It depends on the task at hand and it depends on the people and their skills. Very often, though, if you do have a team within this range, they will sub-divide into temporary smaller teams to solve actual problems if the work is not easily split between so many people.