Why Large Teams Suck
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.
WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.
If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.
Additional comments powered by BackType
[...] Amazon and Google do a lot with small teams and I think they have it right. I have worked on small IT teams for several years now and find it great. Combine with agile management methods small teams allow for great focus (you are naturally guided toward appropriate project sizes instead of huge monster projects), great results and joy in work. I have no desire to work in large teams. [...]