Powering Innovation and Speed with Amazon’s Two-Pizza Teams

Amazon, like many companies that started during the Dot-com era, was organized for rapid agility and delivering constant value to customers. In his very first Letter to Shareholders in 1997, Jeff Bezos discussed the importance of obsessing over customers and delivering continuous long-term value on their behalf – even at the expense of short term corporate profit. This relentless obsession over customers relied on hiring and maintaining an organizational structure of empowered builders who were excited to wake up every day to solve customers’ thorniest problems, and invent on their behalf.

“Setting the bar high in our approach to hiring,” Jeff wrote, “has been, and will continue to be, the single most important element of Amazon.com's success.”

This was easier to accomplish in those early days, when the business was focused on e-commerce, and teams – and the technical architecture they relied upon to deliver rapid innovation – were more centralized and tightly coupled. But over time, as Amazon expanded the number of businesses and new innovations to meet our customers’ need, we began to experience strain in the speed and agility with which we could execute. The desire to remain an “invention machine,” as Jeff outlined in his 2015 Letter to Shareholders – a company that can “combine the extraordinary customer-serving capabilities that are enabled by size with the speed of movement, nimbleness, and risk acceptance mentality normally associated with entrepreneurial start-ups” – began to be impacted. Our tightly coupled architecture and organization were simply not helping us move as fast as we wanted, or needed, to be.

To address growing sluggishness and inefficiency, we fundamentally changed our technical architecture to what became known as a microservices architecture. We decoupled our monolithic architecture into a vast network of single, standalone services. By doing so, we were better able to rapidly launch new innovations and offerings, quickly iterate existing services based on customer’s ever-changing needs, and constantly experiment with new ideas to invent on customers’ behalf.

But it wasn’t good enough to simply overhaul the technology our builders used to drive innovation. We also needed to restructure the way teams were organized to maximize their ability to stay close to customers and their needs, rapidly launch innovative products and services on their behalf, and best take advantage of the agility and speed a microservices architecture could provide. This organization structure became known as Amazon’s “two-pizza teams.”

The concept of Amazon’s two-pizza teams is straightforward: no team should be big enough that it would take more than two pizzas to feed them. Putting aside the number or the nature of toppings (we don’t have time and space to solve the “does pineapple belong on pizza?” debate here), ideally, this is a team of less than 10 people: smaller teams minimize lines of communication and decrease overhead of bureaucracy and decision-making. This allows two-pizza teams to spend more time focusing on their customers, and constantly experimenting and innovating on their behalf – the biggest priority of high-performing teams at Amazon.

Smaller teams also increase ownership and empowerment. This can mitigate the Ringelmann Effect: a tendency for individual productivity to decrease in larger groups. As team resources swell, there is less focus on individual effort as people lean more on others to shoulder the load. The magnitude of individual contribution decreases as team size grows. Inversely, individual effort increases as the team size decreases.

Smaller teams also increase employee satisfaction – a key concern as today’s organizations strive to attract and retain the best talent. A notable study by Hackman and Vidmar shows that individual satisfaction decreases as team size grows. Oftentimes in large teams, individual contributions are less recognizable, and individual ownership over specific areas becomes more diffuse.

This has been borne out in workforce studies; Gallup’s "The State of the American Workplace" study showed that organizations with fewer than 10 employees scored engagement levels of 42% or higher, whereas the average engagement level for larger organizations was below 30%.

But Amazon’s two-pizza teams aren’t just about size. A key factor in enabling constant innovation and speed in a two-pizza team structure is empowering them with a single-threaded focus.

► Listen to the podcast: C-Suite Strategies for Leading Significant Change

Two-pizza team isn’t solely about size as much as it is about fostering and pushing ownership and independence down to the team level.

At Amazon and AWS, two-pizza teams have single-threaded ownership over a specific product or service. Rather than maintaining complex systems or solving problems spanning multiple services, lines of business, or customer segments, two-pizza teams are focused on just one service or offering, and just the customers who use it. This single-threaded focus promotes efficiency and scalability. Two-pizza teams’ roadmap – including the tradeoffs and prioritizations they need to make – are singularly focused on innovating on behalf of just their service and the customer segment that uses that service.

The two-pizza structure also promotes team accountability. Two-pizza teams do not hand over something they’ve launched to another team to run. This single-threaded ownership extends across the full customer experience and the entire lifecycle of a two-pizza team’s product or service.

As such, two-pizza teams need to stay on top of every part of their service, with a clear charter and a tightly defined mission. They need to remain close to their customers, and create the right tracking mechanisms, metrics, and KPIs to ensure their service is constantly delivering value to customers.

This also requires that a two-pizza team has the right resources embedded within them – engineering, testing, product and program management, operations, etc. – to help them own and run their service end-to-end.

As demands for a product or service grow, rather than expanding the team to many more members, we look for ways to split teams into separate two-pizza teams working on single-threaded sub-area of the service. This mitosis maintains a flatter organizational structure that preserves agility, autonomy, and single-threaded ownership.

