Working Backwards: Insights, Stories, and Secrets from Inside Amazon

by Colin Bryar

“You can write down your corporate culture, but when you do so, you’re discovering it, uncovering it—not creating it.”

Brent Gleeson, a leadership coach and Navy SEAL combat veteran, writes, “Organizational culture comes about in one of two ways. It’s either decisively defined, nurtured and protected from the inception of the organization; or—more typically—it comes about haphazardly as a collective sum of the beliefs, experiences and behaviors of those on the team. Either way, you will have a culture. For better or worse.”2

Like all good processes, it’s simple to understand, can be easily taught to new people, does not depend on scarce resources (such as a single individual), and has a feedback loop

The method that Amazon interviewers use for drilling down goes by the acronym STAR (Situation, Task, Action, Result): “What was the situation?” “What were you tasked with?” “What actions did you take?” “What was the result?”

if we wanted Amazon to be a place where builders can build, we needed to eliminate communication, not encourage it.

we needed to focus on loosely coupled interaction via machines through well-defined APIs rather than via humans through emails and meetings.

A two-pizza team will: Be small. No more than ten people. Be autonomous. They should have no need to coordinate with other teams to get their work done. With the new service-based software architecture in place, any team could simply refer to the published application programming interfaces (APIs) for other teams. (More on this new software architecture to follow.) Be evaluated by a well-defined “fitness function.” This is the sum of a weighted series of metrics. Example: a team that is in charge of adding selection in a product category might be evaluated on:

a) how many new distinct items were added for the period (50 percent weighting) b) how many units of those new distinct items were sold (30 percent weighting) c) how many page views those distinct items received (20 percent weighting) Be monitored in real time. A team’s real-time score on its fitness function would be displayed on a dashboard next to all the other two-pizza teams’ scores. Be the business owner. The team will own and be responsible for all aspects of its area of focus, including design, technology, and business results. This paradigm shift eliminates the all-too-often heard excuses such as, “We built what the business folks asked us to, they just asked for the wrong product,” or “If the tech team had actually delivered what we asked for and did it on time, we would have hit our numbers.” Be led by a multidisciplined top-flight leader. The leader must have deep technical expertise, know how to hire world-class software engineers and product managers, and possess excellent business judgment. Be self-funding. The team’s work will pay for itself. Be approved in advance by the S-Team. The S-Team must approve the formation of every two-pizza team.

before any proposed two-pizza team was approved, they had to meet with Jeff and their S-Team manager—often more than once—to discuss the team’s composition, charter, and fitness function.

The team had a well-defined purpose.

The boundaries of ownership were well understood.

The metrics used to measure progress were agreed upon.

Importantly, the specifics of how the proposed team would go about achieving its goal were not discussed at the meeting. That was the team’s role to figure out for themselves.

The most successful teams invested much of their early time in removing dependencies and building “instrumentation”—our term for infrastructure used to measure every important action—before they began to innovate, meaning, add new features.

If you’re good at course correcting, being wrong may be less costly than you think,