Smaller Teams = Better Results: The Two-Pizza Rule
The Two-Pizza Rule: Why small teams lead to big success
Jeff Bezos didn’t just leverage the basic insight of Gall’s Law to develop what has become Amazon’s fastest-growing internal unit — he is also responsible for popularizing one of his own tech rules.
In early 2002, Bezos decided that to reduce communication overhead and improve productivity, all of Amazon would be re-organized into so-called “two-pizza teams” — squads small enough that just two pizzas would be enough to fully feed them when working late in the office.
While this has also been interpreted as a rule for meetings — either capping the maximum size of meetings at Amazon or capping the size of meetings that Bezos himself will attend — the original formulation was an edict about team size.
WHY TWO-PIZZA TEAMS GAVE AMAZON A STRATEGIC ADVANTAGE
For analyst Benedict Evans, the two-pizza rule has been a crucial structural advantage for Amazon.
The root of the two-pizza team idea was Bezos’ attitude toward both centralization and communication. Bezos wanted Amazon to remain nimble even as it grew, and that started with encouraging independent decision-making rather than an over-reliance on hierarchy.
And Bezos hated the overhead created by excess communication. In “The Everything Store,” Brad Stone quotes Bezos as saying that “communication is a sign of dysfunction. It means people aren’t working together in a close, organic way. We should be trying to figure out a way for teams to communicate less with each other, not more.”
Source: Getty Images
The main advantage this conferred upon Amazon was simple: smaller and independent teams meant the ability to spin up new teams much faster, giving Amazon the power to scale more cheaply, explore new ideas easily, and ultimately ship more products to customers.
While many of the new initiatives spearheaded by these small teams have failed, some — like Prime, Kindle, and AWS — have become core businesses for Amazon.
For Bezos, it comes back to the idea of building a corporate structure that can generate the maximum amount of innovation for customers. Big, centralized teams maintain companies. Small, autonomous teams find new ideas.
“We have the good fortune of a large, inventive team and a patient, pioneering, customer-obsessed culture — great innovations, large and small, are happening every day on behalf of customers, and at all levels throughout the company,” he wrote in his 2013 shareholder letter. “[Decentralized] distribution of invention throughout the company — not limited to the company’s senior leaders — is the only way to get robust, high-throughput innovation.”
In other words, as Benedict Evans writes, “you don’t (in theory) need to fly to Seattle and schedule a bunch of meetings to get people to implement support for launching make-up in Italy, or persuade anyone to add things to their roadmap.”
There is a machine, and then there is a machine to build the machine, says Evans. And Amazon’s two-pizza rule ensures that the company, aside from being a ubiquitous tech leviathan, can operate a machine to build more Amazons.
SPOTIFY’S SQUADS COMBINE AUTONOMY WITH RESPONSIBILITY
The concept of small, autonomous teams has become extremely popular in the tech world over the years, and some of the biggest and most successful companies have adopted similar ideas to the two-pizza rule to help make their people more efficient and productive.
Spotify is one example of a company that abides by the smaller-is-better rule when it comes to organizational structure.
The music streaming app organizes teams into 8-person squads, with the function of each squad determined autonomously, rather than being directed from above. Each squad functions as a mini-startup inside Spotify: cross-functional, self-sufficient, and sharing the same geographical location.
One unusual feature of Spotify’s squads is the lack of a designated leader or manager, with each squad member equally responsible for results. In the vein of autonomous operations, any leader of these squads emerges organically and informally. The company uses the squad structure to encourage greater innovation, disruptive thinking, and complete accountability, without the burden of excessive control.
Squads with similar functions across the organization are then grouped under tribes, chapters, and guilds. While tribes act as incubators and provide support for the development of squads, chapters connect employees based on specific skill sets such as web development and quality assurance. Guilds are a way to encourage knowledge sharing across the organization, irrespective of squad, function, or location.
This organizational structure is designed to support a bottom-up approach at Spotify. For example, best practices at the music streaming company only emerge after enough squads have adopted them.
Furthermore, by keeping teams highly autonomous, the structure “lowers the cost of failure” through ensuring that “failure has a‘limited blast radius’ and affects only part of the user experience,” according to Michael Mankins and Eric Garton of the Harvard Business Review.
In the vein of Bezos’ idea of excessive communication being wasteful, Spotify looks to make communication more efficient by seating squads, guilds, and tribes that need to coordinate closer to each other.
NOT EVERYONE IS SATISFIED WITH TWO PIZZAS
According to organizational psychologist J. Richard Hackman, the more interconnections you have between people, the slower your decision-making and the higher the management costs for the organization.
As you add people to an organization, the number of communication links increases exponentially.
“The cost of coordinating, communicating, and relating with each other snowballs to such a degree that it lowers individual and team productivity,” writes blogger Janet Choi. Two-pizza teams solve this inherent scaling problem by artificially capping the number of links.
Despite the organizational clarity derived from the two-pizza team, not everyone at Amazon and in the wider tech world is a fan of the rule.
Some former Amazon employees and others believe the strategy was counterproductive, and some think that building products using two-pizza teams creates a disconnected user experience.
According to Brad Stone, the concept of two-pizza teams was unevenly applied throughout the Amazon. It took root most of all in engineering, while the idea barely touched the finance and legal departments.
Additionally, each team had to set up its own “fitness function” — some kind of quantitative, linear equation that could be used to judge whether that team succeeded or failed in its mission. For a marketing team, that might be the average email blast open rate multiplied by ensuing order value.
Yet, Stone writes, making some teams define this function for themselves was like “asking a condemned man to decide how he’d like to be executed.” For others, it was merely ineffective.
Kim Rachmeler, former VP at Amazon, said, “Being a two-pizza team was not exactly liberating. […] It was actually kind of a pain in the a**. It did not help you get your job done and consequently the vast majority of engineers and teams flipped the bit on it.”
Small, disconnected teams run the risk of producing disjointed products that don’t contribute to a seamless experience, according to product management consultant Matt LeMay.
For LeMay, the most important aspect of a product for a customer is not the individual features of a product, but how those features come together to deliver a cohesive experience.
Given the vast number of products that Amazon has put out over the years, and how cluttered many of its website’s menus can seem, it’s fair to say that Amazon’s drive for two-pizza teams has not been without its drawbacks.
Jeff Bezos wanted small, autonomous teams that could be “independently set loose on Amazon’s biggest problems,” as Brad Stone writes. These teams wouldn’t have to waste cycles communicating with other teams, and they would each have all the resources and people necessary to launch new products. The result, Bezos thought, would be more creative offerings and faster results for customers.
Though not without its detractors, Bezos’ idea that over-communication between teams risks stoking inefficiencies is now commonly implemented at companies like Google and Spotify.
As for personal experience, I agree that the smaller team, in general, will produce a better product. The smallest team is ONE, and since I had the experience of developing TeleMagic completely alone for the first several years of its existence, and with only one other developer taking over for the next several years, there is no question in my mind that the smaller the team, the better the product. (Michael McCafferty)