The two-pizza rule: Keep teams small for quality code

No one sets out to write bad code. (Presumably.) But what’s the best way to go about creating great code? A company should throw as many developers at a problem as possible, right? Not quite. Less, as it turns out, is more.

It’s the classic tale of start-ups. From humble beginnings, a small crew of clever people code and hustle their hearts out to make it big. But in the transition from coding in someone’s basement to opening the Stock Exchange, something is lost. Company culture changes; scaling up in scope feels more like selling out. However, that feeling might have more to do with sociology than business.

The science of relationships

Humans are social animals. Group dynamics are more at play in work than we’d like to think. Despite what your friends list might suggest, anthropologists suggest that the maximum number of relationships a person can have is roughly 150. (Obviously, this number fluctuates depending on where a person falls on the introvert/extrovert scale.) More than that, and we start having problems keeping everyone straight.

So, as companies scale up, they suffer the same problem. It’s not so much the number of employees, but the number of relationships between employees. There’s a nifty equation that maps this out.

The number of relationships starts to get unmanageable as the groups increase. A team of 6 has to manage 15 links. A team of 12 increases exponentially to 66 links. And a small business of 50 people has to manage an astronomical 1225 links.

Coordinating and communicating between that many people has a cost: productivity and quality. “The larger a group, the more process problems members encounter in carrying out their collective work …. Worse, the vulnerability of a group to such difficulties increases sharply as size increases,” said J. Richard Hackman, a noted organizational psychologist.

Pizza party

So what does group theory have to do with quality code? Lots. Think about how big your current team is, right now. Chances are, it might be too big for the optimal group size.

Jeff Bezos famously suggested that the best teams should be limited to only the amount of people that can be fed by two pizzas. Assuming non-ravenous team members, logistically this means an ideal team should have about 6 people at most. (I call shenanigans – I can eat a whole pizza myself. What if those other five people are pretty hungry?)

People preform worse in bigger teams; as the group size increases individual members display more stress. It becomes harder to know where to turn because there are just too many people. Relational stress makes it difficult to effectively communicate. And this inability to just talk it out is what sinks big groups.

Talk, talk, talk

Creating code is difficult work. Creating quality code is even harder. Christiaan Verwijs has a fascinating article on how to create quality code. But as it turns out, all of his tips and tricks mostly boil down to… communication.

Communicating effectively and clearly is a skill, a talent, and an art. Things get lost in translation all the time. But being able to plainly state goals and shared expectations means everyone on the team is on the same page. No one wants to raise their hand and ask what might be a stupid question in an all-hands meeting at a big company. But in smaller, more intimate settings, an equal exchange of ideas is possible.

This is important in all aspects of life, but definitely in writing code. Quality is in the eyes of the beholder; making sure everyone has a shared definition of what “good code” looks like is half the battle. And to do that, you need to talk. And to do that most effectively, you should be in a two-pizza-party -sized group.

So the next time you’re in a staff meeting, have exactly two pizzas delivered. If there’s enough slices to go around, congrats, your group size is optimal for quality work. If not, it may time to divide into smaller groups and also get more pizza.