What is the rational behind the “two-pizzas” team
Two-pizza teams: an Amazon best practice but not only
There are not many IT concepts / organizational concepts that are as famous as the “two-pizza teams” motto of Amazon.
Jeff Bezos once mentionned that he had instituted a rule: the teams in Amazon should be small enough to be fed with 2 pizzas. The idea behind that was to increase their efficiency: intuitively, less people means less need of coordination and keeping people up to date
This rule is so “catchy” that IT literature makes numerous references to it:
- Agile theory emphasizes the idea of small delivery teams <10 people auto-organized
- DevOps advocates small, market-oriented, pluridisciplinary teams in order to stimulate autonomy and reduce technical dependencies
- Some famous “small” product teams are renowned: Apple’s iPhoto was built by 5 developers (source); there were 13 people in Instagram product teams when it was acquired for 1 billion by Facebook (source)
Bref, smaller teams appears to be more relevant to deliver software.
Why less is better: fewer people enhances communication
As we bring more people into a project, the communication complexity increases quadratically:
- If there is only 3 people in the team => 3 communication links;
- If the team is composed of 6 people => 15 communication links;
- If the team is composed of 12 people => 66 communication links.
Thus, we see that by adding people, the number of intercommunication grows way more than only the number of people added: between 6 and 12, we multiply by 4 not by 2 the intercommunication possibilities.
There’s another way of seeing it; if we have one team already formed and we decide to add one people in the team, we generate a lot of new intercommunication possibilities:
- From 3 to 4 people ->we add 3 communication links;
- From 6 to 7 people -> we add 6 communication links;
- From 12 to 13 people -> we add 12 communication links.
We see that the number of new communication links = the number of people in the initial team, logically each initial teammember has 1 link with the new teammember.
The anthropologist Hackmann also made this reasonning and points out the “process problems” that get exponentially more severe as the number of people in a team grows. He identifies two main issues:
- The first is the communication links as explained before, the intrinsic complexity of “keeping anyone up to date”;
- The second is the fact that larger teams will get overconfident with the false feeling that they will be able to be more efficient as they are more numerous.
The “more resource antipattern”: why adding more people to an ailing project is probably making things worse
This reasonning has initially been introduced by Jeff Brookes in The mythical man-month with the following story / vicious circle:
- An ailing project is experiencing delays
- Therefore, the sponsors bring in more people
- Therefore, it adds complexity regarding communication for the reasons presented above
- Therefore, the delays are more severe
In other words, increasing the number of people on a delayed project is unlikely to make things better; quite the opposite actually, it’s surely making things worse.
To illustrate this point, Brookes uses the strong metaphor of tarpits. Big projects are like dinosaurs in tarpits. Bringing more people here would be the false belief that struggle and move in order to escape the tarpits will make things better. However, struggling and moving in tarpits is only making the situation worse.
Furthermore, it’s not only intercommunication that’s making things worse. When you add new people to a preexisting team, it also implies: (i) getting to know each other to achieve a good team dynamics; (ii) upskilling newcomers; (iii) performing work to secure contracts and HR aspects.
Reversely, smaller teams enable better communication which generates numerous benefits
By now, we’ve made clear that bigger teams are never the solution. Here are some illustrations of why the bettered communication in smaller teams that can be fed by two pizzas make them way more efficient.
On the skills level:
- Team members can be upskilled more quickly
- Better pluridisciplinarity therefore a more reactive team
- Reduced tendency to rely on experts that always risks to create bottlenecks
On the alignment level:
- A smaller team will be more engaged and solidar
- It’s also easier to orient fewer people towards a goal
- Fewer people will feel more accountable : that’s the Kitty Genovese effect
On the technical level:
- Smaller teams will more easily work in smaller batches with more incremental developments
- This will make continuous delivery easier with numerous other advantages
- As a consequence of Conway law, independant teams will generate modular and decoupled software components
In fine, your project will be more efficient, deliver faster and your teams will be happier.
If you are interested in making making tech efficient with right-sized teams, join us:
Interested about tech like us? Get in touch with us and stay tuned for more articles to come.
