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

by Colin Bryar

“We have an unshakeable conviction that the long-term interests of shareowners are perfectly aligned with the interests of customers.”

These include: the Bar Raiser hiring process that ensures that the company continues to acquire top talent; a bias for separable teams run by leaders with a singular focus that optimizes for speed of delivery and innovation;

the use of written narratives instead of slide decks to ensure that deep understanding of complex issues drives well-informed decisions; a relentless focus on input metrics to ensure that teams work on activities that propel the business. And finally there is the product development process that gives this book its name: working backwards from the desired customer experience.

“We need to plant many seeds,” he would say, “because we don’t know which one of those seeds will grow into a mighty oak.” It was an apt analogy. The oak is one of the sturdiest and longest-living trees in the forest. Each tree produces thousands of acorns for every one tree that eventually rises to the sky.

Jeff had one simple rule: “It has to be perfect.”

Another important Amazonian phrase often appears alongside the Amazon Leadership Principles and key tenets: “Unless you know better ones.” This reminds people to always seek to improve the status quo.

Far from being mere catchphrases on a poster or screensaver, Amazon’s Leadership Principles are the company’s living, breathing constitution.

There’s a saying often heard at Amazon: “Good intentions don’t work. Mechanisms do.” No company can rely on good intentions like “We must try harder!”

The main components of an OP1 narrative are: Assessment of past performance, including goals achieved, goals missed, and lessons learned Key initiatives for the following year A detailed income statement Requests (and justifications) for resources, which may include things like new hires, marketing spend, equipment, and other fixed assets

OP2 makes it crystal clear what each group has committed to do, how they intend to achieve those goals, and what resources they need to get the work done. Some variances are inevitable, but any change to OP2 requires formal S-Team approval.

S-Team goals are mainly input-focused metrics that measure the specific activities teams need to perform during the year that, if achieved, will yield the desired business results.

S-Team goals are aggressive enough that Amazon only expects about three-quarters of them to be fully achieved during the year. Hitting every one of them would be a clear sign that the bar had been set too low.

At many companies, when the senior leadership meets, they tend to focus more on big-picture, high-level strategy issues than on execution. At Amazon, it’s the opposite. Amazon leaders toil over the execution details and regularly embody the Dive Deep leadership principle, which states: “Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdotes differ. No task is beneath them.”

The OP planning process aligns the entire company on what’s truly important to accomplish for the year. S-Team goals refine that alignment by giving top priority to the company’s biggest or most pressing objectives. The review cadence helps maintain alignment, no matter what happens along the way. This structure ensures that every goal that’s important to the company has someone—an accountable owner—working on it.

“We want missionaries, not mercenaries.” We have all encountered mercenaries in our career. They are in it to make a fast buck for themselves, they don’t have the organization’s best interests at heart, and they don’t have the resolve to stick with your company through challenging times. Missionaries, as Jeff defined the term, would not only believe in Amazon’s mission but also embody its Leadership Principles. They would also stick around: we wanted people who would thrive and work at Amazon for five-plus years, not the 18–24 months typical of Silicon Valley.

According to Sequoia Capital, the average startup in Silicon Valley spends 990 hours to hire 12 software engineers!

The Amazon Bar Raiser program has the goal of creating a scalable, repeatable, formal process for consistently making appropriate and successful hiring decisions.

There are eight steps in the Bar Raiser hiring process: Job Description Résumé Review Phone Screen In-House Interview Written Feedback Debrief/Hiring Meeting Reference Check Offer Through Onboarding

The hiring manager should not bring a candidate in for the time-consuming and expensive interview loop unless they are inclined to hire them after the phone interview.

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?”

Written feedback is expected to be specific, detailed, and filled with examples from the interview to address the Leadership Principles assigned to the interviewer.

Sometimes we would send a “book bomb” to a candidate—a stack of books we thought they would like—or a handful of their favorite DVDs.

Bar Raiser process steps such as preparing a set of behavior-based interview questions in advance of the interview, insisting on written transcripts of the interview, rereading the transcript post interview (before making an assessment), conducting debriefs, basing debriefs on the interview transcripts, and making assessments based on well-understood principles are all steps that seek to eliminate individual biases.

Speed, or more accurately velocity, which measures both speed and direction, matters in business.

“single-threaded leadership,” in which a single person, unencumbered by competing responsibilities, owns a single major initiative and heads up a separable, largely autonomous team to deliver its goals.

Managing dependencies requires coordination—two or more people sitting down to hash out a solution—and coordination takes time. As Amazon grew, we realized that despite our best efforts, we were spending too much time coordinating and not enough time building.

every dependency creates drag. Amazon’s growing number of dependencies delayed results, increased frustration, and disempowered teams.

When a software architecture includes a large number of technical dependencies, it is said to be tightly coupled, a bad thing that frustrates all involved when you are trying to double and triple the size of the software team. Amazon’s code had been designed in such a way that it became more tightly coupled over time.

Resolving a dependency usually requires coordination and communication. And when your dependencies keep growing, requiring more and more coordination, it’s only natural to try speeding things up by improving your communication. There are countless approaches to managing cross-team coordination, ranging from formalized practices to hiring dedicated coordinators—and it seemed as though we looked at them all.

At last we realized that all this cross-team communication didn’t really need refinement at all—it needed elimination.

This change in our thinking was of course nudged along by Jeff. In my tenure at Amazon I heard him say many times that if we wanted Amazon to be a place where builders can build, we needed to eliminate communication, not encourage it.

