The fundamental issue with large organizations is consensus-building. Consensus is needed to move forward on most projects due to the interdependent nature of how we build our technology systems. Since systems are typically large and span multiple teams, once one team makes changes to their part of the system, it may have upstream and downstream effects that they did not anticipate (on subsystems owned and maintained by other teams). The following are some examples:

• Upstream effect: The updated subsystem now operates so quickly that it is straining the data feed with pulls for new data
• Downstream effect: The updated subsystem is generating data much more quickly which is overwhelming the ability of the downstream consumer to process the feed

With the broad adoption of decoupled systems and SOAs, we solve this from a technology aspect, but the organization has yet to adapt to this new reality. If we have decoupled systems, why not decoupled organizational units? Enter the two-pizza team. It's been called many different things by different organizations: tiger teams, DevOps teams, build-run teams, black ops teams, and so on. For our purposes, we will refer to them as CND teams.

These teams build, run, and maintain their systems, but why are they referred to as two-pizza teams? They need to be fed by a maximum of two pizzas, meaning that the team can't have more than 8-12 people. Where did this limit come from? Fundamentally, making decisions and coming to a consensus becomes difficult in larger groups. This is caused by the increasing number of communication links required between n number of developers. As n increases, the number of communication pathways scales exponentially:

Once a team surpasses 10 people, the number of connections between each individual increases exponentially. The trend has been exponential all along, but it becomes much more noticeable. The converse way of making this argument is: smaller teams can reach consensus more quickly. This is the origin of the two-pizza limit.