Enjoy this article? Please SUBSCRIBE to receive all the FREE updates!
I’ve written about the importance of team size before, here, here, and here. Previously, this is what I said:
I’ve written about efficient teams before here and here. At Amazon, there is a concept of a 2-pizza team: no team should be larger than 2 pizzas can feed. It’s a great approach to team size. In my short career, I’ve learned how true that rule is. Here’s another thing I’ve learned –
- 2 people are smarter than one
- 3, 4, 5, 6, 7, 8 people are smarter than 2
- a team larger than 9 people is just one big dumb blob
Ok, that’s not true at a wholesale level, but it sure feels like it. A small team with highly smart and capable team members can do much more than 10 mediocre team members. The Wisdom of Crowds mentality doesn’t work that well when it comes to efficiency in teams — especially software teams.
A more quantitative explanation is as follows:
One of the root causes of failure in projects is communication — either a lack thereof, or miscommunication. Large teams are inherently vehicles for bad communication. This is basic combinatorics — for a given project, suppose there are persons A and B. In this scenario there is only 1 communication link. Add person C, now we have 3 communication links, A-B, B-C, C-A. Add person D, then we have 6; Add person E, then we have 10 communication links. Inductively, as team size grows, the raw combinatoric communication link counts grows geometrically, not linearly. To demonstrate this, we use basic statistics of the form n-choose-r, where !, such as n!, is equivalent to n factorial, to arrive at the formula for how many pairs we can choose from n items:

For the number of pairs, we can reduce the above formula to the following:

Visually, as team size grows, the communication links grows non-linearly, but exponentially:

A Rejoinder
Do not let the above dissuade you from large teams; if the product requires a large team, then that is what is needed. Caution, is what I am arguing here. The facts are that the larger the team, the more communication channels there are and the entire process then becomes more error-prone. If the product requires a large team, then expect the above challenge and manage it.
A Conclusion
There is wisdom in Bezos’ notion of the 2-Pizza Team. Small teams work incredibly well. Also, there is wisdom in Toyota’s usage of “The Big Room” as a way to mitigate defects caused by large teams. A combining of the two will most likely make for a great team and a successful product.
Enjoy this article? Please SUBSCRIBE to receive all the FREE updates!
![]() | ![]() | ![]() | ![]() | ![]() |








{ 2 comments… read them below or add one }
Concerning the “Big Room”, there is a bit of research which examined this phenomenon.
“…having development teams reside in their own large room…had significantly higher productivity and shorter schedules… The teams reported high satisfaction about their process and both customers and project sponsors were similarly highly satisfied.”
Teasley, S., Covi, L, Krishnan, M. S., and Olson, J. S. (2002). Rapid software development through team collocation. IEEE Transactions on Software Engineering, 28(7), 671-683.
“Teams in these warrooms showed a doubling of productivity. Why? Among other things, teams had easy access to each other for both coordination of their work and for learning, and the work artifacts they posted on the walls remained visible to all.”
Teasley, S., Covi, L, Krishnan, M. S., & Olson, J. S. (2000). How does radical collocation help a team succeed? Proceedings of the 2000 ACM conference on Computer supported cooperative work, 339-346.
And, then from the Agile software literature, in the book Agile Software Development, Cockburn talks about radical collocation where communication travels through osmosis. Ultimately, people ask more questions and people overhear important conversations. Intentionally putting people phsycially closer also improves the communication.
Nice blog. Keep up the good work!
Tim
Nice post, Pete.
If you’re interested, I had a post a couple years back criticizing the idea of two pizza teams at Amazon:
http://glinden.blogspot.com/2004/08/amazoncoms-two-pizza-teams.html
The basic issue is that the teams do not end up being truly autonomous and attempts to make them independent end up aggrevating communication problems.
Instead of two pizza teams, I argued, Amazon should focus on promoting informal networks (cross-team communication).
{ 2 trackbacks }