In other words, Jeff’s vision was that we needed to focus on loosely coupled interaction via machines through well-defined APIs rather than via humans through emails and meetings. This would free each team to act autonomously and move faster.

This gave rise to a process called New Project Initiatives (NPI), whose job was global prioritization. Not global in the sense of geographic expansion, but rather in comparing every project under consideration to decide which ones were worthy of doing immediately and which ones could wait.

NPI was our best solution at the time for ranking our global options intelligently and picking the winners. No one liked it, but it was a necessary evil given our organization then. Here’s

In an effort to improve our assumptions, we established a feedback loop to measure how well a team’s estimates matched its eventual results, adding another layer of accountability. Jeff Wilke stashed away paper copies of approved NPI proposals so he could check the predictions against actual results later. The added transparency and accountability helped bring team estimates closer to reality, but ultimately not close enough. A year or more could pass between the first presentation and measurable results, which is a long time to wait in order to learn what adjustments are needed. All

The NPI process was deflating for morale. But figuring out how to “boost morale” is not Amazonian. Other companies have morale-boosting projects and groups with names like “Fun Club” and “Culture Committee.” They view morale as a problem to be solved by company-sponsored entertainment and social interaction. Amazon’s approach to morale was to attract world-class talent and create an environment in which they had maximum latitude to invent and build things to delight customers—and you can’t do that if every quarter some faceless process like NPI smites your best ideas.

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 ...

This required a major investment in development resources, systems architecture planning, and great care to ensure that the monolith continued to stand until its last surviving function had been replaced by a service. The rolling regeneration of the way we built and deployed technology was a bold move, an expensive investment that stretched over several years of intensive and delicate work.

criteria: The team had a well-defined purpose. For example, the team intends to answer the question, “How much inventory should Amazon buy of a given product and when should we buy it?” The boundaries of ownership were well understood. For example, the team asks the Forecasting team what the demand will be for a particular product at a given time, and then uses their answer as an input to make a buying decision. The metrics used to measure progress were agreed upon. For example, In-stock Product Pages Displayed divided by Total Product Pages Displayed, weighted at 60 percent; and Inventory Holding Cost, weighted at 40 percent.

One significant lesson became clear fairly early: each team started out with its own share of dependencies that would hold them back until eliminated, and eliminating the dependencies was hard work with little to no immediate payback. 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.

Seeing its early success in speeding up innovation, we wondered whether it might also work in retail, legal, HR, and other areas. The answer turned out to be no, because those areas did not suffer from the tangled dependencies that had hampered Amazon product development. Therefore, implementing two-pizza teams in those orgs would not increase speed.

we realized that as long as we did the up-front work to agree on the specific metrics for a team, and we agreed on specific goals for each input metric, that was sufficient to ensure the team would move in the right direction. Combining them into a single, unifying indicator was a very clever idea that simply didn’t work.

Now free of its initial size limits, the two-pizza team clearly needed a new name. Nothing catchy came to mind, so we leaned into our geekdom and chose the computer science term “single-threaded,” meaning you only work on one thing at a time. Thus, “single-threaded leaders” and “separable, single-threaded teams” were born.

What was originally known as a two-pizza team leader (2PTL) evolved into what is now known as a single-threaded leader (STL). The STL extends the basic model of separable teams to deliver their key benefits at any scale the project demands. Today, despite their initial success, few people at Amazon still talk about two-pizza teams.

Typically an executive, assigned to drive some innovation or initiative, would turn to one of his reports—possibly a director or senior manager—who might have responsibility for five of the executive’s 26 total initiatives. The executive would ask the director to identify one of those direct reports—let’s say a project manager—who would add the project to their to-do list. The PM, in turn, would prevail upon an engineering director to see if one of their dev teams could squeeze the work into their dev schedule.

Amazon’s SVP of Devices, Dave Limp, summed up nicely what might happen next: “The best way to fail at inventing something is by making it somebody’s part-time job.”

The STL delivers high-velocity innovation, which in turn makes Amazon nimble and responsive even at its now-massive scale. Free of the hindrance of excess dependencies, innovators at every level can experiment and innovate faster, leading to more sharply defined products and a higher level of engagement for their creators. Ownership and accountability are much easier to establish under the STL model, keeping teams properly focused and accurately aligned with company strategies. While all these positive outcomes were possible before the first autonomous single-threaded team was created, now they have become the natural and expected consequence of this very Amazonian model for innovation.

The real risk with using PowerPoint in the manner we did, however, was the effect it could have on decision-making. A dynamic presenter could lead a group to approve a dismal idea. A poorly organized presentation could confuse people, produce discussion that was rambling and unfocused, and rob good ideas of the serious consideration they deserved. A boring presentation could numb the brain so completely that people tuned out or started checking their email, thereby missing the good idea lurking beneath the droning voice and uninspiring visuals.

The reason writing a good 4 page memo is harder than “writing” a 20 page powerpoint is because the narrative structure of a good memo forces better thought and better understanding of what’s more important than what, and how things are related. Powerpoint-style presentations somehow give permission to gloss over ideas, flatten out any sense of relative importance, and ignore the interconnectedness of ideas.

Successful narratives will connect the dots for the reader and thus create a persuasive argument, rather than presenting a disconnected stream of bullet points and graphics that leave the audience to do all the work. Writing persuasively requires and enforces clarity of thought that’s even more vital when multiple teams collaborate on an idea.