Enjoy this article? Please SUBSCRIBE to receive all the FREE updates!
This post is to reiterate what I’ve said many times before: Large teams, for the most part, suck. Large teams are necessary if the product or service requires it, but they genrally suck. Below are my reasons for this very general and somewhat unsubstantiated claim:
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!
![]() | ![]() | ![]() | ![]() | ![]() |








{ 1 trackback }