The Dark Side of AWS’s Two-Pizza Teams
- Mariya Kirichok
- 2 days ago
- 7 min read
This article examines the extent of Amazon’s API mandate’s positive influence on effectiveness within the two-pizza team model, compared to a psychological-safety-based approach. Upon first encountering Amazon’s Day 1 culture and focus on progress and innovation, it fascinated me how a company this big could function as a well-oiled machine with all its cogs in their designated places. It seemed perfect, to be honest, complete demolition of hierarchy that slows down decision-making process, paired with innovative and growth-encouraging environment, looked like the ideal place to be working in. Yet, upon closer examination and with the help of Amy Edmondson’s 1999 research on Psychological Safety and studies on silo effects in big corporations related to technology, I have found a few potential weaknesses in this structure, which may be built into the design. These flaws are crucial in companies whose structure is akin to AWS’s, not only does it affect the workers’ mental state and, thus, productivity and well-being, but also endangers one of the key concepts of today’s companies: flexibility and openness to innovation. One key point we can take away from Edmondson’s research is that psychological safety is crucial for the whole team’s effectiveness. While writing her ‘Administrative Science Quarterly’ paper, she writes:
Team psychological safety is defined as a shared belief that The team is safe for interpersonal risk taking. For the most part, this belief tends to be tacit-taken for granted and not given direct attention either by individuals or by the team as a whole. (Edmondson, 1999, p. 6)
If an individual feels safe to take risks necessary for growth and innovation while recognizing the possibility of mistakes, the environment (company, team, department, etc.) is considered psychologically safe. Many of Amazon’s principles were built on fearless and constant risk-taking to explore new ideas and opportunities, thus making psychological safety nearly a requirement in every two-pizza team.
It allows people to exchange experience inside of the team and have constructive conflicts that further strengthen the dynamic between the members and critique-test new ideas. When risks necessary for innovation are being discussed freely, many mistakes could be avoided and new ideas introduced. People tend to keep any constructive criticism silent to avoid conflict for speaking up against someone, and this creates space for errors that could be avoided if all the opinions were heard.
Several starting steps for creating psychological safety are: set the stage, speak up about uncertainties and emphasise the importance of learning; invite participation, allow every member to share ideas or critique and ask relevant follow-up questions; and, finally, take actions, turn voiced ideas into reality and report on fixes.
Day 1 and the Two-Pizza Team
One of the clearest examples of Amazon’s focus on innovation and growth is the Day 1 culture. Customers are at the core: the company functions from their pain points, and customer obsession is one of the most important values. Through simplifying the company structure to lessen bureaucracy and speed up the decision-making process, AWS reaches the point where
Photo: SounderBruce. Source. CC BY-SA 4.0.
any customer-related idea or bug that needs to be fixed is developed and iterated instantly. These two components, fast decision-making processes and prioritising customers allow constant development. The core of the simple company structure and fast feedback on ideas is the two-pizza team: a small group, generally fewer than ten people, working in a specific area. The company consists of many of those teams that exchange data and valuable knowledge using the famous Bezos API Mandate.
In short, all data that the team uses should be uploaded into a digital environment that could be easily exported and accessed by others. This method is very convenient: instead of hunting the PR team for some stats, you can simply log into their internal API and get everything you need.
Another thing that helps AWS’s two-pizza teams to be this fast in decision-making is two-way door decisions. A one-way decision, according to Bezos, is one that cannot be changed: choosing a path for your company, shutting down a product line, etc. On the contrary, two-way decisions can be reversed if anything goes wrong. In companies with a standard structure, where any decision has to be approved by several higher-standing people to be executed, almost everything is treated like a one-way door because it requires analysis from different departments, information that could be difficult to obtain and so on. Instead of complicating things further, Amazon simplifies this overbearing decision chain and allows every team to make fast and changeable decisions that spark further growth and innovations instead of holding everyone back.
Along with fast decisions, the teams should be able to handle projects, tasks and ideas efficiently to avoid procrastination and any mix-ups. According to Schuler (2023), Amazon handles this challenge through single-threaded leadership. It essentially means one leader per task. Every person in charge can dedicate their time to support and remove any barriers in the way of people below them. Instead of controlling multiple tasks at once, which slows down innovation and often results in confusion, single-threaded leaders help two-pizza teams achieve outstanding results.
Where Silos Begin
While the in-team communication in AWS is perfectly executed through the absence of hierarchy and concepts of two-way door decisions and single-threaded leadership, there are some issues in the communication between teams. This gives space for the “silo” phenomenon to sprout. As per “Silo mentality: 7 devastating types destroying tech companies + proven countermeasures” by Pinto (2025), the Silo mentality is reluctance to share information and resources with other people in your company. Hoarding information and cutting off communication could be found unintentionally due to different KPIs and work methods, but also purposefully because data means influence and job security, us versus them mentality, and, finally, low psychological safety. The consequences of the silo effect are the opposite of AWS’s primary values: stagnation, slow decision-making due to lack of data, and poorly informed decisions. We have already established that in the AWS two-pizza teams, all rules of psychological safety are working well: people are not afraid to grow, make mistakes, and ask questions, yet we didn’t
look into the departmental dynamics. This is where the aforementioned silo problem connects with Schein & Bennis’s, and later Edmondson’s, findings. Departmental silo is when teams prioritize their own goals instead of the needs of the whole department, thus creating specific work methods and KPIs that make it difficult to connect. The main issue, though, is information hoarding. People are reluctant to share information because that would mean they could lose part of their influence. Tech companies, where all departments need to be working perfectly for the products to launch, are especially vulnerable to this phenomenon, yet this has already been solved in Amazon by implementing the Bezos API mandate. So, where’s the catch, then? People are sharing data, even if reluctantly, so no silo effect and everything runs well? Actually, no. The API mandate successfully made the information hoarding part of this effect physically improbable, yet lack of communication stayed and flourished, even partially reinforced by this.
“Organizing into services taught teams not to trust each other,” Lane wrote in 2012.
When allowing strangers to use our data, we always strive to protect it through security protocols and other measures: you never know what motives this person could have. This raises suspicion outside your own department, thus lowering psychological safety. Amazon created a perfect system inside the teams, a growth-powered environment where ideas are brought to life with no hierarchical delays and reported back to customers, but communication between teams may become limited. According to the psychological safety rules listed above, the atmosphere in the team is ideal: open space for mistakes and shared knowledge, absence of judgement toward others and hierarchical pressure, however, the inter-team communication is completely replaced by digital access. If you can get whatever you need simply by connecting to the network... Why would you need communication? According to Larson et al., the silo effect, which may exist at an inter-team level in a structure like AWS’s, can weaken the whole system. This manifests as the extinguishing of cross-pollination between fields, which typically drives new ideas and innovation, alongside worsened decision-making, missed strategic opportunities, and lowered customer satisfaction. It is crucial to note that the absence of psychological safety prevents people from trying to reach out and communicate, repeating the same silo loop over and over. The AWS API mandate and two-pizza team structure were designed to cut off one part of the silo effect consequences, informational hoarding, duplicate work and slower decision-making, yet it amplified and even caused psychological issues.
Schuler argues that communication between teams was considered a “bug” rather than a “feature.”
The Invisible Cost
Let’s take a step all the way back to our research question, the effectiveness of API mandate and two-pizza structure in terms of enabling psychological safety and boosting performance, and compare the pros and the cons that we have discussed.
From the more precise and number-oriented metrics that are easy to track, performance, the speed of decision-making, accessible data, the AWS system is working perfectly well. On the contrary, the emerging silo effect and lowered psychological safety between teams prove that there are flaws that are linked to or amplified by the system. AWS’s approach works well at solving visible, measurable problems but may be quietly costing something harder to measure, and that's precisely why it can look like an unambiguous success from the outside while still carrying a real, under-examined cost. Starting from the part that Bezos and his mandate iterated to perfection, the in-team dynamics, the environment prompts growth and innovations through space for mistakes, prevents stagnation due to two-way decision-making, and takes the burden of carrying several teams from the leader’s shoulders thanks to single-threaded leadership principle. People have space to nurture and test any idea, which later results in better catering to the customers’ needs, while also providing fast feedback. The data is accessible to any person who needs it, the APIs are exportable, reducing the probability of information hoarding. The invisible cost lies in the departmental silos. People are used to working together, in these small teams, and the absence of established, stable communication channels, paired with the erosion of psychological safety between teams, prevents anyone from reaching out. Most brilliant ideas are created when two fields collide: HR and engineering, marketing and product management, yet none of this exists in this structure.
An important distinction must be made: all these claims and analysis are supported by secondhand data and additional literature, so it is a structured hypothesis, not a verified account of private employee experience. I hope that future research will provide additional arguments for this thesis, for example, direct comparison of AWS’s company structure to Google and other competitors in the same field, or interviews with employees including data about communication in teams and between them.
This paper has examined Amazon Web Services’ two-pizza team structure and the Bezos API mandate to find out the effectiveness in terms of psychological safety, as outlined by Schein, Bennis, and Edmondson. Full research question: To what extent has Amazon’s API mandate been a positive enabler of communication effectiveness within its two-pizza team model, compared to interpersonal/psychological-safety-based approaches to team communication?
