Powering Innovation and Speed with Amazon’s Two-Pizza Teams
Article | 10 min read
by Daniel Slater
Worldwide Head, Culture of Innovation, AWS
Learn to Scale Innovation, Not Complexity
Today’s business leaders want to empower their organizations with an ability to constantly innovate new offerings to get to market, drive continuous operational improvement, and speed growth across the entire breadth of their enterprises.
In AWS 2022 C-Suite Report: Cloud Enabled Growth, a comprehensive survey of 1,500 executives across 15 markets and 10 industries, it was found that more than half of today’s executives report prioritizing business growth in their corporate strategy. This includes rapidly innovating across their existing business as well as creating new customer value, revenue streams, and growth opportunity.
Ensuring agility and speed across teams is crucial for successful growth and digital transformation, but is often difficult to realize. Legacy organizational structures may not lend themselves to a pace aimed at accelerating innovation. Enterprises that are initially agile can also strain as the scope of their business grows, becoming bogged down in process and decision-making as the business expands and becomes more complex.
Companies are becoming increasingly global. Products and services are becoming completely digital. Through it all, customer expectations are getting higher as they gain the power of information and choice.
Having the ability to keep up with this pace of change while at the same time responding to market opportunities and disruptions requires business agility. IT leaders who take a customer centric approach can create the conditions in which that can happen.
"To truly become a high-performing agile organization, you must look at your organization structure differently and be willing to change your mindset and behavior."
Amazon and AWS are not immune to these dynamics as our own business has scaled. As the number of business units expanded, and as our global workforce rapidly grew and became more geographically dispersed, we needed to transform the way our teams were organized in order to maintain fast-paced innovation, and retain our Day 1 Mentality.
Speed of Innovation
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.”
Conway’s Law (coined by famed computer scientist Melvin Conway in 1967) expresses that the way an organization is structured, and how its teams communicate, will impact the way it develops technology and systems.
Empowering Innovation with the Two-Pizza Team
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.
The Whys of Two-Pizza Teams
small teams have minimized bureaucracy and maximized time to focus on innovating for customers, which in turn raises employee satisfaction
mitigate the Ringelmann Effect (the tendency for individual productivity to decrease in larger groups)
allows teams to run fast, experiment early and frequently, and apply learnings rapidly to constantly drive value to their customers
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
Taking Ownership
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.
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.
Single-Threaded Leaders
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 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.
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.
The Role of Narratives at Amazon
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.
Takeaways
While the structure and mechanisms of two-pizza teams may not be apt for all organizations, executive leaders can bring more agility, speed, and a culture of innovation throughout their enterprises. They can look at ways of increasing autonomy and ownership at the team level, providing them with guideposts (Amazon’s Leadership Principles one such an example) that enable independent, high quality and high-velocity decisions.
Being deliberate about team structure, and how that structure optimizes teams’ ability to leverage its technical architecture (and vice versa) can help drive flexibility, agility, and speed to market of new innovations that meet customer need. Cloud microservices leveraged by teams that are more decoupled from dependencies and constraint (both technical and administrative) allow them to respond more rapidly to changes in the market, and iterate based on lessons learned.
Seeking to drive more single-threaded focus for teams by simplifying and rationalizing the problems each team is asked to solve can accelerate innovation and allow teams to spend more time understanding their customers and inventing on their behalf.
Finally, executives can provide deliberate mechanisms for teams that empower them to bring new ideas to the table. They can encourage bold experimentation by being accepting of failure as a necessary part of invention. And they can enable teams to capture and share lessons to better hone future experiments – all with the right level of single-threaded leadership and governance.
This will help enterprises become an “invention machine” – providing ongoing avenues of new business growth, and serving as a true differentiator that enable their ability to surprise and delight customers, and invent on their behalf.
How to get started
Seek ways to empower smaller autonomous teams with single-threaded ownership over a rationalized service, offering, or customer segment.
Head those teams with single-threaded leaders, dedicated to removing roadblocks for their teams to constantly experiment instead of being the decision-making bottlenecks.
Create consistent, highly distributable mechanisms that give builders guideposts to make autonomous, high-quality and high-velocity decisions.
Have leaders create the right level of inspection and governance to ensure speed, agility, and customer obsession – and encourage constant experimentation and sharing the lessons from failure.
"...invention is the root of all real value creation. And value created is best thought of as a metric for innovation."
Daniel Slater, Worldwide Head, Culture of Innovation, AWS
Dan Slater oversees Culture of Innovation as a part of AWS’s Digital Innovation team. Dan joined Amazon in 2006 to launch the company’s first direct-to-customer digital content offerings. He helped launch the Kindle device and Kindle’s global content marketplaces, as well as Amazon’s self-publishing service, Kindle Direct Publishing (KDP). After overseeing the digital business of the top 60 trade publishers, Dan led content acquisition, demand generation, and vendor relations for KDP. Prior to Amazon, Dan was a Senior Acquisitions Editor at Simon & Schuster and Penguin, and led sales for a publishing IT firm (Vista, now Ingenta). Born in Toronto, Canada, Dan lives in Seattle with his wife and two children. He earned his MBA from the Fuqua School of Business, Duke University, and completed a dual Bachelor of Arts degree at Cornell University.
Related reading
The Imperatives of Customer-Centric Innovation
Product Management at Amazon
Take the next step
Stay Connected
AWS Executive Insights is a digital destination for business and technology leaders where we share information, best practices, and event invitations.
Listen and Learn
Listen to executive leaders and AWS Enterprise Strategists, all former C-Suite, discuss their digital transformation journeys.
Uncover New Insights
Learn how to drive growth and implement change that scales your organization.