If the question is how to make a team more productive, the answer, according to Jeff Bezos, is clear: with two pizzas.

And it’s not that Amazon can’t afford to buy pizza for every employee, it’s that it has a lot to do with the optimal size of teams.

Amazon is one of the largest companies in the world, and its founder and former CEO Jeff Bezos is one of the richest people. At a company like Amazon, productivity, talent management, and team synchronization are all important, and ensuring that everything runs smoothly is the responsibility of a rule that is as curious as it is useful and entertaining: the two-pizza team rule.

The “problem” of scale. As Daniel Slater, global director of innovation culture at Amazon AWS, explains, when Amazon began, its structure was focused “on rapid agility and continuous value for customers.” Amazon was an “invention machine” at the time. That’s why hiring and organizational structure were a priority. The problem is that Amazon, which started as an e-commerce company, scaled.

It has escalated, and how.

When the company was smaller, teams “were more centralized and tightly coupled,” but as the firm began to grow, that structure led to more sluggishness and inefficiencies. To solve this problem, “we radically changed our technical architecture to what’s called a microservices architecture,” Slater explains. “We broke our monolithic architecture into a vast network of unique and independent services,” allowing us to launch new products and offerings more quickly.

But that is not all. To maximize its ability to stay close to users and their needs while launching new products and services, Amazon invented a new way to organize teams, Slater says. Instead of large teams, the company chose smaller, more agile teams that could take advantage of the microservices architecture. It did this by using a rather peculiar rule.

Two pizza teams. The idea is simple: no piece of equipment should be so big that it requires more than two pizzas to serve. Not because it burns a hole in Amazon’s books by buying an average of three more ingredients from the nearest Domino’s, but because “smaller teams minimize communication channels and reduce bureaucratic overhead and decision-making.”

It’s assumed that two pizzas can be eaten by about ten people, although I’m willing to fight that notion with all my might. In any case, “two-pizza teams” is a somewhat contrived way of referring to teams of fewer than ten people. That size “allows two-pizza teams to spend more time with their customers and to continually experiment and innovate for their benefit,” says Slater.

Benefits of Small TeamsAs Amazon explains, small teams increase “engagement and learning” and reduce the so-called Ringelmann effect (individual performance declines as the group gets larger, and vice versa).

Citing research by Hackman and Vidmar, Amazon claims that smaller teams “also improve employee satisfaction” because “in larger teams, individual contributions are less recognizable and individual contributions to specific areas become more fragmented.” Smaller teams, Amazon says, also allow for faster experimentation and lower costs of failure.

One team, one product. How does Amazon implement these “two-pizza teams”? Easy: one team for each product or service. According to Daniel Slater:

“Instead of maintaining complex systems or solving problems that span multiple services, business lines, or customer segments, two-pizza teams focus on one service or offering and only the customers who use it. This single-minded approach helps improve efficiency and scalability.

More pizzas. If the team grows, which is likely if demand increases, “we look for a way to split it into separate two-pizza teams working on a single-threaded subset of the service.” However, Amazon recognizes that this structure isn’t for everyone, and that there is an equivalent.

“Two-pizza teams aren’t perfect, and they’re not immune to limitations; one example is that with so many autonomous teams with a single process, working quickly to meet their customers’ needs, there’s a risk of duplication and development into silos,” says Slater. Collaboration across teams is also necessary to ensure rapid experimentation is effective, and to share mistakes and learnings.

Image | Flickr (Smithsonian), Pexels