Amazon is a mess. In the words of one former Amazon.com engineer: “their hiring bar is incredibly inconsistent across teams,” “their operations are a mess,” “their facilities are dirt-smeared cube farms without a dime spent on decor or common meeting areas,” “their pay and benefits suck,” and “their code base is a disaster, with no engineering standards whatsoever except what individual teams choose to put in place.”
It’s madness! No, it’s Amazon.com. They do a lot of things totally wrong. But they make up for it (and then some) by doing one thing really, really right.
The Chaos of Small Teams
Within Amazon, founder and CEO Jeff Bezos has a rule: working teams should be no bigger than what two pizzas can feed. Moreover, he has declared that “communication is terrible” and that he wants his teams to communicate less instead of more.
The upshot is a chaotic environment in which the left hand doesn’t know what the right is doing. Standards are incredibly inconsistent across teams, work gets duplicated, issues and bugs get lost, and more. It’s insane.
The saving grace is a decree that Bezos made back in 2002 — now the one thing they do really well — that aligned their software structure together with their organizational structure to make small teams work at Amazon.
Constraining Team Communication
Bezos’s 2002 decree had a profound impact on how software and teams were organized. It went something like this:
1) All teams will henceforth expose their data and functionality through service interfaces.
2) Teams must communicate with each other through these interfaces.
3) There will be no other form of interprocess 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.
4) It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.
5) All service interfaces, without exception, must be designed from the ground up to be externalizable. 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.
Take a moment to appreciate what Bezos was saying about how teams should communicate. Instead of informal communication in the hallway, teams had to interact through well-defined software APIs. If marketing wants stats from a product team, they can’t ask them for it. They need to hit the product team’s API to get the data. Software teams were made to decouple their code and their resources from each other, and make them available through APIs and web services.
In short, Bezos decreed that the code must be organized into small, distinct services over which small teams have ownership. “Each of these services require a strong focus on who their customers are, regardless whether they are external[] or internal[],” says Amazon CTO Werner Vogels. In other words, each small team acted like its own small company inside of Amazon. Moreover, small teams were directed to interact internally with each other as if they were external customers, by using external interfaces and only those interfaces.
That’s the incredibly powerful force that spawned Amazon Web Services, which has grown its revenue to over $1 billion annually. It started as the infrastructure that supported the Amazon.com store (its first “customer”) — and then, decoupled and working autonomously, it grew into a huge independent business that powers much of the web.
* * * * *
Bezos’s genius sleight of hand was that by limiting team communication to defined external interfaces, by overstating that “communication is terrible,” Bezos turned internal company collaboration into a process of customer-to-customer interaction, furthering his goal of making Amazon the most customer-centric company in history.
It’s called a services-oriented architecture, and no one does it better than Amazon. Each team and piece of software operates as an independent, self-contained service. It’s the model that makes the chaos of small teams in Amazon work.
Liked this article? Sign up for our newsletter to have the ease of receiving one new article every day in your inbox, with unconventional tips on how to get more done.
Photo: Takashi Hososhima
