Jeff Bezos, Amazon CEO, famously claimed that if a team couldn’t be fed with two pizzas it was too big. Of course, he also declared that “communication is terrible!” – so, was he making a valid point or just grandstanding?

It can seem counterintuitive to suggest that two heads are worse than one, but there’s actually a good body of evidence to suggest that Bezos knows what he is talking about.

A number of studies show a variety of effects that make create sluggishness and lower productivity in large teams, regardless of who’s in them.

Sluggishness in Large Scrums – Jeff Sutherland

The Scrum Guide has evolved its “7 ± 2” people rule for team size into “3-9 people” over the years, showing a growing recognition of the value of even the smallest teams.

But Jeff Sutherland, one of the inventors of Scrum and writer of The Scrum Guide, is unequivocal on the matter – keep it at 7 people or fewer.

In an experience report he produced for Craig Larman’s book Agile and Iterative Development: A Manager’s Guide, Sutherland described a situation he observed within a 500 person dev group:

A few teams within the group were generating production code five times over the industry average rate. But most only doubled the production average, despite good Scrum execution. All the teams that were able to work hyper-productively consisted of 7 people or fewer, and Sutherland surmises that the larger group numbers (usually of around 15) were the reason behind their relative sluggishness.

He also points out that (at the time of writing) Rubin’s Worldwide Benchmark database gives the average cost per function point, across over 1000 projects, as $2970, but for teams of 7 people, the average was just $566.

“Any team over 7 in size should be split up into multiple Scrums.” – Jeff Sutherland

Social Loafing–Ringelmann, Latané et al

A much earlier case for small teams was made by Maximilien Ringelmann, with his 1913 findings now referred to as the Ringelmann Effect.

Essentially, the Ringelmann Effect suggests that the size of a team is inversely proportional to its productivity. The more bodies in a group, the more difficult coordination becomes, with teamwork and cooperation suffering. Ringelmann highlighted this with his renowned “rope pulling experiment” – he found that if he asked a group of men to pull on a rope together, each made less effort when doing so as part of the group than when tugging alone.

Ringelmann’s findings are backed up by the experiments of Bibb Latané et al, who studied the phenomenon known as social loafing.

Social psychologist Latané demonstrated the social loafing effect in a number of ways. A key experiment that showed that, when tasked with creating the loudest noise possible, people in a group would only shout at a third of the capacity they demonstrated alone. Even just (mistakenly) believing they were in a group was enough to make a significant impact on the subjects’ performance.

“When groups get larger, you experience less social pressure and feel less responsibility because your performance becomes difficult, or even impossible, to correctly assess amidst a crowd. It’s no wonder that when credit and blame get harder to assign, you start to feel disconnected from your job.” – Bibb Latané

The Pain of Link Management – J. Richard Hackman

It was published a number of years ago now, but Diane Coutu’s interview with J. Richard Hackman on Why Teams Don’t Work in the Harvard Business Review is worth a read for a further look at the many reasons that teams can hinder more than help.

To Hackman, one of the key stumbling blocks for teams is link management. As groups grow, the accumulating links between everyone within the team rises steeply. The number of links created by a team can easily be calculated with the equation:

# of links = n(n-1)/2 
(where n = number of people in the team)

So a team of six will create 15 links, but a team of twelve racks up 66.

The more links needing maintenance, the higher the potential for mismanagement and miscommunication. Keeping everyone in the loop and coordinated can eat into productive time. Or, as Hackman bluntly puts it, “big teams usually wind up just wasting everybody’s time”.

Relational Loss – Jennifer Mueller

Racking up links can also incur a more personal toll. Psychologist and Professor of Management, Jennifer Mueller proposed “relational loss” – the feeling that you are receiving diminishing support the larger your team grows – as another issue created by a larger team.

Mueller studied 212 knowledge workers across a number of companies in teams ranging in size from three to nineteen. Across data derived performance evaluations and questionnaires on motivation, connectedness, and coordination, she found “compelling evidence for relational loss.” The larger the team, the less supported people felt and the more their performance suffered.

Software Project Teams – Brooks’s Law

“Adding human-power to a late software project just makes it later.” – Fred Brooks

Most developers will be familiar with Brooks’s Law for software project management and the idea that for every project there is an incremental person who will make a project take longer, if added to it, along with those arguments that refute it.

Whether the law is gospel or “an outrageous simplification” as Brooks himself claimed, three sound factors underpin his point:

Firstly, new team members are rarely immediately productive – they need what Brooks refers to as “ramp up” time. During ramp up time, existing members of the group may lose focus as they dedicate time and resources to training the newcomer. Far from creating an immediate improvement, the new worker may even make a negative contribution, for instance introducing bugs.

Secondly, personnel additions increase communication overheads – everyone needs to keep track of progress, so the more people in the team the longer it takes to find out where everyone else is up to.

Thirdly, there’s the potential issue of limited task divisibility. Some tasks are easily divided but others are not, as illustrated by Brooks’s charming example that, while one woman needs nine months to make one baby, “nine women can’t make a baby in one month”.

Larger Teams Breed Overconfidence and Under-performance – Staats, Milkman and Fox

Not only does larger team size seemingly make people more complacent and less productive, but it also breeds overconfidence. There’s a tendency “to increasingly underestimate task completion time as team size grows,” say researchers Bradley Staats, Katherine Milkman, and Craig Fox. One of their experiments showed that, in a task to build uniform Lego figures, teams of four people were almost twice as optimistic about how quickly they could construct it as teams of two, but they actually took over 44% longer.

If four people struggle to work together to build some Lego, then the outlook doesn’t exactly look great for a complex development project.

Back to Bezos (and Pizza)

In practice, the two-pizza rule translates to splitting your personnel into autonomous task forces of five to seven people, which sits comfortably alongside the advice of Sutherland and Hackman and should minimise social loafing and the sense of relational loss.

And when Bezos said “communication is terrible”, he was really saying that cross-team exchange gets in the way of team independence and creates group-think. Not everywhere has a culture that relies on creative conflict like Amazon, but limiting dysfunctional decision-making and being discerning about how and where communication is needed would be beneficial to all.

If you’re mystified by a lack of productivity from a highly skilled and talented dev team, it may be that you’ve just got too many talented people trying to work together. Splitting your group into two or more two-pizza sub-teams might be all it takes to radically change your output.