So you have an idea, and you kick it about with some people and refine it, until it's time to take it out into the world. Now that insight gets paraphrased and simplified and reduced to sound-bites, and those sound-bites get passed around by people who don't necessarily understand all of the context behind the sound-bite. In fact, I wrote about this process already: SMAC My Pitch Up.
In what we laughingly call "software engineering", the current favourite delaying tactic to postpone the onset of cargo cults is the two pizza rule. The rule was coined by Jeff Bezos of Amazon: if a team couldn’t be fed with two pizzas, it was too big1.
The problem with the two pizza rule is not that it doesn't work. Small teams can indeed get a lot more done in a hurry than big teams, which inevitably get bogged down into management by committee. The problem is that very quickly you end up with many two-pizza teams, all eating in different rooms and not talking to each other.
Sooner or later, some bright spark will suggest that there should be a committee to manage the interaction between the various teams. In accordance with the Iron Law of Bureaucracy, the requirements of communication proliferate until people in the individual two-pizza teams are spending more time on formal communication processes than on the original purpose that they sat down to thrash out over pizza.
Congratulations: your two-pizza team just reinvented the org chart. As tempting as it may be to set sail in your own pocket battleship, it's generally better to figure out a way to achieve your goals within the corporate structure, or without upending it entirely. Revolution sounds fun, but evolution actually gets results.
Incidentally, having grown up in Italy, this rule has always confused me. Does Jeff Bezos mean that the ideal size of a team… is two people? One pizza each? Because sure, that will cut down on unnecessary arguments and politicking within the team, but it’s not much manpower. ↩