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

by Colin Bryar

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

There’s a saying often heard at Amazon: “Good intentions don’t work. Mechanisms do.”

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.

This makes it sound like an OKR.

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

It takes almost no time to spot the superstars and to weed out the duds, but the majority of candidates, alas, falls somewhere in between, and that is when biases tend to kick in. If you just pick people who have known characteristics, who already feel familiar, they seem likely to work out. The fact that they sometimes do succeed only makes matters worse, as it reinforces the notion that your process is good enough.

the number of employees can leap from 50 to 150 in a startup, or from 150 to 500 or more during a later phase of rapid growth when the business model is promising and the funding is in the bank. Seemingly overnight, the new employees can vastly outnumber their predecessors, and this dynamic can permanently redefine the corporate culture. 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.”

The theory held that by raising the bar with each new hire, the team would get progressively stronger and produce increasingly powerful results. The Bar Raiser could not be the hiring manager or a recruiter. The Bar Raiser was granted the extraordinary power to veto any hire and override the hiring manager.

Successful managers would quickly realize that they had to devote a considerable amount of their time to the process and would redouble their efforts to source, recruit, and hire candidates who were Amazonian. Managers who failed to put in the time (in addition to their day job) to recruit and interview didn’t last. There is no substitute for working long, hard, and smart at Amazon.

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

Interviewers are also trained to maintain control of the interview. We’ve all been in a situation where the candidate, perhaps seeking to avoid a question, goes on long detours designed to deflect. Or perhaps they are just nervous, and speaking aloud is their way of calming their nerves. In such cases, interviewers know to politely cut the candidate short and move on to the next question.

Bar Raisers are trained to become experts in every aspect of the interviewing process. There is a group of senior Bar Raisers that manages the program, known as Bar Raiser Core, composed mostly of VPs and directors (Bill served in this group).

Some interviewers create a document with the questions, which they use to record notes. Some enter the notes in their computer, while others write them longhand on paper or on the back of the candidate’s résumé. (At the start of the meeting, you may want to explain to the candidate that you will be taking notes and why.) The notes are the record of the data you gather in the interview, and you will use these notes to develop the written feedback you’ll give to your fellow interviewers.

The role of the interviewers is to help the hiring manager gather data and make an informed decision, not to block the hire. The best practice for the hiring manager is to listen and learn and to speak infrequently. The process is designed to prevent urgency and bias from negatively affecting the decision, which could result in wasted time and months of agony.

This technique made it clear that when a candidate’s name implied the gender as female, an unconscious bias had been affecting the résumé screening. The result was that well-qualified female candidates were apparently being rejected too early in the process. This director’s insightful solution provides a great example of how simple enhancements to the hiring process can improve outcomes without damaging the core principles that it was designed to protect.

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. Having a diverse group of people involved in the process obviously reduces the chance of unconscious bias worming its way in.

The answer lies in an Amazon innovation called “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.

while the growth in employees was linear, the number of their possible lines of communication grew exponentially. Regardless of what form it takes—and we’ll get into the different forms in more detail shortly—every dependency creates drag. Amazon’s growing number of dependencies delayed results, increased frustration, and disempowered teams.

The variations in technical dependencies are endless, but each one binds teams more tightly together, turning a rapid sprint into a stumbling sack race where only the most coordinated will cross the finish line. 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.

Too much of any kind of dependency not only slows down the pace of innovation but also creates a dispiriting second-order effect: disempowered teams. When a team is tasked with solving a particular problem and is judged by their solution, they should expect to have the tools and authority to complete the job. Their success should be a source of team pride.

At last we realized that all this cross-team communication didn’t really need refinement at all—it needed elimination. Where was it written in stone that every project had to involve so many separate entities? It wasn’t just that we had had the wrong solution in mind; rather, we’d been trying to solve the wrong problem altogether. We didn’t yet have the new solution, but we finally grasped the true identity of our problem: the ever-expanding cost of coordination among teams.

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. When you view effective communication across groups as a “defect,” the solutions to your problems start to look quite different from traditional ones. He suggested that each software team should build and clearly document a set of application program interfaces (APIs) for all their systems/services.

The switch to microservices removed the shackles that had prevented the Amazon software teams from moving fast, and enabled the transition to small, autonomous teams.

In the 2016 shareholder letter, even though he wasn’t explicitly talking about two-pizza teams, Jeff suggested that “most decisions should probably be made with somewhere around 70% of the information you wish you had. If you wait for 90%, in most cases, you’re probably being slow. Plus, either way, you need to be good at quickly recognizing and correcting bad decisions. If you’re good at course correcting, being wrong may be less costly than you think, whereas being slow is going to be expensive for sure.”

After experimenting over many months across many teams, 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.

The other crucial component of the STL model is a separable, single-threaded team being run by a single-threaded leader like Tom. As Jeff Wilke explains, “Separable means almost as separable organizationally as APIs are for software. Single-threaded means they don’t work on anything else.”

Amazon uses two main forms of narrative. The first is known as the “six-pager.” It is used to describe, review, or propose just about any type of idea, process, or business. The second narrative form is the PR/FAQ. This one is specifically linked to the Working Backwards process for new product development.

“As analysis becomes more causal, multivariate, comparative, evidence based, and resolution-intense,” he writes, “the more damaging the bullet list becomes.” That description fit our discussions at the S-Team meetings: complex, interconnected, requiring plenty of information to explore, with greater and greater consequences connected to decisions. Such analysis is not well served by a linear progression of slides that makes it difficult to refer one idea to another, sparsely worded bits of text that don’t fully express an idea, and visual effects that are more distracting than enlightening. Rather than making things clear and simple, PowerPoint can strip the discussion of important nuance.

