The lesson of Jeff Bezos, founder of e-commerce giant Amazon, on how not to hold meetings with more than 8 to 10 people at a time is well known. It is known as the two-pizza rule (which must be able to feed the meeting participants).
Amazon’s structure, based on small work teams, endowed the company with the agility that its rivals lacked.
“Amazon’s two-pizza teams are agile, developed flexible inter-team structures, offer clarity or purpose, and are fast to innovate. They are also highly autonomous: the Prime Now team was able to launch its pilot on the iPhone first even though Amazon is generally an Android company. When the workload for a team becomes too big, Amazon may decide to break it into multiple smaller teams to keep their agility,” explains Robin Gaster in “Amazon Rising: Power and Seduction in the Age of Amazon.”
The key to Amazon’s success lies within its small-team structure
Each employee is free to seek support and backup within or outside of his or her own regular team. Unlike traditional companies, which have clearly defined chains of command and therefore, for an idea to be implemented, it must move up the chain of command, this is not the case at Amazon.
The book indicates that in companies where a decision involves financial resources or legal issues, accountants and lawyers will have to be consulted. And throughout the process, there are endless opportunities for vetoes.
In contrast, Amazon offers “multiple paths to a yes.” People can go outside their team or even their division to find a team interested in an idea. Teams can find any number of senior leaders to sponsor and support a project.
Not that Amazon makes innovation easy. But Amazon’s structure is designed to get to yes, the author assures us.
What Amazon’s work process looks like?
At Amazon, innovators start working backward to develop a clear vision of what the project is for, who it will serve, and why specifically customers will benefit.
As it takes shape and more evidence is added that the project is worthwhile, it may attract more resources from within and outside the original team. This may include part-time help from other areas such as logistics, human resources, or advertising.
In this phase, the project is adding resources with action lines from existing structures. An HR person may be helping to acquire talent but remains within your existing team. More information resources are available because of Amazon’s earlier decision to manage information flows through an API; emerging teams can access information without having to ask for authorization.
At some point, the project/team gets the green light to move into pilot production. That requires a lot more resources and the creation of a more focused team.
Neil Ackerman explains in the aforementioned text that when he started building a team for his Small and Light Fulfillment project, he sought out the team members he would need through Amazon’s internal directory, and contacted them for “numerous coffee meetings” over several weeks of work. Of the seven people he eventually asked to join the new team, three accepted and he hired four from outside.
As the project becomes more successful, his place in Amazon’s overall hierarchy is settling down.
It is no longer a pilot in an experiment; it is now a service within existing services. Thus, Ackerman’s Small and Light project established itself as a successful tool to serve the needs of the marketplace.
Over time, it attracted Amazon Retail usage and is now a permanent service within Amazon’s logistics network, reporting through the chain of command, and funded through the standard OP1 mechanism. As projects consolidate, teams become fully independent entities within the Amazon ecosystem.
What differentiates small team structures?
The main difference is that Amazon’s internal environment is set up to foster the ongoing formation of teams and provides the critical upfront resources that enable them to move forward quickly.
For this to happen requires, of course, a leadership that expects, and even demands, innovation, and a structure prepared to provide sufficient “fertilizer” in the early stages, sufficient support during the prototyping and testing phase, and sufficient clear pathways for final adoption.
The structural advantage of teams, at least at Amazon (and in theory, at least) is that you can multiply them. You can add new product lines without adding new internal structures or direct reports, and you can add them without the need for meetings and projects, and processes in logistics and e-commerce platforms.
Of course, this image is somewhat idealized. Small teams also compete for resources and projects, so from another perspective, Amazon created a Darwinian environment where teams compete for their projects and initiatives. Not everything is funded, so naturally, there are winners and losers. This hyper-competitive environment is another way Amazon pushes teams to innovate.
One final note. Small teams are only possible because Amazon, from its earliest days, has required all teams to share information electronically not only with other Amazon teams but also with outsiders. This key requirement makes it possible for hundreds of teams to connect; otherwise, they would drown in information overload, time and resource costs of communicating by manual methods such as email and messaging.
