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

by Colin Bryar

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

Three notably Amazonian features of S-Team goals are their unusually large number, their level of detail, and their aggressiveness. S-Team goals once numbered in the dozens, but these have expanded to many hundreds every year, scattered across the entire company.

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.

No matter how clear your leadership principles and yearly plan may be, they speak softly in comparison to financial incentives. Money talks—if your leadership principles, your yearly plan, and your financial incentives are not closely aligned, you won’t get the right results.

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.

General, open-ended questions such as “Tell me about your career” or “Walk me through your résumé” are usually a waste of time and will not produce the kind of specific information you’re after. When asked such questions, most candidates will take the opportunity to deliver a positive, perhaps slightly glorified narrative of their career.

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 the hiring manager or Bar Raiser feels that they don’t have enough information to make a decision, then there was a failure in the process upstream (e.g., one or more of the interviewers failed to properly assess the candidates on one or more of their assigned leadership principles).

The Bar Raiser process is designed to minimize personal bias and maximize making data-based hiring decisions based on the substance of each candidate’s work and how that work maps to a set of principles. As discussed earlier in this chapter, personal biases naturally occur in an unstructured interview and hiring process. 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 best way to fail at inventing something is by making it somebody’s part-time job.”1

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.

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.

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)

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

We eventually reverted to relying directly on the underlying metrics instead of the fitness function. 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.

As analysis becomes more causal, multivariate, comparative, evidence based, and resolution-intense, the more damaging the bullet list becomes.

Jeff has an uncanny ability to read a narrative and consistently arrive at insights that no one else did, even though we were all reading the same narrative. After one meeting, I asked him how he was able to do that. 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.

A common mistake among less-seasoned product managers is to not fully consider how third parties who have their own agendas and incentives will interact with their product idea, or what potential regulatory or legal issues might arise.

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.

When Amazon teams come across a surprise or a perplexing problem with the data, they are relentless until they discover the root cause. Perhaps the most widely used technique at Amazon for these situations is the Correction of Errors (COE) process, based upon the “Five Whys” method developed at Toyota and used by many companies worldwide. When you see an anomaly, ask why it happened and iterate with another “Why?” until you get to the underlying factor that was the real culprit.

“When you encounter a problem, the probability you’re actually looking at the actual root cause of the problem in the initial 24 hours is pretty close to zero, because it turns out that behind every issue there’s a very interesting story.”

After you have been operating a WBR for a while, you may notice that a metric is no longer yielding useful information. In that case, it’s okay to prune it from the deck.

As we noted above, at Amazon we routinely place our trailing 6 weeks and trailing 12 months side by side on the same x-axis. The effect is like adding a “zoom” function to a static graph that gives you a snapshot of a shorter time period, with the added bonus that you’re seeing both the monthly graph and the “zoomed-in” version of it simultaneously.

Exception reports come in many flavors, but the following Contribution Profit (CP) example should illustrate the basic concept and its usefulness. CP is defined as the incremental money generated after selling an item and deducting the variable costs associated with that item. It’s essentially the money the company has left over after the sale of the item, which goes to pay for the fixed costs of the business and, ideally after that, contributes a profit. There is a CP Exception report that lists the top ten CP negative products (ones that did not generate a profit) within a category for the previous week. Doing a deep dive into these ten products, which often vary from week to week, can reveal very useful information about problems that require action.

Many statistical methods, such as XMR control charts,3 can highlight when a process is out of control.

In other words, his first action was not a “what” decision, it was a “who” and “how” decision. This is an incredibly important difference. Jeff did not jump straight to focusing on what product to build, which seems like the straightest line from A to B. Instead, the choices he made suggest he believed that the scale of the opportunity was large and that the scope of the work required to achieve success was equally large and complex. He focused first on how to organize the team and who was the right leader to achieve the right result.

Why? For digital in particular, part of the answer was that the industry was changing more rapidly than most. With a fast-follower strategy, by the time we could have built and deployed a reasonable replica of a competitor’s service, they or someone else would have already created something better, and we wouldn’t have had enough time to recoup returns on our existing service before we had to build a different one.

The feature that really attracted us was BlackBerry’s constant connectivity. Like everyone, Jeff loved that his phone was always connected and automatically refreshed itself to display new email. In those early days of digital media, this was a first. At the time, the only way to load content onto an MP3 player or other portable device was to connect it to your PC with a wire and sync the content between the two machines. This process was known as “sideloading.”

“Which would you rather have, ‘slow and free’ or ‘fast and expensive’?” is “fast and free.” So the catch was that “fast and free” was where Amazon needed to go next, but our fulfillment capabilities were not up to the task.

The “institutional no” is a big reason why Amazon could have made an error of omission in this case. Jeff and other Amazon leaders often talk about the “institutional no” and its counterpart, the “institutional yes.” The institutional no refers to the tendency for well-meaning people within large organizations to say no to new ideas. The errors caused by the institutional no are typically errors of omission, that is, something a company doesn’t do versus something it does. Staying the current course offers managers comfort and certainty—even if the price of that short-term certainty is instability and value destruction later on.

Prime transformed Amazon from a fairly successful company in the e-commerce space to a top player in the retail space. And Prime changed the way people think about shopping online—and shopping, period. As one journalist wrote, “Amazon single-handedly—and permanently—raised the bar for convenience in online shopping.

At Amazon, our compensation wasn’t tied to financial results. As we mentioned in chapter one, the maximum base salary at Seattle headquarters was $160,000 per year, and there was no bonus system at all. Additional compensation was in Amazon stock. If you got a raise, it was completely in stock, which wouldn’t begin vesting for 18 to 24 months.

Someone asked Stewart to describe a typical day at Flickr. His answer was surprising. He said that about half the day was probably the same as it was for many of the people in the audience—scrambling to keep their technology platform one step ahead of the rapid growth of their business. They worked on scaling their databases, web servers, software, and hardware. Stewart said they did not spend as much time as he would like on innovating things that were unique to Flickr. After the meeting, Jeff and I had a brief chat about Stewart’s comments. We’d both noticed the same thing—a phenomenon that Amazon would later refer to as “undifferentiated heavy lifting,” that is, the tasks that we could do for companies that would enable them to focus on what made them unique. This was an opportunity.

We also knew our unique capabilities would not be unique for very long, which provided a sense of urgency. (The first company to offer a robust set of general-purpose web services wouldn’t be guaranteed to win in the long run, but the head start sure would help.) That sense of urgency is codified in Amazon’s Bias for Action leadership principle. It states, “Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk-taking.”