At Calcey we often like to say that we are in the business of providing ‘two pizza’ product engineering teams to fast scaling technology companies, looking to take their software product ideas to market quickly. Why two pizza teams? Well, simply because it works. A concept popularized by Jeff Bezos, ‘two pizza’ teams is not simply a management fad, but an idea backed by the science behind how people coordinate and communicate within teams.

Bigger isn’t always better      

As the story goes, the coining of the ‘two pizza’ rule was sparked by a discussion at an Amazon corporate retreat. One manager suggested that teams should communicate more with each other, a seemingly reasonable suggestion that Bezos shot down to everyone’s surprise. “Communication is terrible” he said, but the way to fix it was not to communicate more. He went on to explain that small teams make it easier to communicate more effectively, to stay decentralized and moving fast, while encouraging high autonomy and innovation. The rule of thumb he coined to summarize his idea was that a team should not be larger than two pizzas can feed. Let’s take a look at the science behind his thinking.

Communication becomes more problematic as team size grows

The late Harvard psychologist, J. Richard Hackman, bluntly stated, “What he found was that number of links between people within a team increased at an exponential rate as the team size grew. Management – essentially the task of handling these links, consequently becomes harder.

The formula for calculating the number of links between people in a group is as follows;

n(n-1)/2, where n = number of people

Let’s look at how this works as team size increases.

 

As group size increases, the links start to get unwieldy

  • A basic two-pizza team size of, say, 6, has 15 links between everyone
  • Double that group for a team of 12. That shoots up to 66 links
  • A group of 50 people has an incredible 1225 links to manage

Every steep jump in links also produces a steep jump in the potential for mismanagement, misinterpretation, and miscommunication. Delays emerge from the snowballing time and effort required to keep everyone informed, coordinated, and integrated. There’s even a name for the delaying phenomenon in the software development world — Brooke’s Law, which states that:

“adding human-power to a late software project just makes it later.”

Put simply, throwing more bodies at a problem becomes an increasingly inefficient solution, as team size grows.

Getting lost in the crowd

Studies have also shown that larger groups also have a negative effect on motivation – a phenomena known as social loafing. In layman’s terms this is the classis result of thinking that someone else will do it, if I don’t. Bibb Latane, who demonstrated this via multiple studies described the lower sense of ownership that a members of larger teams feel as follows;

“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.”

Smaller teams get more love

Psychologists have also uncovered an emotional element that leads to deteriorating performance in larger teams – termed “relational loss”. Research into how team members felt within teams of varying sizes revealed that people feel confused about where to turn and who to turn to, for support, in larger teams. Think back to the last time when you were part of a tight knit team where you regularly interacted and spent time with everyone on a daily basis and this should seem fairly obvious.

Larger teams need to rely on formal structure and roles. When asking a peer for help becomes a formal request, it is likely to be done with some reluctance. It is easy to underestimate the overall effect of informal links within a small team that make work more enjoyable and socially rewarding, until workers start feeling disengaged and stifled by bureaucracy. Anyone who has gone through this experience can attest to how both individual and team output as well as creativity and satisfaction at work, all take a collective nose dive in such a situation.

Our formula for happy teams

So is there a magic number for optimal team size? Bezos’s two-pizza rule works out to at most 6 or 7 non-ravenous people. At Calcey we typically keep our extended teams to this size. It been rare occasion indeed when we had a team of more than 10.

Transparency is built into our mode of operation to ensure that everyone within a team is on the same page. Teams use email groups or public chat channels to coordinate work, hence everyone has access almost all communication. Every team operates with a significant amount of autonomy, in everything from scheduling to how work is allocated among members.

There is certainly room to improve, but we feel we are on the right track. Last year we got the opportunity to develop a business intelligence dashboard for PayPal’s CEO and global management to keep track of the company’s metrics in real-time. The catch – they needed it done within a few weeks, whereas PayPal’s internal team had estimated few months for the project. We took on the challenge and put one of our best ‘two pizza teams’ on it. They took full ownership for delivering on a seemingly impossible timeline, coordinated with several PayPal teams based around the globe and worked around the clock to deliver the project in 6 weeks.

What’s been your experience with ‘two pizza’ teams? Comment below.

References:

Why teams don’t work? 

Brooke’s Law 

Why individuals in larger teams perform worse