Too Many Cooks in the Kitchen
Team size can make a big difference in the success of your service or product. What is counter-intuitive for most people is that the larger the team size, the lower the likelihood of success for your service or product. Why? Communication Entropy can set in and large teams are inherently bad vehicles for communication.
More sinister, however, is that the larger the team, there is a higher likelihood of accountability and responsibility being diffused across the team and when everyone is in charge, then nobody is in charge. A good friend of mine calls this situation a state of affairs where “there are too many cooks in the kitchen” — but the big difference is that the Kitchen acts as an Obeya since all the actors are in the same location.
In this article, I quantitatively show the inverse relationship between team size and productivity & how team size does impact the effectiveness of communication and accountability & the eventual success of the service or product.
Here’s my hypothesis:
- 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 a big dumb gelatinous blob (acronym: BDGB)
Okay, 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.
A more quantitative explanation is as follows: One of the root causes of failure in projects is communication — either a lack thereof, miscommunication, overcommunication, or hand-off’s. Large teams are inherently vehicles for bad communication.
Indeed, 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:
“Reply All”
A classic instantiation of this general rule that I’ve explained is the email diffusion through the “Reply All”. In most cases, when somebody sends a message via “Reply All”, either nobody reads it, people do read it but do nothing about it, or the reader — in kind — does a “Reply All” and continues the vicious cycle. At the end, nothing happens and people remained confused.
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 Toyota’s usage of Obeya or “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.
Comments
Nice mathematical proof of something that I already knew but based on my gut feeling and no real logic. When working with introducing Lean and Agile thinking into software development I often make the analogy of having a drink with your friends. If you are a group of friends that has known each other for some time and have a deep relationship you can go out in groups of 4-6 people without organizing a damn thing. But if your group gets bigger or there are a lof of uncertainty and new group members someone always have to decide before going out where you are going, otherwise you will end up in a street corner arguing about where to go. But your mathematical proof sure is nicer than my drinking analogy.
I also really liked your 1,2,3 list regarding the BDGB. Very funny.
Please feel free to check out my blog regarding lean and agile software development within Sony Ericsson in Sweden (http://aenyberg.blogspot.com)
Best regards,
Anders
Not to nitpick, but the word should be Oobeya or Ōbeya. As it is (without the macron-O), the word would be read as ‘obeya’ or ’small room’.
@Mark,
Thanks for reading.
I appreciate the correction — you’re right — the growth model is quadratic, not exponential. My mistake.
Leave a comment
Additional comments powered by BackType
Nicely done – a bit of probability in with some pragmatic wisdom!
Two other points:
1. There’s a difference between working IN a team and working AS a team, and
2. Check out http://www.qv-system.com/Mail%20Paradox11.pdf for a thoughtful piece by Takashi Tanaka, a wizard obeya consultant who got his chops at Toyota in the late 1990s, on the very topic of email overload due to bad “Reply All” habits.
Best,
Jeff