Innovation formula at Amazon: Small-2-pizza team at Amazon – Part 4

57

In the previous sections, we learned about the culture of accepting failure, the innovation mechanism through customer understanding techniques and part of the organizational structure. This article will focus on the organizational structure at Amazon, revolving around the small “2 Pizza” group, which contributes a large part to the innovation formula.

Benefits from small “2 Pizza” groups.

There is one paradox at Amazon is that communication between groups is… not encouraged by Jeff Bezos. When asked in a discussion on how to make the groups communicate more in a retreat, Bezos stood up and said, “No, communication is terrible.” Thus, group thinking will give way to independent and flexible idea. Why so? That’s because Bezos likes the idea of ​​a distributed organization, in which small team (with as few employees as possible) can unleash creativity, test and verify vision, growth hypothesis and value hypothesis.

An important principle of this philosophy is the famous rule of two pizza. This rule is not related to… any party at Amazon, but merely to arrange enough people in a team to feed just two pizzas. Bezos believes that the company cannot operate effectively, no matter how large it is if a team has an excessive number of people who can eat the two pizza.

What Bezos said comes down to the diminishing returns of labor in Economics. Many studies also prove this view. Professor J. Richard Hackman pointed out: “The larger a group, the more process problems members encounter in carrying out their collective work. […] It’s managing the links between members that gets teams into trouble.” Another researcher, Fred Brooks, said: “Adding human-power to a late software project just makes it later.”

The link among members is difficult to control when we increase the node.

There are hundreds of such small team at Amazon (usually for a group of six to ten people). Breaking into small team helps Amazon to operate in an agile and lean manner. Above all, these teams operate relatively independently, revolving around just one service/capacity instead of whole projects. Entrepreneurship spirit & founder’s mentality is also enhanced when the team leader and team are fully responsible for the product/feature created. E.g: It could be the payment part, or the order processing process.

Team are given autonomous, trust and empower in the decision-making process, to define plans in terms of products, markets, and operations (along with a set of metrics to measure the impact, we will discuss more in the API section), which facilitate improving continuously and create transparency as well as making higher commitment to long-term results. Of course, not all teams have two pizzas in Amazon, but such teams are the core of the spirit of innovation here.

API  connecting “2-Pizza Teams”

In 2002, Jeff Bezos issued an “API Mandate” (API is Application Programming Interface, more in Table 1). Looking at this mandate, we see that all teams at Amazon must interact with each other based on API. “2 –Pizza team” own their own data and no other team can access and change data except through API. If you are in the HR department and need data from the marketing department, you need to get them through the API. All teams have to identify the resources they have to connect API and become partners of each other.

More specifically, every Amazon product must have an API (just like when developing products for an outside customer). Project teams can operate without depending on each other’s working speed and handover to each other easier, faster. In addition, teams can operate fast, streamlined, automated, creating the foundation for innovation at Amazon. The efficiency of small groups is measured by a function of long-term measurement indicators, the measure of influence, impact (Amazon calls this set of measurement indicators a fitness function).

The API mandate shows Bezos’s vision of a decentralized company, where the decision is distributed rather than being centralized and put in one place. Here, teams can independently innovate and active without being affected by other teams or individuals.

Box 1. API mandate from Jeff Bezos in 2002:

  • All teams will henceforth expose their data and functionality through service interfaces.
  • Teams must communicate with each other through these interfaces.
  • There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
  • It doesn’t matter what technology you use.
  • All service interfaces, without exception, must be designed from the ground up to be externalize-able. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
  • The mandate closed with: Anyone who doesn’t do this will be fired.

Microservice

Amazon’s API mandate tells us somewhat about Amazon’s focus on a distributed system, empowering agile teams to make lean decisions. Amazon has switched from Monolith to microservice architecture to accomplish this (The most notable example is at AWS). Of course, each architecture has a limited and positive side. We will explore the positive side of this architecture in this section.

The transition from Monolith to Microservice. Source: Amazon.
The transition from Monolith to Microservice. Source: Amazon.

First, let’s discuss the Monolithh architecture, this is the classic school when all the components of the software are closely intertwined (imagine a spaghetti plate, which is hard to separate them from each other) and doing many things. If a process in the application receives a surge in demand, the entire architecture must scale up. Adding a feature in an application with this architecture becomes more complicated. Even a small change in the system requires a lot of effort to plan and we should be available for human resources, which in turn slows down the process of making products.

Functional groups (such as testing, deployment, user experience (UI), backend group, etc) will work locally and it is difficult to handle who is responsible when there is a bug. This limit tasks such as testing and brainstorming new ideas.

Development cycle on Monolith architecture. Source: Amazon.

With Microservice architecture, the software is divided into independent service components (like each cake in a cake box. We can take one by one), performing a single task, communicating via APIs. For example, the feature displays “purchases” and features “Similar product”, although appearing on the same screen for users but are different services. If there are any changes or bug fixes, it can be corrected smoothly without affecting other services.

These services are managed and responsible by small, independent teams. The microservice architecture makes applications more easily scalable and faster when building and developing. With technology teams, programmers can both write spec and deploy.

Microservice not only changes in the technical structure but also changes the culture, in which there are team members gathered from different functional groups. If the UI/UX group became a separate group in Monolith, in microservice, UI and UX groups will be separated in different groups. Therefore, individuals have diverse views from professional departments.

Development cycle on Microservice architecture. Source: Amazon.

Most importantly: The lean decision-making mechanism at Amazon

The secret to Amazon empowering small teams to operate lies in the decision-making process, divided into two categories: Type I decisions and Type II decisions. The Type I decision is like a one-way door. Those are the decisions that make a huge impact on the big strategy of the company. Once approved, it is irreversible and must be planned in a systematic, careful and slow manner. When you have stepped out of the door, you cannot return.

In contrast, the decision of type II is just different. It is a decision bringing less risk, such as a two-way door: If you make a decision below the standard, you can quickly open the door and come back. Type II decisions will be made quickly by individuals or small teams. Almost all decisions in Amazon are in category II.

A company may have both of these decisions. However, companies, often large companies, often confuse these two types of decisions. When companies are large, there will be a tendency to use the type I decision-making process for every decision, including a decision of type two. This will create stagnation, risk-aversion, and failure to provide appropriate testing. The result is to reduce the innovation of the company.

Class I and Type II decisions are clearly divided. For Type I decisions, Bezos will serve as the “Director of slowing down the process” and requires many criteria, including distinctness, scaling, ROI. With second-class decisions, often in the form of incremental innovations, Amazon created the mechanism of “many paths to yes answers”. An employee with ideas and project plans can be approved and greenlighted by many people in the company, which in turn avoiding bottlenecks.

Conclusion

As discussed in our previous parts, Amazon’s innovation formula is nothing such magic. In Amazon, it is just a function of variables of culture, organization, operational mechanism, architecture. However, many companies fail to achieve this due to culture. Perhaps in these variables, culture plays the most important role. That culture has been disseminated from the top leaders to the lowest level employees in the organization. It is these factors that help more-than 26-year-old Amazon keep the momentum of the spirit of innovation.

Hoang Nam Le – FPT Ventures

What is the innovation formula at Amazon? – Part 1
The innovation formula at Amazon: Going backward from the customer – Part 2
Innovation formula at Amazon: “Amazon is the best place in the world to… fail” – Part 3

Related posts: