Utah Open Source Planet

Team size can make a big difference in the success of your service or product.  What is counterintuitive for most people is that the larger the team size, the lower the likelihood of success for your service or product.  Why?  Entropy can set in and large teams are inherently bad vehicles for communication.  In what follows, I show quantitatively how team size does have an impact on the effectiveness of communication and the eventual success of the service or product.

I’ve written about efficient teams before here and here.  When I was at Amazon, teams were organized into small, delta teams called "2-pizza teams": 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 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, or hand-off’s.  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 — provided you have the right people — work incredibly well.  Also, 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.

+++++

Please find originally-written articles on Queueing Theory below:

• Queueing Theory: Part 1
• Queueing Theory: Part 2
• Queueing Theory: Part 3
• Queueing Theory: Part 4
• What is Waste?
• On Time-Traps and Waste
• Call Centers as Queueing Systems
• Travel Time & Waste
• Little’s Law for Product Development
• YouTube’s Queueing Properties
• Psychology of Queueing and Disneyland
• Queueing, Disneyland, and FastPass
• Multi-Tasking Leads to Lower Productivity
• Queueing Theory and Terrorism
• On Queueing Theory and Elevator Mirrors
• Queueing Psychology at the Gas Pump
• Psychology of Queueing, Haunted Houses, and Halloween
• The Variability Tree
• Attitude and the Psychology of Waiting - The Psychology of Queueing

For a few articles on Operations, lean and six sigma, please visit the links below:

• The Gemba is the Dojo

• Managing Constraints Under Peak Volumes

• Order Pipeline of Events

• On Game Theory

• Series on Queueing Theory

• Applied Regression Analysis

• 5S

• Click-to-Ship Processes

• Kanban Sizing and "Pull"

• Lean at Krispy Kreme

• Theory of Constraints and Camping

• Lean for Software Development

• Don’t Waste the Customer’s Time

• Featuritis and the Focus on the Customer

Share This

Aza Raskin is the founder of Humanized, the son of Macintosh inventor, Jef Raskin, and an all-around good guy.  A few months ago, Aza Raskin agreed to answer several readers’ questions.   In today’s post, Aza Raskin tackles a reader’s question about Product Management, cooperations with other groups, throwing stuff over the fence, why large teams generally suck, and political in-fighting and politics.

I work as a product manager for a technology company in the valley.  In large companies like mine, the department of Product Management, Software Engineering, and Customer Experience work together, but in a clunky way, to build a product.  What is the best way, in your opinion, to infuse the Humane Design Principles in a hot political environment?

Maybe you should start an "Ask Aza" column, like a Dr. Phil segment, or something.

Successfully bringing a product to market is a holistic endeavor.  User requirements drives customer experience; customer experience drives marketing; marketing drives user requirements.  Nobody should feel that a set of requirements has been "thrown over the fence".  When this happens, the recipient-of-the-throw is beholden to an abstract deliverable and is no longer connected to the end-user.  That’s a real problem.  Combating this requires a tight-feedback loop which is most easily created with a small team: engineering gets to see the market research come in, and the usability people can guide engineering throughout the actual creation process.

In an ideal world, everyone on the team would have a foot in engineering, design, and marketing.  Unfortunately, this isn’t always possible.  What is possible is that we can create small, tight teams that collectively have intimate knowledge of all three disciplines.

The small-team idea is by no means new.  In the book In Search of Excellence, Tom Peters explains over-and-over again that it’s the small groups; skunk works, home-brew projects, and strike teams that drive innovation at companies both large and small.  The most successful teams are those of 10 people or less — preferably between 4 and 8 — that include people from the required disciplines.

By keeping teams small, products don’t get commitee-ized.  The team is directly responsible for success.  Success is dependent on making a product that meets the needs of the user and to the user, the interface is the product.

P.S.,  I like the idea of an "Ask Aza" column: Anything that’s alliterative must be good!

Aza’s point above about team size is important, and one that I’ve discussed before.  Quantitatively, we can show why, in general, large teams aren’t the best way to go.  Here is what I wrote back in Ocotober 15, 2006:

Stinky Large Teams: A Proof

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.

+++++

Other articles in the "Ask Aza Raskin" Series:

1. Ask Aza Raskin
2. Aza Raskin on Poka-Yoke & The Humane Interface
3. Aza Raskin on Quasimodal Design and The ATM
4. Aza on Feature-Bloat and Site Clutter
5. Aza on Google Search Results Page
6. Aza on Cooperation and Team Size

+++++

Articles on Queueing Theory

• Queueing Theory: Part 1
• Queueing Theory: Part 2
• Queueing Theory: Part 3
• Queueing Theory: Part 4
• What is Waste?
• On Time-Traps and Waste
• Call Centers as Queueing Systems
• Travel Time & Waste
• Little’s Law for Product Development
• YouTube’s Queueing Properties
• Psychology of Queueing and Disneyland
• Queueing, Disneyland, and FastPass
• Multi-Tasking Leads to Lower Productivity
• Queueing Theory and Terrorism
• On Queueing Theory and Elevator Mirrors
• Queueing Psychology at the Gas Pump
• Psychology of Queueing, Haunted Houses, and Halloween
• The Variability Tree

+++++

For articles on Operations, lean and six sigma, please visit the links below:

• The Gemba is the Dojo

• Managing Constraints Under Peak Volumes

• Order Pipeline of Events

• On Game Theory

• Series on Queueing Theory

• Applied Regression Analysis

• 5S

• Click-to-Ship Processes

• Kanban Sizing and "Pull"

• Lean at Krispy Kreme

• Theory of Constraints and Camping

• Lean for Software Development

• Don’t Waste the Customer’s Time

• Featuritis and the Focus on the Customer

Share This

It’s been a while now since I was employed at Amazon.com, but I still greatly admire Jeff Bezos and Amazon.  Culturally, it was hands-down the most brutal and cut-throat environment, but one that really brought out the best in you — not from a people or relationship perspective, but from an innovation and business-thinking perspective.  Indeed, the cut-throat culture invited very heated debates and some bridges would be burned along the way, but the next day people move on.  This month’s interview on Harvard Business Review underscores my point and also shares Bezos’ views on Lean and Six Sigma (I can personally share many stories on this topic at Amazon…).  Much is also said about how Amazon follows the Start with the Customer and then Work Backwards model, which I’ve also spoken about much on this blog.  The article is a good read.  Here’s what Bezos specifically says about Lean and Six Sigma and defect reduction:

As the business grew and moved into new areas, you must have felt challenged to keep up on a personal level. What have you had to learn along the way?

Something we haven’t talked about, but that is super important in our culture, is the focus on defect reduction and execution.  It’s one of the reasons that we have been successful for customers.  That is something I had to learn about.

Well, by “learn” I mean I literally learned a bunch of techniques, like Six Sigma and lean manufacturing and other incredibly useful approaches. I’m very detail oriented by nature, so I have the right instincts to be an acceptable operator, but I didn’t have the tools to create repeatable processes and to know where those processes made sense. Before I started Amazon, I was with a quantitative hedge fund. That work is very disciplined and very analytical, but it’s not a question of designing a repeatable process. It’s not like a car-manufacturing plant, where the work has to be done in a defect-free way, in the same way over and over and over—or anyway, that piece of it is not as important. But here, that execution focus is a big factor, and you can see it in our financial metrics over the past ten years. It’s very obvious when, for instance, we look at the number of customer contacts per unit sold. Our customers don’t contact us unless something’s wrong, so we want that number to move down—and it has gone down every year for 12 years. That’s big-time process management. We try to implement those kinds of processes in various places. They’re most naturally applied in our fulfillment centers and in customer service and so on, but we’ve actually found that they can be useful in a bunch of different things.

When you are inexperienced with disciplined process management, you initially think that it’s equivalent to bureaucracy. But effective process is not bureaucracy. Bureaucracy is senseless processing—and we’ve had some of that, too.

Share This