In the end, a two-pizza team isn’t solely about size as much as it is about fostering and pushing ownership and independence down to the team level – from ideation to execution, from ongoing operational improvement to constant product iteration and innovation. It allows teams to run fast, experiment early and frequently, and apply learnings rapidly to constantly drive value to their customers. Faster innovation and experimentation also helps lower the costs of failure – your learnings come quicker and at lower stakes than you may have otherwise faced at later stages of development.

While the two-pizza team structure has worked for Amazon and AWS, we acknowledge that it may not be suitable for all organizations, or for every business unit. Two-pizza teams are not perfect, and are not immune to limitations; one example is that with so many autonomous, single-threaded teams running fast to meet the needs of their own customers, there is a risk of duplication and siloed development. You need the right governance structure in place to decide when and how to combine efforts that are purely replicative, while not stifling teams’ abilities to drive innovation in their areas of ownership.

With rapid experimentation, there is also a need to collaborate across teams to force-multiply success and rationalize resources. Even more important is the ability to capture and share learning from failure to better apply those lessons to future experiments, and to fine tune the direction of iteration and future investment decisions.

One aspect of Amazon and AWS’s organization that helps promote governance and oversight while enabling teams to run quickly, independently, and autonomously, is the concept of single-threaded leaders.

The role of single-threaded leaders is vital in instituting the right level of oversight to retain a team’s empowerment to innovate independently on behalf of their customers.

Today’s executive leaders realize the enormous benefit of being able to rapidly deliver innovation and digital transformation. The ability to quickly go to market with new products and services is not only crucial in delivering constant value to customers, it can also become a differentiating competitive advantage for your enterprise. But as scale and scope of the business increases, executives need to ensure they are creating the right structure and leadership to ensure teams are empowered to run fast.

The governance and management of teams must provide “guardrails” – mechanisms that allow teams to run fast and make high-quality, high-velocity decisions – rather than “tollgates” that impede speed by swelling lines of approval or coordination before allowing teams to progress with innovative experiments.

At Amazon and AWS, the role of single-threaded leaders is vital in instituting the right level of oversight to retain a team’s empowerment to innovate independently on behalf of their customers, while creating consistent mechanisms that allow the right level of inspection and directional vision. Single-threaded leaders help provide a strategic vision – and then get out of their team’s way. Team leaders need to help remove obstacles as opposed to being a barrier through which all decisions need to pass through. Small, agile, autonomous teams who obsess over their customers every day are the foremost subject matter experts on their service and customer segment.

Single-threaded leaders need to preserve their team’s autonomy to make the best decisions for the business. Single-threaded leaders’ involvement in their team’s decision-making is most often to help guide the team in situations where, even with the right data instrumentation and highest judgement, the path forward may not be clear.

One mechanism used at Amazon to facilitate a single-threaded leader’s oversight at these checkpoints are written narratives. Narratives in these circumstances help outline the customer-facing problem that has surfaced; brings information from deep analysis and data that the team gathered to inform next steps; and articulates the decision the team recommends, along with alternate paths considered and the risks and benefits of each of those paths.

While taking the time to write a narrative may seem counterintuitive to maintaining speed and constant execution, the use of narratives across Amazon and AWS has driven extraordinary benefits. One is that these documents are often highly debated and refined by the team, its stakeholders, and subject matter experts of the team’s offering and customer segment even before it lands on an executive’s desk. This fosters collaboration and diverse perspectives, challenges assumptions, and serves to refine the ideas and recommendations within the document. Ultimately, this often leads to higher quality decisions.

There are many different narratives at Amazon and AWS. Some are focused on launching new products, such as our PR/FAQ document (which stands for Press Release/Frequently Asked Questions) which is the product of our Working Backwards approach. Others are operational business reviews (often on weekly, monthly, and quarterly cadences) that provide inspection and governance on the key metrics, trends, tensions, risks, and opportunities that arise in a team’s business.

We have narratives that provide rigorous operational readiness reviews prior to the launch of any new service, diving deep to ensure aspects of a service’s architecture, its release quality and procedures, and the associated incident and event management procedures are well formulated and documented. Other narratives, such as our Correction of Errors document, are done post-mortem when a service negatively impacts customers. These documents are driven by the team that owns the service – not as a point of blame, but because as the single-threaded team that owns that service, they are closest and most knowledgeable about that service and its customers.

In these Correction of Errors (or COE) documents, the team dives deep to fully outline what happened, providing relevant quantitative analysis and data around the impact of a service’s failure and why it occurred. They peel back layers to identify root causes, including all contributing factors, and outline how they not only addressed the root cause, but what they will continue to do to ensure that it does not happened again – often updating or creating new mechanisms of inspection and continuous improvement. These documents are then retained in a searchable database so that valuable learning can be shared cross-functionally.