Team Size Matters

I like small teams, between four and six people. Here’s why.

I’ve observed over the years that teams of more than nine people didn’t have what I call the “intimacy” of smaller teams. Teams of three people or smaller didn’t always have the ideas needed, but teams larger than nine people lost something that was common to smaller teams—an ability to easily communicate with each other. There is a reason for that: the number of communication paths in the team.

Beware of Too-Small Teams
	Too-small teams—three or fewer people—might not have enough diversity to solve their problems. They don’t have enough ideas. Too few people can be just as bad—although differently bad—than too many people.

Collaborative teams need pair-wise communication, where everyone talks to everyone else. There is no restriction on communication, and we want people to talk to each other. Following is a picture of the paths in a six-person team. I numbered the paths going around and then from the top to the bottom, starting on the left side of the image.

The number of communication paths in the team does not increase linearly as the team size increases. Team communication paths square when the team increases linearly.

Here is the calculation where N is the number of people on the team: Communication Paths = N*(N-1)/2. That means you have these communication paths for these team sizes:

Five people require a total of 10 communication paths. Eight people require 24 communication paths. Once we get past 21 paths, many of us don’t talk with the entire team—we choose who to work with and who to ignore. Once a team gets to 10 people, the number of paths is 45, which is unmanageable for most of us.

Can some people manage this number of communication paths? Sure. But not many of us, which is the problem. That’s why “teams” of 10 people don’t work.

If you have a group of 10 people, they will naturally divide into smaller subteams of people who can work together. They will not divide themselves evenly, as in five and five. Oh no, that would make life too easy. If you are lucky, they will divide by features. If you are not lucky, they will divide by architecture or by function, or even worse, by clique.

What do you do if you have a large team? Organizations create large teams for any number of reasons: they envision large features or the necessary expertise is distributed throughout the organization. Sometimes the organization has a program, a collection of projects that fulfill one business objective. (See Agile and Lean Program Management [Rot16] for ways to organize a program other than to create a very large team.) Often it’s easier to organize the features so that smaller feature teams can deliver the results than it is to create a larger team.

Consider these alternatives to create smaller cross-functional teams:

• Make the stories smaller so the team can be smaller. See ​Write Small Stories​, for more information.

• Organize by feature or feature set. If you’ve been organizing by architecture, reorganize the teams to be feature teams. Aim for a feature team size of no more than six. For example, think about these feature sets: search, admin, billing. Each of those feature sets might need just one team. If your feature set is too large for one team, consider organizing as a program around smaller feature sets. For example, you might need a feature set for “simple search” and another feature set for “search within results.” Both would be search feature sets and the team members might need to work or speak with each other.

• If you have already organized by feature and the team is still larger than nine, check for team skills and capabilities. The team members might not realize that it’s great if they “cover” other areas of the code or tests.

• Should this team break into several other teams and organize as a program? Sometimes when teams become large, it’s time for each team to take a feature set (or two) and focus on those features. (See Agile and Lean Program Management: Scaling Collaboration Across the Organization [Rot16] for ideas.)

If you still need a large team, consider measuring the team’s throughput and see if the team waits for people outside the team or for people on the team. That will help you see if there is a problem with experts, as discussed in ​Trap: The Team Consists of Narrow Experts​.