In his essay, Tufte proposed a solution. “For serious presentations,” he wrote, “it will be useful to replace PowerPoint slides with paper handouts showing words, numbers, data graphics, images together. High-resolution handouts allow viewers to contextualize, compare, narrate, and recast evidence. In contrast, data-thin, forgetful displays tend to make audiences ignorant and passive, and also to diminish the credibility of the presenter.”

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.

Strong six-pagers don’t just make their case, they anticipate counterarguments, points of contention, or statements that might be easily misinterpreted. Adding the FAQ to address these saves time and gives the reader a useful focal point for checking the thoroughness of the authors’ thinking.

He responded with a simple and useful tip that I have not forgotten: he assumes each sentence he reads is wrong until he can prove otherwise. He’s challenging the content of the sentence, not the motive of the writer. Jeff, by the way, was usually among the last to finish reading.

Creating such solid narratives requires hard work and some risk-taking. Good ones take many days to write. The team writing the narrative toils over the topic, writes its first draft, circulates and reviews and iterates and repeats, then finally takes the vulnerable step of saying to their management and their peers, “Here’s our best effort. Tell us where we fell short.” At first this openness can prove intimidating.

this model imposes duties and expectations upon the audience as well. They must objectively and thoroughly evaluate the idea, not the team or the pitch, and suggest ways to improve it. The work product of the meeting is ultimately a joint effort of the presenter and their audience—thinking that they can all stand behind. Silence in the discussion stage is the equivalent of agreement with what is presented, but it carries the same weight as a full-blown critique.

Writing up our ideas was hard work. It required us to be thorough and precise. We had to describe features, pricing, how the service would work, why consumers would want it. Half-baked thinking was harder to disguise on the written page than in PowerPoint slides. It could not be glossed over through personal charm in the presentation.

The primary point of the process is to shift from an internal/company perspective to a customer perspective. Customers are pitched new products constantly. Why will this new product be compelling enough for customers to take action and buy it? A common question asked by executives when reviewing the product features in the PR is “so what?” If the press release doesn’t describe a product that is meaningfully better (faster, easier, cheaper) than what is already out there, or results in some stepwise change in customer experience, then it isn’t worth building.

However, restricting the length of the document is, to use a term that came up when describing the narratives, a forcing function—we have seen that it develops better thinkers and communicators.

The more PR/FAQs they read, and the more products they build and launch using the PR/FAQ process, the more capable they become at identifying the omissions and flaws in the author’s thinking. And so the process itself creates a tier of master evaluators as it vets and strengthens the idea and aligns everyone involved in the project, from individual contributor to CEO. It also increases the likelihood that a project will be approved and funded.

share price is what Amazon calls an “output metric.” The CEO, and companies in general, have very little ability to directly control output metrics. What’s really important is to focus on the “controllable input metrics,” the activities you directly control, which ultimately affect output metrics such as share price.

Input metrics track things like selection, price, or convenience—factors that Amazon can control through actions such as adding items to the catalog, lowering cost so prices can be lowered, or positioning inventory to facilitate faster delivery to customers. Output metrics—things like orders, revenue, and profit—are important, but they generally can’t be directly manipulated in a sustainable manner over the long term. Input metrics measure things that, done right, bring about the desired results in your output metrics.

Sounds simple, but with the wrong input metrics or an input metric that is too crude, your efforts may not be rewarded with an improvement in your output metrics. The right input metrics get the entire organization focused on the things that matter most. Finding exactly the right one is an iterative process that needs to happen with every input metric.

But DMAIC and the WBR process is eminently scalable. Your level of investment should be on par with the resources you have. If you are a nonprofit, figure out a modest number of key metrics that reliably show how well you are doing.

A big mistake people make is not getting started. Most WBRs have humble beginnings and undergo substantial changes and improvement over time.

One often-overlooked piece of the puzzle is determining how to audit metrics. Unless you have a regular process to independently validate the metric, assume that over time something will cause it to drift and skew the numbers. If the metric is important, find out a way to do a separate measurement or gather customer anecdotes and see if the information trues up with the metric you’re looking at.

If you have progressed through the prior three steps (Define, Measure, and Analyze), then your actions to improve the metric will have a higher chance of succeeding because you’ll be responding to signals instead of noise. If you immediately jump to the Improve stage, you’ll be working with imperfect information on a process you likely don’t fully understand yet, and the actions you take will be much less likely to generate desired results.

It turns out that the Amazon version of the Andon Cord empowered the right people, those on the front lines who were talking directly to customers. It surfaced serious issues as soon as they were noticed. It proved once again that giving employees the right tools to solve problems and relying on their good judgment is a powerful combination.

Controllable input metrics are a quantitative (diving deep with data) and qualitative (anecdotes) way of measuring how well the organization is satisfying these customer interests so that the output metrics trend the way the company desires.

When we have invented, our long-term, patient approach—driven by customer need—has been fundamentally different from the more conventional “skills-forward” approach to invention, in which a company looks for new business opportunities that neatly fit with its existing skills and competencies. While this approach can be rewarding, there is a fundamental problem with it: the company will never be driven to master new skills and develop new competencies, hire new kinds of leaders, or create different types of organizations.

Each time we had these meetings, Jeff would reject what he saw as copycat thinking, emphasizing again and again that whatever music product we built, it had to offer a truly unique value proposition for the customer. He would frequently describe the two fundamental approaches that each company must choose between when developing new products and services. We could be a fast follower—that is, make a close copy of successful products that other companies had built—or we could invent a new product on behalf of our customers. He said that either approach is valid, but he wanted Amazon to be a company that invents.

It’s everyone’s job to obsess over customers and think of inventive ways to delight them.