Note: While reading a book whenever I come across something interesting, I highlight it on my Kindle. Later I turn those highlights into a blogpost. It is not a complete summary of the book. These are my notes which I intend to go back to later. Let’s start!

  • In such close quarters, Jeff could take the pulse of the company—from software development to finance and operations—by turning his chair around or poking his head through the doorway of an adjoining room. He knew everyone who worked for the company and, apart from writing the all-important software, he had done each of their jobs alongside them while they learned the ropes. And, never shy about how he wanted things done, he began to instill guiding principles, like customer obsession and unrelentingly high standards, into every step his small team took. From the tone of customer emails to the condition of the books and their packaging, Jeff had one simple rule: “It has to be perfect.” He’d remind his team that one bad customer experience would undo the goodwill of hundreds of perfect ones. When a coffee-table book arrived from the distributor with a scratch across the dust jacket, Jeff had customer service write to the customer to apologize and explain that, since coffee-table books are meant for display, a replacement copy was already on order, but shipment would be delayed—unless time was of the essence and they preferred the scratched copy right away. The customer loved the response, and decided to wait for the perfect copy while expressing their delight at receiving this surprise consideration.

  • Another of Jeff’s frequent exhortations to his small staff was that Amazon should always underpromise and overdeliver, to ensure that customer expectations were exceeded. One example of this principle was that the website clearly described standard shipping as U.S. Postal Service First-Class Mail. In actuality, all these shipments were sent by Priority Mail—a far more expensive option that guaranteed delivery within two to three business days anywhere in the United States. This was called out as a complimentary upgrade in the shipment-confirmation email. Thank-you emails for the upgrade included one that read, “You guys R going to make a billion dollars.” When Jeff saw it he roared with laughter, then printed a copy to take back to his office. The job description he wrote for his very first employee said, “You must have experience designing and building large and complex (yet maintainable) systems, and you should be able to do so in about one-third the time that most competent people think possible.”1 In his very first letter to shareholders, in 1997, Jeff wrote, “When I interview people I tell them, ‘You can work long, hard, or smart, but at Amazon.com you can’t choose two out of three.’”

  • Newly hired Amazonians go through a challenging multimonth period of learning and adapting to these new methods. Because these processes and practices are embedded in every meeting, document, decision, interview, and performance discussion, following them becomes second nature over time. And any employee who violates them draws attention to themselves like a person loudly scratching their fingernails across a chalkboard. If, for example, a person spoke up at a meeting and suggested an idea that was obviously geared toward short-term considerations and ignored significant longer-term ones, or proposed something that was competitor- rather than customer-centric, there would be an uncomfortable pause before someone pointed out what was on everyone else’s mind. While this practice may not be unique to Amazon, it is a defining element of its success.

  • People often ask, “How do you remember all 14 principles?” The answer is not that we are particularly good at memorization. In fact, if a company’s principles must be memorized, it’s a warning sign that they aren’t sufficiently woven into the fabric of that company. We know and remember Amazon’s principles because they are the basic framework used for making decisions and taking action.  
  • We encountered them every day, measured ourselves against them, and held one another similarly accountable. The longer you work at Amazon, the more these 14 principles become part of you and how you look at the world. If you expose the workings of any major Amazon process, you’ll see these principles playing a prominent role; employee performance evaluations highlight this perfectly. Much of the peer and manager feedback used in these evaluations focuses on how a person exhibited, or fell short of exhibiting, the Amazon Leadership Principles during the review period. Similarly, every candidate who interviews for a job at Amazon is evaluated in light of the Leadership Principles. Interviewers spend the better part of an hour vetting the candidate according to selected principles, and each candidate typically goes through five to seven interviews. Add in a 30–60 minute debrief meeting attended by each interviewer, multiply that by the number of open positions—10,000 in Seattle alone at the time of this writing—and you begin to understand why Amazon people know the principles intimately. Far from being mere catchphrases on a poster or screensaver, Amazon’s Leadership Principles are the company’s living, breathing constitution.  

  • The nature of the Amazon Leadership Principles is borne out in processes and practices throughout the company. For example, the six-page narratives that the company uses in place of PowerPoint decks to present quarterly and yearly business updates require both the writer and reader to Dive Deep and Insist on the Highest Standards. The Press Release/Frequently Asked Questions process— aka PR/FAQ—reinforces customer obsession, starting with customer needs and working backwards from there.

  • The Door Desk Award goes to a person who exemplifies Frugality and Invention. The Just Do It Award is an abnormally large, well-worn Nike sneaker given to employees who exhibit a Bias for Action. It usually goes to a person who has come up with a clever idea outside the scope of their job. What’s peculiarly Amazonian about the award is that the idea doesn’t have to be implemented—nor does it have to actually work if it is—in order to be eligible.  
  • Even though the Leadership Principles are embedded into the fabric of the company, they cannot effectively enforce themselves—that’s the job of something that Amazonians call mechanisms.  

  • 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!” or “Next time remember to…” to improve a process, solve a problem, or fix a mistake. That’s because people already had good intentions when the problems cropped up in the first place. Amazon realized early on that if you don’t change the underlying condition that created a problem, you should expect the problem to recur. Over the course of many years, Amazon has put in place mechanisms to ensure that the Leadership Principles translate into action. Three foundational mechanisms are: the annual planning process; the S-Team goals process (the STeam consists of the senior vice presidents and direct reports to Jeff Bezos); and Amazon’s compensation plan, which aligns incentives with what’s best for customers and the company over the long term.

  • Annual Planning: OP1 and OP2 Amazon relies heavily on autonomous, single-threaded teams (more in chapter three). These teams keep the company nimble, moving quickly with a minimum of external friction, but their autonomy must be paired with precise goal-setting to align each team’s independent plans with the company’s overarching goals. Amazon’s planning for the calendar year begins in the summer. It’s a painstaking process that requires four to eight weeks of intensive work for the managers and many staff members of every team in the company. This intensity is deliberate, because a poorly defined plan—or worse, no plan at all—can incur a much greater downstream cost. The S-Team begins by creating a set of high-level expectations or objectives for the entire company. For example, in previous years, the CEO and CFO would articulate goals like “Grow revenue from $10 billion to $15 billion” or “Reduce fixed costs by 5 percent.” Over time, Amazon refined such broad goals into a longer list of increasingly detailed objectives. Examples have included: revenue growth targets by geography and business segment; operating leverage targets; improving productivity and giving back those savings to customers in the form of lower prices; generating strong free cash flow; and understanding the level of investment in new businesses, products, and services. Once these high-level expectations are established, each group begins work on its own more granular operating plan—known as OP1—which sets out the individual group’s “bottom-up” proposal. Through the narrative process (described in chapter four), Amazon aims to evaluate about ten times as much information as the typical company does in a similar time frame. 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 Each group works in partnership with its finance and human resources counterparts to create their detailed plan, which is then presented to a panel of leaders.

  • The level of those leaders—director, VP, or S-Team—depends on the size, impact, or strategic importance of the group. The panel then reconciles any gaps between the bottom-up proposal and the top-down goals the group has been asked to meet. Sometimes a team may be asked to rework its plan and re-present it until there’s agreement between the top-down goals and bottom-up plan. The OP1 process runs through the fall and is completed before the fourthquarter holiday rush begins. In January, after the holiday season ends, OP1 is adjusted as necessary to reflect the fourth-quarter results, as well as to update the trajectory of the business. This shorter process is called OP2, and it generates the plan of record for the calendar year. OP2 aligns each group with the goals of the company. Everybody knows their overall objectives, including targets for revenue, cost, and performance. The metrics are agreed upon and will be supplied as part of every team’s deliverables. 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 STeam approval.  

  • S-Team Goals During OP1, as the S-Team reads and reviews the various operating plans, they select the initiatives and goals from each team that they consider to be the most important to achieve. These selected goals are called, unsurprisingly, S-Team goals. In other words, my (Bill’s) team working on Amazon Music might have had 23 goals and initiatives in our 2012 operating plan. After reviewing our plan with us, the S-Team might have chosen six of the 23 to become S-Team goals. The music team would still have worked to achieve all 23 goals, but it would be sure to make resource allocation decisions throughout the year to prioritize the six S-Team goals ahead of the remaining 17. 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 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. In chapter six, we will discuss in more detail how Amazon develops such precise and specific metrics to ensure teams meet their business objectives. S-Team goals must be Specific, Measurable, Attainable, Relevant, and Timely (SMART). An actual S-Team goal could be as specific as “Add 500 new products in the amazon.fr Musical Instruments category (100 products in Q1, 200 in Q2…),” or “Ensure 99.99 percent of all calls to software service ‘Y’ are successfully responded to within 10 milliseconds,” or “Increase repeat advertisers from 50 percent to 75 percent by Q3 of next year.” S-Team goals are aggressive enough that Amazon only expects about threequarters 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.

  • S-Team goals for the entire company are aggregated and their metrics are tracked with centralized tools by the finance team. Each undergoes an intensive quarterly review that calls for thorough preparation. Reviews are conducted in multihour S-Team meetings scheduled on a rolling basis over the quarter rather than all at once. 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 finance team tracks the S-Team goals throughout the year with a status of green, yellow, and red. Green means you are on track, yellow means there is some risk of missing the goal, and red means you are not likely to hit the goal unless something meaningful changes. During the periodic reviews, yellow or red status draws the team’s attention where it’s needed most, and a frank discussion about what’s wrong and how it will be addressed ensues. 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. Last, as Amazon has grown, the planning process has evolved with it. While the overall structure remains the same, there are now separate leadership teams for the retail business and AWS—and even separate teams for the large businesses within those parts of the company. Each of these parts of the company has its own version of “S-Team goals,” just with a different label. As your organization grows, you can follow this recursive process too.  

  • Amazon Compensation Reinforces Long-Term Thinking Even the very best of all these preparations can still be subverted by other factors —the most insidious of which is a certain type of “performance-based” executive compensation that’s all too common elsewhere. 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. Amazon believes that the “performance” in performance-based compensation must refer to the company’s overall performance, that is, the best interests of shareholders, which in turn are perfectly aligned with the best interests of customers. Accordingly, the compensation of Amazon S-Team members and all senior leaders is heavily weighted toward equity earned over a period of several years. The maximum salary itself is set well below that of industry peers in the United States. When we were there, the maximum base salary for any employee was $160,000 (indications are that this remains true). Some new executive hires may receive a signing bonus, but the bulk of their compensation—and the potentially enormous upside—is the long-term value of the company. The wrong kind of compensation practice can cause misalignment in two ways: (1) by rewarding short-term goals at the expense of long-term value creation, and (2) by rewarding the achievement of localized departmental milestones whether or not they benefit the company as a whole. Both can powerfully drive behaviors that are antithetical to the company’s ultimate goals. In other industries, such as media and financial services, a large percentage of executive compensation is doled out in annual performance bonuses. These short-term goals (and yes, a year is definitely short term) can generate behaviors that are detrimental to creating long-term value. In seeking short-term targets to maximize compensation, some may intentionally push revenue from one time period to the next, cannibalizing future results and obscuring current challenges. Others might overspend marketing funds to boost sales for the current quarter and thus hit a short-term sales goal, even at the expense of future quarters or long-term sales. Some might be tempted to defer expenses, put off maintenance, or cut back on hiring in order to hit a quarterly cost-containment target—all with negative longer-term implications. A few may even drag their feet if asked to take on an important new role in the company until their bonus is “in the bank,” delaying some important company initiative. Long-term stock-based compensation incentives, by comparison, eliminate such selfish and costly decisions by making them nonsensical.

  • Many companies set entirely independent goals for key players at every level. All too often this gives rise to infighting, information withholding, and hoarding of resources, as each leader is incentivized to undermine the other. Amazon’s compensation is, by contrast, simple and oriented toward the long term. As one is promoted at Amazon, the ratio of cash to equity compensation becomes more and more skewed toward long-term equity. The Frugality leadership principle makes the reason very plain: “There are no extra points for headcount, budget size, or expense.”

  • There’s no magic number of principles and mechanisms that every company will need. The magic lives in the moments when the principles are put into practice. You’ll develop the number that’s right for you, provided that you focus on how these principles will give clarity to your company’s vision and drive the right behaviors to create meaningful value for your shareholders and stakeholders over the long term—even when the CEO is not in the room. It’s important too to allow your principles to evolve when necessary—to revise, cut, and add as the company grows and changes. Learn and Be Curious was the most recent addition for Amazon. Being Vocally Self-Critical was dropped, with much of its content merged into Earn Trust. Adding, subtracting, and modifying your principles in response to change or deeper understanding is a sign that you’re probably doing things right.

  • Strong leadership principles represent a company’s vision and enable good and fast decisions throughout the company. Codifying those principles is a huge step forward, as we’ve seen, but there is another step that is equally important: to embed them into every one of your company’s core processes, including hiring, performance management, planning, operating cadence, and career development.

  • Several significant flaws appear in this hiring process. First, the fact that the team members shared their thoughts after each interview increased the likelihood that subsequent interviewers would be biased. And Carson’s failure to immediately write up his assessment meant that the group was deprived of the wisdom of its most experienced and insightful team member. Carson’s behavior—uncharacteristic for him—was just one result of the urgency bias that affected the whole process. With a key position glaringly open, and a critical employee doing double duty to cover, the whole team felt time pressure that compelled them to accentuate the positive and to overlook some shortcomings in the process.

  • Every bad hiring decision comes at a cost. In the best cases, it quickly becomes apparent that the new hire is not a good fit, and the person leaves shortly after joining. Even then, the short-term cost can be substantial: the position may go unstaffed for longer than you’d like, the interview team will have wasted their time, and good candidates may have been turned away in the interim. In the worst case, a bad hire stays with the company while making errors in judgment that bring a host of possible bad outcomes. Along the way, a bad hire is a weak link who can bring the entire team down to their standards, a long-term cost that lingers long after they leave the company. Whatever the long-term cost of hiring Joe, Leah and her team will pay a price for their mistake. And, in fact, they did. Because Joe turned out to be a poor fit, the team members still had to put in extra hours to do the work Joe proved unable to do— and to fix the mistakes he made. Six months after the hire, Leah and Joe agreed that it wasn’t working out, and Joe left the company. Still time-pressed and now a little wary of making further mistakes, the team had to go through the whole process again.

  • Another force that works against successful hiring is the lack of a formal process and training. Startups and rapidly growing companies are particularly likely to hire new people without a process in place, though all too many moreestablished companies have the same problem. A manager who has been on the job for just two weeks may be expected to quickly hire a new team of ten people. Working without the framework of a formally defined interview and hiring process, managers will often be driven by urgency, biases, and convenience rather than purpose, data, and analysis. This can have devastating consequences for the fast-growing company. Over a short period of time, say a year, 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.”

  • In a period of torrid headcount growth, founders and early employees often feel that they’re losing control of the company—it has become something different than what they set out to create. Looking back, they realize that the root cause of the problem can be traced to an ill-defined or absent hiring process. They were hiring scores of people who would change the company culture rather than those who would embody, reinforce, and add to it.  

  • The Amazon Bar Raiser program has the goal of creating a scalable, repeatable, formal process for consistently making appropriate and successful hiring decisions. 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 to ensure continual improvement. The Bar Raiser hiring process became one of the earliest and most successful components of the being Amazonian toolkit. As we’ve discussed, many traditional interviewing techniques rely on the “gut feel” of interviewers working in an informal structure, allowing bias to creep in. It is true that an excellent interviewer will have a keen instinct for who might make a great hire, as well as the ability to ignore biases that arise during the interview process. The problem with relying on a few gifted interviewers is that it doesn’t scale and it’s hard to teach. These traits are far from universal and, in the absence of a formal framework, you can’t ensure that everyone involved will know how to conduct an excellent interview. Amazon’s Bar Raiser process was designed to provide that framework, minimize the variability of ad hoc hiring processes, and improve results. “Bar Raiser” is the name of both a larger process and the group of individuals—Bar Raisers—central to that process. In formulating the concept of Bar Raisers, Rick, Joel, and John drew inspiration from Microsoft, where Joel had worked prior to joining Amazon. For many—but not all—hires, Microsoft assigned a so-called “as-app” (short for “as appropriate”) interviewer, a seasoned interviewer who conducted the final interview. The as-app’s role was to make sure that only quality hires were made. They would not be penalized if the role went unfilled, and thus their decisions were unlikely to be influenced by urgency bias. Amazon Bar Raisers receive special training in the process. One participates in every interview loop. The name was intended to signal to everyone involved in the hiring process that every new hire should “raise the bar,” that is, be better in one important way (or more) than the other members of the team they join. 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.

  • Amazon’s first Bar Raisers were handpicked by Rick, Joel, and John for their interviewing skills, ability to assess talent, adherence to high standards, credibility with peers and hiring leaders, and leadership capability. This program would meet more than its fair share of resistance over the years. There were countless times when a hiring manager was desperate to meet a goal set by Jeff or another leader and couldn’t get the people they needed quickly enough. The concept of a Bar Raiser with veto power was seen by shortsighted managers as an enemy standing in the way of their progress. It was bewildering at first to many experienced leaders new to the company. Many would ask if exceptions could be made. But of course, this was part of the problem—hiring almost always felt urgent. We know of no instances where managers were allowed to take shortcuts. 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 idea worked: of the hundreds of processes developed at Amazon over more than twenty years, Bar Raiser is perhaps the most widely used and enduring.

  • No loop participant should be more than one level below the level of the position the candidate will hold. Nor should there be an interviewer who would become a direct report of the candidate. People often want to have a say in hiring their manager and may be upset if they are excluded from the process, but it is a mistake for direct reports to interview a prospective boss. It’s uncomfortable for the candidate during the interview, and the direct report will learn about the candidate’s weaknesses, and other employees’ views of those weaknesses, during the debrief—which could lead to problems for the future functioning of the team. Also, nothing good happens if a future direct report is not inclined to hire the candidate and you hire that person anyway.

  • In the early days, before the Bar Raiser was created, one of our former colleagues was, in fact, a member of the hiring process for the person who would be his manager. He wrote strong no-hire feedback, but the candidate was hired anyway. The recruiter then showed the new person the negative feedback our colleague had written. In their first meeting together, the newly hired boss slid the feedback document across the desk to our colleague, as if to challenge him. The whole situation was, in the words of our colleague, “super weird.” The boss was gone within a year.  
  • The Bar Raiser is involved in every interview loop, and ensures the process is followed and bad hiring decisions are avoided. They are also there to set a good example for other interviewers. In addition to conducting one of the interviews, the Bar Raiser coaches others on interviewing techniques, asks probing questions in the debrief, makes sure that personal biases do not affect the hiring decision, and determines whether the candidate meets or exceeds the hiring bar set by the company. 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). Members of the core typically have been part of the program for many years, have participated in hundreds of interviews, and have demonstrated their mastery of interviewing, managing debriefs, making decisions, and teaching and training other Bar Raisers. Potential new Bar Raisers are identified by current Bar Raisers and by Bar Raiser Core team members. They are reviewed by the core group and, when provisionally approved, they participate in a training session that is usually led by a core member. They are then paired with a Bar Raiser who will shadow and mentor them, and their work is reviewed again by the Bar Raiser Core. Not all candidates are approved. They may not be able to put their training into practice. They may not be skilled enough at interviewing. They may not be able to properly lead and facilitate the debrief meeting. It’s important to emphasize, however, that the skills of the Bar Raiser can be learned by nearly everyone. Not everyone is naturally a great interviewer, but given good instruction and mentoring, people can learn to be very effective at asking pointed questions and probing follow-ups. There is no extra merit pay or bonus for becoming a Bar Raiser, and you retain all the duties of your day job. The only public recognition you get for being a Bar Raiser is an icon next to your name in the online company directory. But it’s a coveted role, because Bar Raisers directly participate in the process that helps ensure Amazon hires the best.  

  • Once the in-house interviews are complete and the written feedback and votes have been collected, the interviewers get together in person or via video conference to debrief and make the hiring decision. The Bar Raiser leads the meeting, which should be held as soon as possible, usually no more than a few days after the interviews have been completed. The meeting begins with everyone reading all the interview feedback. Afterward, the Bar Raiser may kick off the meeting by asking the group, “Now that everyone has had a chance to read all the feedback, would anyone like to change their vote?” The reason for this is that each interviewer submitted their vote based on only the data that they gathered in their interview. In a five-person interview loop, this means that the initial vote is given while in possession of one-fifth of the data. Now that each interviewer has read all the interview transcripts and commentary, they have four times more information on which to base their decision. This additional data may either confirm an initial vote or lead to a change in vote. Either outcome is valid and appropriate; there is no shame in changing your vote based on the presence of additional data. Another method for the Bar Raiser to help get the meeting started is to create a two-column list on a whiteboard of the Leadership Principles where the candidate meets the bar in one column and falls short in the other. The hiring meeting is more than just tallying votes, otherwise it wouldn’t be necessary unless there were a tie. The effective Bar Raiser uses the Socratic method, asking questions that jump-start the critical thinking process, to lead and guide the dialogue with the goal that everyone, or at least the majority, will arrive at the same conclusion about the candidate. The meeting is concluded with a decision from the hiring manager (validated by the Bar Raiser) to hire or not hire. 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). It is extremely rare for a Bar Raiser to exercise their veto power. We know this from our own experience and from an informal poll of interviewers who collectively conducted some 4,000 interviews over the course of 15 years. We’ve only been able to identify three instances in which the veto was exercised. One of them came during the early days of the process in 1999. The other two involved hiring managers who were new to Amazon and had not yet adapted to the organization. Instead, an effective Bar Raiser shares the right examples from the interview transcripts and asks the right probing questions of the interview panel and hiring manager to help them see why a candidate doesn’t meet or raise the bar.

  • When the interview panel decides that the candidate is a hire, the process is not complete. The hiring manager or recruiter next asks the candidate to supply four or five references. Ideally, the references will include former managers, peers and subordinates, and others who have worked directly with the candidate, possibly for many years. The hiring manager, not the recruiter, then calls the references to further explore and confirm the candidate’s skills and past performance. One question that often gets a telling response is, “If given the chance, would you hire this person again?” Another is, “Of the people you have managed or worked with, in what percentile would you place this candidate?” The reference calls should validate the hiring decision and add to the manager’s understanding of the person they will be working with and counting on to help the group achieve their important work goals.   
  • What happens once the team has decided to offer the job to the candidate? At many companies, the hiring manager has the recruiter make the offer. This is another mistake. The hiring manager should personally make the offer and sell him/her on the role and company. You may have chosen the candidate, but that doesn’t mean the candidate has chosen you. You must assume that good employees are being actively pursued by other companies, including their current employer. There is always the risk that you could lose the candidate. Nothing is certain until the day they report to the office. This is why the hiring manager and team members must remain involved in this part of the process. It’s important to keep the candidate excited, not only about the company but also about the team members they’ll be working with. They’ll be spending the majority of their waking hours with that team, possibly for years to come. There is still a lot that the team can do to ensure that the investment you’ve made in getting to the point of making the offer will pay off. After the offer is made, a team member should check in with the candidate at least once a week until he or she makes a final decision. The contact can be as simple as an email saying how excited you are about the candidate joining the team. 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. It could be a coffee or lunch. What matters is that the gesture be sincere and personal.  
  • It may be useful to enlist other people to help close the deal. Perhaps you have a current employee who came over from the same company as the candidate, who attended the same school, who knows someone who overcame similar reservations, or who had the same questions about compensation, work style, or whatever else you know is holding your candidate back. Don’t be afraid to ask your VP or CEO to get involved by making contact in some way. An email or a quick phone call from a person outside the hiring team, especially a person high up in the organization, may help seal the deal.  
  • Speed, or more accurately velocity, which measures both speed and direction, matters in business. With all other things being equal, the organization that moves faster will innovate more, simply because it will be able to conduct a higher number of experiments per unit of time. Yet many companies find themselves struggling against their own bureaucratic drag, which appears in the form of layer upon layer of permission, ownership, and accountability, all working against fast, decisive forward progress.  
  • We are often asked how Amazon has managed to buck that trend by innovating so rapidly, especially across so many businesses—online retail, cloud computing, digital goods, devices, cashierless stores, and many more—while growing from fewer than ten employees to nearly one million. How has the company managed to stay nimble, not stuck struggling to find common ground, as happens with most companies of such size? 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.  
  • 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. That’s because, while the growth in employees was linear, the number of their possible lines of communication grew exponentially.  

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

  • Our organizational chart created extra work in a similar fashion, forcing teams to slog through layers of people to secure project approval, prioritization, and allocation of shared resources that were required to deliver a project. These organizational dependencies were just as debilitating as the technical ones. The org chart had ballooned as we created teams for each new product category, geographic location, and function (e.g., Consumer Electronics, Amazon Japan, Graphic Design). When the company was smaller, you could enlist help or check for possible conflicts by just asking around—everyone often knew each other fairly well. At scale, the same task became long and laborious. You’d have to figure out who you needed to talk to, whether their office was in your building, and who they reported to. Maybe you’d track them down yourself, but more often you’d have to ask your manager, who in turn would ask their managers or their peers—and every step took time. Success connected you with some person (or their manager) you’d ask to listen to your pitch and commit resources to your project. They would often be doing the same thing at the same time for their own projects. In any case, they might be reluctant to slow themselves down on your behalf. You often had to do this several times for a given project, and often without success. If your team had the resources other people needed, such requests could also come your way—sometimes many in a single week. You had to balance each one against the priorities you already had, then decide which (if any) you could support based on your own best judgment about their merits. To get a sense of how much drag these escalating organizational dependencies were adding to the average Amazon project, you had to multiply that effort as much as five or ten times. Just like our software, many of our org structures had become tightly coupled and were holding us back. 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. But Amazon’s tightly coupled software architecture and org structure too often made owners heavily dependent on outside teams, over whom they had little influence. Few teams were fully in control of their own destiny, and many were frustrated by the slow pace of delivery that was beyond their control. Disempowered workers increasingly became discouraged, unable to pursue innovative ideas in the face of so much structural resistance.  
  • 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. 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. 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. 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. An API is a set of routines, protocols, and tools for building software applications and defining how software components should interact. 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.  
  • We could only take on a few big projects each quarter. Trying to prioritize which ones to pursue drove us crazy. We needed a way to ensure that our scarce resources, which mostly meant the software engineering teams, were working on the initiatives that would make the biggest impact to the business. This gave rise to a process called New Project Initiatives (NPI), whose job was global prioritization.  

  • Once every quarter, teams submitted projects they thought were worth doing that would require resources from outside their own team—which basically meant almost every project of reasonable size. It took quite a bit of work to prepare and submit an NPI request. You needed a “onepager”; a written summary of the idea; an initial rough estimate of which teams would be impacted; a consumer adoption model, if applicable; a P&L; and an explanation of why it was strategically important for Amazon to embark on the initiative immediately. Just proposing the idea represented a resource-intensive undertaking. A small group would screen all the NPI submissions. A project could be cut in the first round if it wasn’t thoroughly explained, didn’t address a core company goal, didn’t represent an acceptable cost/benefit ratio, or obviously wouldn’t make the cut. The more promising ideas would move to the next round for a more detailed technical and financial scoping exercise. This step typically happened in real time in a conference room where a leader from each major area could review the project submission, ask any clarifying questions, and provide an estimate on how many resources from their area would be required to complete the project as stated. Usually 30 or 40 attendees were on hand to review a full list of projects, which made for long, long meetings—yuck. Afterward, the smaller NPI core group would true up the resource and payback estimates, then decide which projects would actually go forward. After that group met, every project team leader would receive an email about their submission that came in one of three forms. From best to worst they were: “Congratulations, your project has been approved! The other teams you need to help complete your project are ready to get started too.” “The bad news is that your project was not chosen, but the good news is that none of the approved NPI projects require work from you.” “We’re sorry that none of your projects were approved and you were probably counting on them to hit your team goals. There are, however, approved NPI projects for other teams that require resources from you. You must fully staff those NPI projects before staffing any of your other internal projects. Best of luck.”

  • A lot of NPI projects were presented with large error bars—that is, an unhelpfully broad range of the potential costs and of the predicted return. “We anticipate this feature will generate between $4 million on the low side and $20 million on the high side and expect it will take 20 to 40 person-months to develop.” It’s not easy to compare projects with estimates like that. The toughest job for many project teams was to accurately predict consumer behavior. Time and time again, we learned that consumers would behave in ways we hadn’t imagined during the development phase—especially for brandnew features or products. Even the most rigorous models we used to predict consumer adoption could be well off the mark, leading to long, vigorous debates that never quite felt conclusive.  
  • 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 in all, the NPI process was not beloved. If you mention NPI to any Amazonian who went through it, you’re likely to get a grimace and maybe a horror story or two. Sometimes you got lucky, your project was approved, and you could move forward smoothly enough. Too often, however, your plans were thwarted. Instead of doing vital work on something you owned, you’d be assigned to support another team’s project while still taking care of everything that was left on your plate. “Getting NPI’d,” as we called it, meant that your team was literally getting nothing for something.  
  • Seeing that our best short-term solutions would not be enough, Jeff proposed that instead of finding new and better ways to manage our dependencies, we figure out how to remove them. We could do this, he said, by reorganizing software engineers into smaller teams that would be essentially autonomous, connected to other teams only loosely, and only when unavoidable. These largely independent teams could do their work in parallel. Instead of coordinating better, they could coordinate less and build more.  
  • Rick solicited ideas from people throughout the company and synthesized them, then came back with a clearly defined model that people would talk about for years to come: the twopizza team, so named because the teams would be no larger than the number of people that could be adequately fed by two large pizzas. With hundreds of these two-pizza teams eventually in place, Rick believed that we would innovate at a dazzling pace. The experiment would begin in the product development organization and, if it worked, would spread throughout the rest of the company. He laid out the defining characteristics, workflow, and management as follows. 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.  

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

  • Just as two-pizza teams replaced a single large organization with something faster and more flexible, a comparable reorganization was overdue for much of the Amazon software architecture to enable us to achieve Rick’s “be autonomous” vision. In a 2006 interview by Jim Gray, Amazon CTO Werner Vogels recalled another watershed moment: We went through a period of serious introspection and concluded that a service-oriented architecture would give us the level of isolation that would allow us to build many software components rapidly and independently. By the way, this was way before service-oriented was a buzzword. For us service orientation means encapsulating the data with the business logic that operates on the data, with the only access through a published service interface. No direct database access is allowed from outside the service, and there’s no data sharing among the services.  

  • Autonomous teams are built for speed. When they are aligned toward a common destination, they can go a long way in a short time. But when they are poorly aligned, the team can veer far off course just as quickly. So they need to be pointed in the right direction and have the tools to quickly course-correct when warranted. That’s why, 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. For instance, the Inventory Planning team would convene with Jeff, Jeff Wilke, and me to ensure that they were meeting the following criteria: 1. 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?” 2. 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. 3. 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. 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.

  • 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. For example, the Picking team owned software that directed workers in the fulfillment centers where to find items on the shelves. They spent much of their first nine months systematically identifying and removing dependencies from upstream areas, like receiving inventory from vendors, and downstream areas, like packing and shipping. They also built systems to track every important event that happened in their area at a detailed, real-time level. Their business results didn’t improve much while they did so, but once they had removed dependencies, built their fitness function, and instrumented their systems, they became a strong example of how fast a two-pizza team could innovate and deliver results. They became advocates of this new way of working.  

  • The original idea was to create a large number of small teams, each under a solid, multidisciplined, frontline manager and arranged collectively into a traditional, hierarchical org chart. The manager would be comfortable mentoring and diving deep in areas ranging from technical challenges to financial modeling and business performance. Although we did identify a few such brilliant managers, they turned out to be notoriously difficult to find in sufficient numbers, even at Amazon. This greatly limited the number of two-pizza teams we could effectively deploy, unless we relaxed the constraint of forcing teams to have direct-line reporting to such rare leaders.

  • We found instead that two-pizza teams could also operate successfully in a matrix organization model, where each team member would have a solid-line reporting relationship to a functional manager who matched their job description —for example, director of software development or director of product management—and a dotted-line reporting relationship to their two-pizza manager. This meant that individual two-pizza team managers could lead successfully even without expertise in every single discipline required on their team. This functional matrix ultimately became the most common structure, though each two-pizza team still devised its own strategies for choosing and prioritizing its projects.

  • We all agreed at the outset that a smaller team would work better than a larger one. But we later came to realize that the biggest predictor of a team’s success was not whether it was small but whether it had a leader with the appropriate skills, authority, and experience to staff and manage a team whose sole focus was to get the job done. 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. We say that the STL is bigger and better, but better than what? Certainly it’s an improvement on the two-pizza team it evolved from, but is it better than other alternatives too? To answer that question, let’s look at a more common approach to developing something new.

  • 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.”6 Amazon learned the hard way how this lack of a single-threaded leader could hinder them in getting new initiatives off the ground. One example is Fulfillment by Amazon (FBA). Initially known as Self-Service Order Fulfillment (SSOF), its purpose was to offer Amazon’s warehouse and shipping services to merchants. Rather than handling the storing, picking, packing, and shipping themselves, the merchants would send products to Amazon, and we would handle the logistics from there. The executives in the retail and operations teams thought this was a big, interesting idea, but for well over a year it did not gain significant traction. It was always “coming soon,” but it never actually arrived. Finally, in 2005, Jeff Wilke asked Tom Taylor, then a VP, to drop his other responsibilities and gave him approval to hire and staff a team. Only then did SSOF take off, eventually morphing into Fulfillment by Amazon. FBA launched in September 2006 and became a huge success. Third-party sellers loved it because, by offering them warehouse space for their products, Amazon turned warehousing into a variable cost for them instead of a fixed cost. FBA also enabled third-party sellers to reap the benefits of participating in Prime, which in turn improved the customer experience for buyers. As Jeff said in a letter to shareholders, “In just the last quarter of 2011, Fulfillment by Amazon shipped tens of millions of items on behalf of sellers.”  
  • The leaders who had been trying to get this service off the ground before Tom Taylor took it over were exceptionally capable people, but while they were tending to all their other responsibilities, they just didn’t have the bandwidth to manage the myriad details FBA entailed. FBA would have been, at best, much slower and more difficult to launch if Jeff Wilke hadn’t freed up Tom to focus on nothing but this one project. The single-threaded leader concept hadn’t yet been formalized at Amazon, but Tom became an important forerunner. The other crucial component of the STL model is a separable, singlethreaded 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.”  
  • Such teams have clear, unambiguous ownership of specific features or functionality and can drive innovations with a minimum of reliance or impact upon others. Appointing a single-threaded leader is necessary but not sufficient. It’s much more than a simple org chart change. Separable, single-threaded teams have fewer organizational dependencies than conventional teams. They clearly demarcate the boundaries of what they own and where the interests of other teams begin and end. As former Amazon VP Tom Killalea aptly observed, a good rule of thumb to see if a team has sufficient autonomy is deployment—can the team build and roll out their changes without coupling, coordination, and approvals from other teams? If the answer is no, then one solution is to carve out a small piece of functionality that can be autonomous and repeat. A single-threaded leader can head up a small team, but they can also lead the development of something as large as Amazon Echo or Digital Music. For example, with Amazon Echo and Alexa, were it not for the fact that Amazon VP Greg Hart was assigned to be the single-threaded leader, there might have been one person in charge of hardware and another in charge of software for all of Amazon’s devices—but no one whose job it was to create and launch Amazon Echo and Alexa as a whole. On the contrary, a single-threaded leader of Amazon Echo and Alexa had the freedom and autonomy to assess the novel product problems that needed to be solved, decide what and how many teams they needed, how the responsibilities should be divided up among the teams, and how big each team should be. And, crucially, since the technical dependencies problem had been solved, that leader no longer had to check with a prohibitively large number of people for each software change they needed to make.  
  • It took us a while to arrive at the approach of single-threaded leaders and separable, single-threaded teams, and we went through a number of solutions along the way that ultimately didn’t last—like NPIs and two-pizza teams. But it was worth it, because where we landed was an approach to innovation that is so fundamentally sound and adaptable that it survives at Amazon to this day. This journey is also a great example of another phrase you’ll hear at Amazon: be stubborn on the vision but flexible on the details.  

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

  • At Amazon, after a brief exchange of greetings and chitchat, everyone sits at the table, and the room goes completely silent. Silent, as in not a word. The reason for the silence? A six-page document that everyone must read before discussion begins. Amazon relies far more on the written word to develop and communicate ideas than most companies, and this difference makes for a huge competitive advantage.  
  • Amazon uses two main forms of narrative. The first is known as the “sixpager.” 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.  
  • One of my (Colin’s) roles as Jeff’s shadow in the early days of the company was to manage the agenda of the weekly S-Team meeting, which took place every Tuesday and typically ran for four hours. Roughly 80 percent of the time was focused on execution, namely how the company was making progress toward achieving the S-Team goals. In the S-Team meeting, we would select between two and four S-Team goals and do a deep dive on their progress. The meeting was expensive: between preparation and attendance, it consumed at least half a day each week for the top leaders in the company. Given the types of decisions made in the meeting, the stakes were high.  

  • 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. It would take time for people to get the hang of the narrative form. First, there were no codified rules about what the narrative should be, and Jeff offered a short explanation of the reason behind the change. 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.

  • A typical Word document, with text in Arial 11-point font, contains 3,000–4,000 characters per page. For comparison, we analyzed the last 50 S-Team PowerPoint slide presentations and found that they contained an average of just 440 characters per page. This means a written narrative would contain seven to nine times the information density of our typical PowerPoint presentation. If you take into account some of the other PowerPoint limitations discussed above, this multiplier only increases.  

  • Narratives also allow for nonlinear, interconnected arguments to unfold naturally— something that the rigid linearity of PP does not permit. Such interconnectedness defines many of our most important business opportunities. Moreover, better-informed people make higherquality decisions, and can deliver better, more detailed feedback on the presenting teams’ tactical and strategic plans. If our executives are better informed, at a deeper level, on a wider array of important company initiatives, we will gain a substantial competitive advantage over executives elsewhere who rely on traditional low-bandwidth methods of communication (e.g., PP).

  • A complete narrative should also anticipate the likely objections, concerns, and alternate points of view that we expect our team to deliver. Writers will be forced to anticipate smart questions, reasonable objections, even common misunderstandings—and to address them proactively in their narrative document. You simply cannot gloss over an important topic in a narrative presentation, especially when you know it’s going to be dissected by an audience full of critical thinkers. While this may seem a bit intimidating at first, it merely reflects our longstanding commitment to thinking deeply and correctly about our opportunities.  
  • The old essay-writing adage “State, support, conclude” forms the basis for putting a convincing argument forward. 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. The narrative form demands that teams be in sync or, if they are not, that they clearly state in the document where they are not yet aligned.  

  • How to Conduct a Meeting in This New Format Narratives would be distributed at the start of each meeting and read by all in attendance during the time normally taken up by the slide deck—approximately the first 20 minutes. Many will want to take notes, or annotate their copy, during this time. Once everybody signals their readiness, conversation about the document begins. We know that people read complex information at the rough average of three minutes per page, which in turn defines the functional length of a written narrative as about six pages for a 60-minute meeting. Our recommendation is therefore that teams respect the six-page maximum.

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

  • An Amazon quarterly business review, for instance, might be broken down like this instead: Introduction Tenets Accomplishments Misses Proposals for Next Period Headcount P&L FAQ Appendices (includes things like supporting data in the form of spreadsheets, tables and charts, mock-ups).

  • The six-pager can be used to explore any argument or idea you want to present to a group of people—an investment, a potential acquisition, a new product or feature, a monthly or quarterly business update, an operating plan, or even an idea on how to improve the food at the company cafeteria. It takes practice to master the discipline of writing these narratives.

  • When everyone has read the document, the presenter takes the floor. Firsttime presenters often start by saying, “Let me orally walk you through the document.” Resist that temptation; it will likely be a waste of time. The whole point of the written document is to clearly present the reasoning and to avoid the hazards of live presentation. The attendees have already walked themselves through the argument.  

  • Some groups at Amazon go around the room, ask for high-level feedback, then pore over the document line by line. Other groups ask a single individual to give all their feedback on the entire document, then ask the next person in the audience to do the same. Just pick a method that works for you—there’s no single correct approach. Then the discussion begins, which essentially means that the audience members ask questions of the presenting team. They seek clarification, probe intentions, offer insights, and suggest refinements or alternatives. The presenting team has put great care and thought into the narrative, and the audience members have a responsibility to take it seriously. The key goal of the meeting, after all, is to seek the truth about the proposed idea or topic. We want that idea to become the best it can possibly be as a result of any adjustments we make along with the presenting team. During the discussion stage, it’s also important that notes be taken on behalf of the entire audience, preferably by someone knowledgeable about the subject who is not the primary presenter. The presenter is generally too involved in answering questions to capture effective notes at the same time. If I don’t see anyone taking notes at the discussion stage, I will politely pause the meeting and ask who is going to do so. It’s vital that we capture and record the salient points of the ensuing discussion, as those comments become part of the output of the narrative process.

  • Providing valuable feedback and insight can prove to be as difficult as writing the narrative itself. Two of the most cherished gifts I (Colin) received in my career are pens, given to me by people whose narratives I had read and commented on. (I would typically give a printout of the narrative with my handwritten notes on it to the presenters after the meeting.) Both people told me that my comments had played a key role in making their businesses successful. I say this not to boast but to provide evidence that when the reader takes the narrative process just as seriously as the writer does, the comments can have real, significant, and long-lasting impact. You are not just commenting on a document, you’re helping to shape an idea, and thereby becoming a key team member for that business.

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

  • This approach to critical thinking challenges the team to question whether the current narrative has it right or if there are additional fundamental truths to uncover, and if they are aligned with the Amazon Leadership Principles. For example, say a narrative reads, “Our customer-friendly returns policy allows returns up to 60 days from the time of purchase compared to the 30 days typically offered by our competitors.” A busy executive doing a cursory read and already thinking about their next meeting may be content with that statement and move on. However, a critical reader would challenge the implicit assumption being made, namely, that the longer allowable return duration makes the policy customer friendly. The policy may be better than a competitor’s, but is it actually customer friendly? Then during the discussion, the critical reader may ask, “If Amazon is really customer obsessed, why do we penalize the 99 percent of customers who are honest and want to return an item by making them wait until our returns department receives the item to make sure it’s the right item and that it’s not damaged?” This type of thinking—in which you assume there is something wrong with the sentence—led Amazon to create the no-hassle return policy, which specifies that the customer should get a refund even before Amazon receives the returned goods. (The refund is reversed for the small percentage of people who do not send back the item.)

  • Narratives are designed to increase the quantity and quality of effective communication in your organization—by an order of magnitude over traditional methods. 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. But as we’ve seen, 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. In this way, the presenter and audience become integrally linked to the subsequent success or failure of the initiative, or the correctness or incorrectness of a team’s business analysis. When looking at any of Amazon’s big wins, remember that every major success has gone through multiple narrative reviews; it’s likely there were meaningful contributions from the audience as well as the team. On the other hand, for every failed initiative or analysis that fell short, there were senior leaders who looked at it and thought, “This makes sense,” or, “Yes, this should work.” Either way, if the narrative process works to its fullest potential, you’re all in it together.  

  • Most of Amazon’s major products and initiatives since 2004 have one very Amazonian thing in common—they were created through a process called Working Backwards.

  • Working Backwards is a systematic way to vet ideas and create new products. Its key tenet is to start by defining the customer experience, then iteratively work backwards from that point until the team achieves clarity of thought around what to build. Its principal tool is a second form of written narrative called the PR/FAQ, short for press release/frequently asked questions.

  • Working as Jeff’s shadow was a bit like drinking from a fire hose. One surprising challenge of the job I (Colin) noticed early on was just how much context switching went on each day. Every week Jeff—and therefore I—had three recurring meetings: the four-hour S-Team meeting discussed in the previous chapter, a Weekly Business Review (chapter six), and an informal Monday-morning S-Team breakfast near the office. In addition to those, on any given day we’d usually meet with two to four product teams, where we’d spend between one and two hours doing a deep dive on new products and features. Throw in the occasional retail, finance, and operations updates, plus a fire drill or two requiring immediate attention, and you have a typical week.  

  • When we wrote a Kindle press release and started working backwards, everything changed. We focused instead on what would be great for customers. An excellent screen for a great reading experience. An ordering process that would make buying and downloading books easy. A huge selection of titles. Low prices. We would never have had the breakthroughs necessary to achieve that customer experience were it not for the press release process, which forced the team to invent multiple solutions to customer problems.

  • As we got more adept at using the Working Backwards process, we refined the press release document and added a second element: the FAQ, frequently asked questions, with, of course, answers. The FAQ section, as it developed, included both external and internal questions. External FAQs are the ones you would expect to hear from the press or customers. “Where can I purchase a new Amazon Echo?” or “How does Alexa work?” Internal FAQs are the questions that your team and the executive leadership will ask. “How can we make a 44-inch TV with an HD display that can retail for $1,999 at a 25 percent gross margin?” or “How will we make a Kindle reader that connects to carrier networks to download books without customers having to sign a contract with a carrier?” or “How many new software engineers and data scientists do we need to hire for this new initiative?” In other words, the FAQ section is where the writer shares the details of the plan from a consumer point of view and addresses the various risks and challenges from internal operations, technical, product, marketing, legal, business development, and financial points of view. The Working Backwards document became known as the PR/FAQ.  
  • 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.  
  • The PR gives the reader the highlights of the customer experience. The FAQ provides all the salient details of the customer experience as well as a clear-eyed and thorough assessment of how expensive and challenging it will be for the company to build the product or create the service. That’s why it’s not unusual for an Amazon team to write ten drafts of the PR/FAQ or more, and to meet with their senior leaders five times or more to iterate, debate, and refine the idea.  
  • The PR/FAQ process creates a framework for rapidly iterating and incorporating feedback and reinforces a detailed, data-oriented, and fact-based method of decision-making. We found that it can be used to develop ideas and initiatives—a new compensation policy, for example—as well as products and services. Once your organization learns how to use this valuable tool, it is addicting. People start to use it for everything. Over time, we refined and normalized the specifications for the PR/FAQ. The press release (PR) portion is a few paragraphs, always less than one page. The frequently asked questions (FAQ) should be five pages or less. There are no awards for extra pages or more words. The goal isn’t to explain all the excellent work you have done but rather to share the distilled thinking that has come from that work.  

  • The creation of the PR/FAQ starts with the person who originated either the idea or the project writing a draft. When it’s in shareable condition, that person sets up a one-hour meeting with stakeholders to review the document and get feedback. At the meeting, they distribute the PR/FAQ in either soft or hard copy, and everyone reads it to themselves. When they have finished, the writer asks for general feedback. The most senior attendees tend to speak last, to avoid influencing others. Once everyone has given their high-level responses, the writer asks for specific comments, line by line, paragraph by paragraph. This discussion of the details is the critical part of the meeting. People ask hard questions. They engage in intense debate and discussion of the key ideas and the way they are expressed. They point out things that should be omitted or things that are missing. After the meeting, the writer distributes meeting minutes to all the attendees, including notes on the feedback. Then they get to work on the revision, incorporating responses to the feedback. When it is polished, they present it to the executive leaders in the company. There will be more feedback and discussion. More revision and more meetings may be required.

  • Press Release Components These are the key elements of the press release: Heading: Name the product in a way the reader (i.e., your target customers) will understand. One sentence under the title. “Blue Corp. announces the launch of Melinda, the smart mailbox.” Subheading: Describe the customer for the product and what benefits they will gain from using it. One sentence only underneath the heading. “Melinda is the physical mailbox designed to securely receive and keep safe all your e-commerce and grocery deliveries.” Summary Paragraph: Begin with the city, media outlet, and your proposed launch date. Give a summary of the product and the benefit. “PR Newswire, Atlanta, GA, November 5, 2019. Today Blue Corp. announced the launch of Melinda, a smart mailbox that ensures secure and properly chilled delivery and storage for your online purchases and groceries.” Problem Paragraph: This is where you describe the problem that your product is designed to solve. Make sure that you write this paragraph from the customer’s point of view. “Today, 23 percent of online shoppers report having packages stolen from their front porch, and 19 percent complain of grocery deliveries being spoiled.” Solution Paragraph(s): Describe your product in some detail and how it simply and easily solves the customer’s problem. For more complex products, you may need more than one paragraph. “With Melinda, you no longer need to worry about getting your online purchases and deliveries stolen…” Quotes and Getting Started: Add one quote from you or your company’s spokesperson and a second quote from a hypothetical customer in which they describe the benefit they are getting from using your new product. Describe how easy it is to get started, and provide a link to your website where customers can get more information and purchase the product. “Melinda is a breakthrough in safety and convenience for online shoppers…” FAQ Components Unlike the PR, the FAQ section has a more free-form feel to it—there are no mandatory FAQs. The PR section does not typically include visuals, but it is more than appropriate to include tables, graphs, and charts in the FAQ. You must include things like your pro forma P&L for a new business or product. If you have high-quality mock-ups or wireframes, they can be included as an appendix.

  • Often FAQs are divided into external (customer focused) and internal (focused on your company). The external FAQs are those that customers and/or the press will ask you about the product. These will include more detailed questions about how the product works, how much it costs, and how/where to buy it. Because these questions are product specific, they are unique to an individual PR/FAQ. For internal FAQs, there is a more standardized list of topics you will need to cover. Here are some of the typical areas to address. Consumer Needs and Total Addressable Market (TAM) How many consumers have this need or problem? How big is the need? For how many consumers is this problem big enough that they are willing to spend money to do something about it? If so, how much money would they be willing to spend? How many of these consumers have the characteristics/capabilities/constraints necessary to make use of the product? These consumer questions will enable you to identify the core customers by filtering out those who don’t meet the product constraints. In the case of Melinda, for example, you would eliminate people who: don’t have enough space on their front porch for this product don’t have a front porch or similar outdoor area with access to the street at all (e.g., most apartment dwellers) don’t have a suitable source of electricity wouldn’t be pleased to have a large storage/mailbox on their front porch don’t receive many deliveries or deliveries that need refrigeration don’t live in areas where package theft is a problem don’t have interest or ability to pay $299 to answer the need Only a discrete number of people will pass through all these filters and be identified as belonging to the total addressable market. Research into these questions (e.g., how many detached homes are there in a given area?) can help you estimate the total addressable market (TAM), but like any research, there will be a wide error bar. The author and readers of the PR/FAQ will ultimately have to decide on the size of the TAM based on the data gathered and their judgment about its relevance. With Melinda, this process would likely lead to the conclusion that the TAM is in fact pretty small. Economics and P&L What are the per-unit economics of the device? That is, what is the expected gross profit and contribution profit per unit? What is the rationale for the price point you have chosen for the product? How much will we have to invest up front to build this product in terms of people, technology, inventory, warehouse space, and so on? For this section of the PR/FAQ, ideally one or more members of your finance team will work with you to understand and capture these costs so you can include a simplified table of the per-unit economics and a mini P&L in the document. A resourceful entrepreneur or product manager can do this work themselves if they do not have a finance manager or team. For new products, the up-front investment is a major consideration. In the case of Melinda, there is a requirement for 77 people to work on the hardware and software, for an annualized cost of roughly $15 million. This means that the product idea needs to have the potential to earn well in excess of $15 million per year in gross profit to be worth building. The consumer questions and economic analysis both have an effect on the product price point, and that price point, in turn, has an effect on the size of the total addressable market. Price is a key variable in the authoring of your PR/FAQ. There may be special assumptions or considerations that have informed your calculation of the price point—perhaps making it relatively low or unexpectedly high—that need to be called out and explained. Some of the best new product proposals set a notto-exceed price point because it forces the team to innovate within that constraint and face the tough trade-offs early on. The problem(s) associated with achieving that price point should be fully explained and explored in the FAQ. Suppose your research into Melinda leads you to conclude that to realize the largest possible TAM, you need to offer the product at no more than $99. The bill of materials (BOM), however, comes to $250. Now you have two choices to suggest. First, alter the specs, strip out features, or take other actions that will reduce the BOM to below $99. Second, construct a financial plan that shows heavy losses in the early days of release, but also shows that the losses can eventually be mitigated with BOM reductions as the product achieves scale or can be enhanced with some additional source of revenue (e.g., an associated service or subscription).

  • Dependencies How will we convince couriers (USPS, UPS, FedEx, Amazon Fulfillment, Instacart, etc.) to actually use this device instead of their current/standard delivery methods? How will we ensure that couriers (who don’t work for you and over whom you have no control) will use the Melinda UI properly and bother to actually put packages in it instead of just leaving the package by the front door like they typically do? Won’t it take more time (which is precious) for them to make a delivery than it does today? What third-party technologies are we dependent on for Melinda to function as promised? 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 role of third parties is a major issue with Melinda, whose success largely depends on their involvement and proper execution. Without the correct package tracking data or the cooperation of the companies that own that data and the couriers who deliver the packages, Melinda (as described) would be useless. The only alternative would be for customers to manually enter their tracking information for every single delivery into the Melinda app, which they are unlikely to do—and even if they did, it would still require couriers to be willing and able to use it. A good PR/FAQ honestly and accurately assesses these dependencies and describes the specific concepts or plans for the product to solve them. Feasibility What are the challenging product engineering problems we will need to solve? What are the challenging customer UI problems we will need to solve? What are the third-party dependencies we will need to solve? How will we manage the risk of the up-front investment required? These questions are intended to help the author clarify to the reader what level of invention is required and what kind of challenges are involved in building this new product. These criteria vary from product to product, and there are different types of challenges ranging from technical to legal to financial to third-party partnerships and customer UI or acceptance. With Melinda, the engineering challenges are probably quite manageable, since no new technologies need to be developed or employed. The user interface is also familiar. The third-party dependencies present the greatest challenge to making Melinda work.

  • It is important to note that, during our time with Amazon, most PR/FAQs never made it to a stage where they were launched as actual products. What this means is that a product manager will put in a lot of time exploring product ideas that never get to market. This may be because of the intense competition for resources and capital among the hundreds of PR/FAQs that are authored and presented each year within the company. Only the very best will rise to the top of the stack and get prioritized and resourced, whether the pool of capital comes from within a large company like Amazon or from a startup investor. The fact that most PR/FAQs don’t get approved is a feature, not a bug. Spending time up front to think through all the details of a product, and to determine—without committing precious software development resources—which products not to build, preserves your company’s resources to build products that will yield the highest impact for customers and your business. Another one of the biggest benefits of a written PR/FAQ is that it enables the team to truly understand the specific constraints and problems that would prevent a new product idea from being viable and aligning on them. At that point, the product or leadership team must decide if they will keep working on the product, addressing the problems and constraints surfaced by the PR/FAQ and developing solutions that will potentially make the product viable, or if they will set it aside.

  • This process enables a product team and the company leadership to gain a thorough understanding of the opportunity and the constraints. Leadership and management are often about deciding what not to do rather than what to do. Bringing clarity to why you aren’t doing something is often as important as having clarity about what you are doing. If, after the PR/FAQ process, the leadership team still believes in the product and wants it to become a reality, the process will have given them a thorough understanding of the problems that would need to be solved in order to move forward with it. Perhaps a problem can be solved through an acquisition or a partnership. Perhaps it can be solved with the passage of time—new technologies may become available, or the costs of the technology might come down. Perhaps the company decides that the problem or constraint is solvable, that the solution will require risk and cost, and that they are willing to assume that risk and cost because the TAM is large and therefore the potential rewards are great. This last consideration came up frequently in reviews with Jeff, as we would wrestle with product ideas using the PR/FAQ process. A team might identify a hard problem during a review that we did not know how to solve, and didn’t know if we could solve. Jeff would say something to the effect of, “We shouldn’t be afraid of taking on hard problems if solving them would unlock substantial value.”

  • Above all, keep in mind that the PR/FAQ is a living document. Once it is approved by the leadership team, it will almost certainly still be edited and changed (a process that should be directed by or reviewed with the leadership team). There is no guarantee that an idea expressed in an excellent PR/FAQ will move forward and become a product. As we’ve said, only a small percentage will get the green light. But this is not a drawback. It is, in fact, a huge benefit of the process—a considered, thorough, data-driven method for deciding when and how to invest development resources. Generating and evaluating great ideas is the real benefit of the Working Backwards process.  

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

  • Shortly after that holiday season we held a postmortem, out of which was born the Weekly Business Review (WBR). The purpose of the WBR was to provide a more comprehensive lens through which to see the business. The WBR has proved very useful over the years and is widely adopted throughout the company.  

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

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

  • At Amazon, the Weekly Business Review (WBR) is the place where metrics are put into action.  

  • Each meeting begins with the virtual or printed distribution of the data package, which contains the weekly snapshot of graphs, tables, and occasional explanatory notes for all your metrics.

  • The deck represents a data-driven, end-to-end view of the business. While departments shown on org charts are simple and separate, business activities usually are not. The deck presents a consistent, end-to-end review of the business each week that is designed to follow the customer experience with Amazon. This flow from topic to topic can reveal the interconnectedness of seemingly independent activities. It’s mostly charts, graphs, and data tables. With so many metrics to review, written narrative or explanatory notes would undercut the efficiency of the read-through.  

  • How many metrics should you review? There is no magic number or formula. Coming up with the right metrics takes time, and you should seek to improve them continuously. Over time you and your team should modify, add, and remove metrics based on the strength and quality of the signal each emits. Emerging patterns are a key point of focus. Individual data points can tell useful stories, especially when compared to other time periods. In the WBR, Amazon analyzes trend lines to highlight challenges as they emerge rather than waiting for them to be summed up in quarterly or yearly results. Graphs plot results against comparable prior periods. Metrics are intended to trend better over time. Care is taken to ensure that prior periods are structured to provide apples-to-apples comparisons so as not to highlight false variances due to predictable things like holidays or weekends. Graphs show two or more timelines, for example, trailing 6-week and trailing 12-month. Trend lines for the short term can magnify small but important issues that are hard to spot when averaged out over longer periods.

  • Anecdotes and exception reporting are woven into the deck. One trait of an Amazon WBR deck that people often remark upon is the liberal use of two tools: anecdotes and exception reporting—that is, the description of an element that falls outside some standard or usual situation. Both tools enable you to dive into examples that contain something that doesn’t follow the natural or accustomed patterns and that can sometimes, but not always, reveal a defect, a broken process, or a problem with system logic. The use of anecdotes and exception reporting has enabled leaders to audit at scale in a very detailed way. This ability to flag, evaluate, examine, dig deep, and seek specific solutions for a wide range of issues in a very large organization is something we’ve noticed is uniquely Amazonian, and it’s helpful for small and large businesses alike.  

  • What happens inside the WBR is critical execution not normally visible outside the company. A well-run WBR meeting is defined by intense customer focus, deep dives into complex challenges, and insistence on high standards and operational excellence. One may wonder, at what level is it appropriate for executives to shift focus to output metrics? After all, companies and their senior executives are routinely judged by output metrics like revenue and profit. Jeff knows this well, in part based on his time spent working at a Wall Street investment firm. The simple answer is that the focus does not shift at any level of management. Yes, executives know their output metrics backward and forward. But if they don’t continue to focus on inputs, they lose control over and visibility into the tools that generate output results. Therefore, at Amazon, everyone from the individual contributor to the CEO must have detailed knowledge of input metrics to know whether the organization is maximizing outputs.

  • The deck is usually owned by someone in finance. Or more accurately, the data in the deck are certified as accurate by finance. However, because multiple people in the room are responsible for each section of the deck, no one “runs” the meeting per se. For most companies, excluding large companies with tens of billions in revenue and multiple big divisions, the audience for the WBR is the CEO and CFO. The meeting attendees should include the executive team and their direct reports as well as anyone who owns or is speaking to any specific section in the deck. Because technology now enables virtual meetings, it is possible to include many more people in the meeting. Adding more junior members of the company to the WBR can increase their engagement in the business and further their growth and development—by allowing them to observe the discussions and thinking of more seasoned leaders.  

  • It is worth noting here that, at Amazon, even the most senior executives review the full WBR deck of metrics, including all the inputs and outputs. Metrics—as well as anecdotes about the customer experience—are the area where the leadership principle Dive Deep is most clearly demonstrated by senior leaders. They carefully examine the trends and changes in the metrics; audit incidents, failures, and customer anecdotes; and consider whether the input metrics should be updated in some way to improve the outputs. The WBR is an important embodiment of how metrics are put into action at Amazon, but it isn’t the only one. Metrics dashboards and reports are established by every engineering, operations, and business unit at the company. In many cases metrics are monitored in real time, and each critical technical and operational service receives an “alarm” to ensure that failures and outages are identified instantly. In other cases, teams rely on dashboards that are updated hourly or daily for their metrics. The WBR meeting and process is distinctive in how it has enabled Amazon to drive the flywheel faster every year, which in turn has yielded exceptional results.

  • We use consistent and familiar formatting to speed interpretation A good deck uses a consistent format throughout—the graph design, time periods covered, color palette, symbol set (for current year/prior year/goal), and the same number of charts on every page wherever possible. Some data naturally lend themselves to different presentations, but the default is to display in the standard format. Amazon thereby looks at the same set of data every week, in the same order, and gets a holistic view of the business. The team builds up expertise in spotting trends and picks up the rhythm of the review; anomalies stand out more distinctly, and the meeting runs more efficiently. We focus on variances and don’t waste time on the expected People like talking about their area, especially when they’re delivering as expected, and even more so when they exceed expectations, but WBR time is precious. If things are operating normally, say “Nothing to see here” and move along. The goal of the meeting is to discuss exceptions and what is being done about them. The status quo needs no elaboration. Our business owners own metrics and are prepared to explain variances Amazon business owners are responsible for tracking the success of their area as defined by their metrics. In the weekly review, the owners, not the finance team, are expected to provide a crisp explanation for variances against expectations. As a result, business owners quickly become adept at spotting trends. Every week they review the deck before the WBR and respond by discussing what action they plan to take to address the variances.

  • This is a hard-earned lesson; we’ve seen a metric owner display their metrics in front of a group where it’s obviously the first time that person has seen the data. That’s a big mistake, a waste of everyone else’s time, and will most definitely result in a kerfuffle with the senior leader in the room. By the time the WBR meeting occurs, each metric owner should have thoroughly analyzed the metrics they own. Sometimes even the well prepared are hit with a question to which the right answer isn’t immediately apparent. In that case, the owner is expected to say something like, “I don’t know. We are still analyzing the data and will get back to you.” This is preferable to guessing, or worse, making something up on the fly.  

  • We keep operational and strategic discussions separate The WBR is a tactical operational meeting to analyze performance trends of the prior week. At Amazon, it was not the time to discuss new strategies, project updates, or upcoming product releases. We try not to browbeat (it’s not the Inquisition) It’s okay to dig into a meaningful variation that needs more attention, and to point out when high standards have not been met. Still, success demands an environment where people don’t feel intimidated when talking about something that went wrong in their area. Some Amazon teams were better at exemplifying this than others were, and, quite honestly, it’s an area where the company could improve. Sometimes WBRs can devolve into downright hostile environments, especially at times when a major slip-up caused the comments to focus more on the presenter than on the issue. While fear may be a good short-term motivator, it will ultimately cause more problems than it solves.

  • Mistakes should be a learning experience for all. If people become afraid of pointing out their own mistakes because they will feel humiliated in front of their peers, it’s human nature for them to do whatever they can to hide those mistakes in future meetings. Variances that get glossed over are lost learning opportunities for everybody. To prevent this, mistakes should be acknowledged as a chance to take ownership, understand the root cause, and learn from the experience. Some tension is unavoidable and appropriate, but we think it’s better to establish a culture where it’s not just okay, it’s actually encouraged to openly discuss mistakes. We make transitions easy We’ve attended many executive meetings where the most expensive team in the company wastes valuable time, for example, fumbling the handoff of the presentation from one person to the next because the second person’s dashboard doesn’t load easily, or what have you. To make these transitions quick and seamless, you have to put in the up-front work. The WBR is Amazon’s most expensive and impactful weekly meeting, and every second counts—plan ahead and run the meeting efficiently.  

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

  • Adding YOY growth rates in addition to the underlying metric you are measuring is a great way to spot trends.

  • Output Metrics Show Results. Input Metrics Provide Guidance.

  • Numerical data become more powerful when combined with real-life customer stories. The Dive Deep leadership principle 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.” Amazon employs many techniques to ensure that anecdotes reach the teams that own and operate a service. One example is a program called the Voice of the Customer. The customer service department routinely collects and summarizes customer feedback and presents it during the WBR, though not necessarily every week. The chosen feedback does not always reflect the most commonly received complaint, and the CS department has wide latitude on what to present. When the stories are read at the WBR, they are often painful to hear because they highlight just how much we let customers down. But they always provide a learning experience and an opportunity for us to improve.

  • 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. Here are a few findings that could result from reviewing a top-ten CP negative report: CP was negative due to price markdowns that were necessary because we had purchased too many of a certain item, which took up valuable fulfillment center space and capital. The purchase was initiated by the automated purchasing system that had been fed faulty input data. Action: investigate the source of the faulty input data to correct the system. CP was negative due to price markdowns originating from a manual purchase order error. The order quantity the buyer entered on the purchase order was too large, and they did not follow the correct process due to a lack of training. Action: use the incident as a teaching moment. CP was negative due to faulty cost allocation. The finance system was not allocating costs correctly for a certain class of item. Action: fix the cost allocation system. CP was negative because the logistics provider charged more than double the appropriate fee for shipping a particular item. The provider charged the higher fee based on incorrect size and weight information listed for the item in the catalog. Action: fix the catalog data and come up with a plan to put a mechanism in place to prevent the same error from happening for other items in the catalog. CP was negative because the item is sold at a low price but is expensive to ship. Whiteboards and yard rakes are examples of products that can fall into this category. Action: evaluate whether these items should be stocked and sold or some other change should be made, such as changing suppliers or changing the default shipping method. Data and anecdotes make a powerful combination when they’re in sync, and they are a valuable check on one another when they are not. Perhaps the most powerful anecdote in this regard features Jeff himself. Though it happened outside the WBR, it’s worth mentioning here. Amazon has a program called Customer Connection, which is mandatory for corporate employees above a certain level. While the details have changed over the years, the premise has remained the same. Every two years the corporate employee is required to become a customer service agent for a few days. The employee gets some basic refresher training from a CS agent, listens in on calls, watches email/chat interactions, and then handles some customer contacts directly. Once they learn the tools and policies, they perform some or all of those tasks under the supervision of a CS agent. (One of my own calls was from a customer whose neighbor’s dog had eaten his Amazon package. He offered to send us the uneaten bits to prove his case.) Jeff is not exempted from this program. While I was working as his shadow, it came time for his Customer Connection recertification, and we dutifully traveled an hour each day to the customer service center in Tacoma, Washington. Jeff was particularly good with customers over the phone, though he was sometimes overly generous. He gave one customer a full product refund when the policy was to refund the shipping cost only.

  • A few months later, he appointed a singlethreaded leader—Steve Kessel—to run Digital, who would report directly to him so that they could work together to formulate a vision and a plan for digital media. 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. Though the shift to digital was already beginning to happen, no one could predict when the tide would really turn. No one wanted to get in too early, with a product that did not yet have a market. But no one wanted to miss the moment either and be unable to catch up. We knew that we’d need to invent our way out of this dilemma by obsessing over what the best customer experience would be in this new paradigm. Our inherent DNA of customer focus, long-term thinking, and invention were assets in this case.

  • In our one-on-ones, Steve patiently explained why this was the right decision. We had worked through countless drafts of our PR/FAQ for an e-book store and device, and the end result was clear: we needed to build an e-book store that was deeply integrated with a reading device. This combination was the key to delivering a book-buying and reading experience that would delight customers. Through our research, we learned that relying on third parties, while operationally and financially less risky, was much riskier from the point of view of customer experience. If we start with the customer and work backwards, then the most logical conclusion is that we need to create our own devices. The second point he made was that if you decide that the long-term success and survival of your company, like any company at a crossroads, is predicated on having a specific capability that you do not currently have, then the company must have a plan to build or buy it. We had to figure out how to build the capability to make hardware devices internally. If we wanted to ensure a great customer experience that was differentiated on the far end of the value chain, we couldn’t outsource—and therefore cede—that important innovation to others. We had to do it ourselves. Our decision to become a hardware device manufacturer would inform a number of decisions down the road. Many companies that decide to enter a business area in which they have little internal expertise or capability choose to outsource, as happened in the early days of e-commerce when brick-and-mortar retailers created their first online retail sites. They brought in third-party developers, consultants, and sometimes both. This approach enabled them to move much more quickly. But it deprived them of the flexibility to innovate and differentiate, and to continuously incorporate customer desire. Retailers who outsourced e-commerce lacked the ability to ideate and test new products like Super Saver Shipping, Prime, or Fulfillment by Amazon (FBA). They could only pick from a menu of options from their outsourced provider. At best, they would be fast followers of what the innovators built. At worst, in order to compete effectively they would have to implement an end-to-end experience for the product (like Prime), from their website, to their order management systems, to their fulfillment centers, to their delivery methods. You can’t outsource a customized, integrated, end-to-end experience.

  • E Ink screens were black-and-white only, so the Kindle could not support color graphics or video. The transition from one page to the next was slow. But the E Ink screen was much easier on the eyes than the traditional backlit computer screen and was readable in direct sunlight. It would also allow for a much longer battery life, enabling the device to stay on for up to one week without needing a charge. Both of these features were ways for the Kindle to “get out of the way” so customers would forget they were reading on a machine.

  • These two features—wireless delivery and the E Ink screen—proved to be two of the keys to making the Kindle great. Wireless delivery meant that customers could search, browse, buy, download, and start reading a new book in under 60 seconds. The E Ink screen’s paper-like display meant that, unlike with an iPad, you could read by the pool, and its low power consumption meant you could read throughout a 12-hour plane flight without worrying about the device dying on you. We take these features for granted today, but in those days they were unheard of.

  • Retail customers don’t care about a company’s revenue—they care about what they get back in return for parting with their hard-earned dollars. Amazon customers cared about three main things that we could deliver for them: Price . Is the price low enough? Selection. Does Amazon have a wide range of products—ideally everything? Convenience. Is the product in stock, and can I get it quickly? Can I easily find or discover the product? Price, selection, and convenience were therefore the inputs for our business. And we could control all three. Every week the senior leaders would review detailed price, selection, and convenience metrics for each product line and challenge the teams if they were falling short along any of those dimensions. If a competitor beat us in the prior week on pricing for our top-selling items, if we did not add enough new products to the store, if we were out of stock or late on deliveries, or if our website was responding too slowly, the team would have to formulate and enact a plan to fix it. For instance, in the fourth quarter of 2003, we added over 40,000 new gourmet food items, 60,000 new jewelry items, and 70,000 unique health and personal care items in the United States. In Canada and France, we launched Marketplace, the feature that allowed independent third-party retailers to sell their products on our site. We also launched the Home and Kitchen category in Japan. We were adding new items for sale in every other product category as well.

  • In 2000, Amazon had no large-scale loyalty program, which was unusual for an e-commerce company of its size. Jeff asked David Risher, Alan Brown (head of Marketing), and Jason Child (Finance) to create a loyalty program that would drive durable growth. The marketing and retail teams analyzed several variations of loyalty programs, including free standard shipping for orders over $25 (which was essentially Super Saver Shipping but without the three-to-five-day click-to-ship time), free shipping on all preorders (that is, an order placed before the item’s official first ship date), paying an annual fee for free standard shipping, or free two-day shipping. We also considered an alternate form of loyalty program that would include different combinations of purchases of our “owned inventory” (items we stocked in our fulfillment centers) and those of third-party items, where we would have to subsidize shipping costs or require third-party sellers to do so. We even evaluated rebates and points-based programs similar to the airlines’, but there’s an important difference between airlines and retailers. Once a plane takes off, its empty seats have no value. Therefore, airlines, in exchange for loyalty, can give away marginal inventory that would otherwise go unsold. Whereas in retail, giving away either product or shipping fees always has a cost. None of the ideas made it very far because they could not meet the three essential criteria.

  • What do I actually do to bring some of the aspects of being Amazonian into my business?” Here are a few suggestions:
    • Ban PowerPoint as a tool to discuss complicated topics and start using sixpage narratives and PR/FAQ documents in your leadership team meetings. This can be implemented almost instantly. There will be pushback and grumbling, but we’ve found it produces results swiftly, and eventually your leaders will say to themselves, “We can never go back to the old way.”
    • Establish the Bar Raiser hiring process. This approach is no longer unique to Amazon and we have seen it work in many companies. It too can be established relatively quickly, once a training process is in place. It also delivers short-term results by improving the quality of the process and enabling learning for everyone involved in the loop. It should reduce the number of poor hires and, in the long run, improve the overall quality of thinking and performance in each team, and in the company as a whole.
    • Focus on controllable input metrics. Amazon is relentless about identifying metrics that can be controlled and have the greatest impact on outputs such as free cash flow per share. This is not an easy process, because it requires patient trial and error as you seek the input metrics that best allow you to assume control of your desired results. Note too that this is not an argument for abandoning output metrics. Amazon does care a great deal about free cash flow per share.
    • Move to an organizational structure that accommodates autonomous teams with single-threaded leaders. This takes time and requires careful management, as it invariably raises questions about authority and power, jurisdiction, and “turf.” You’ll also have to be on the lookout for dependencies and roadblocks that are preventing autonomy in your organization. But it can be done. Start with your product development group, and then see what other areas, if any, work better in teams.
    • Revise the compensation structure for leaders so that it encourages longterm commitment and long-term decision-making. Avoid making too many exceptions for “special cases.” Make sure that leaders in all areas of the company are compensated with the same basic approach.
    • Articulate the core elements of the company’s culture, as Amazon did with long-term thinking, customer obsession, eagerness to invent, and operational excellence. Then build these into every process and discussion. Do not assume that simply stating them and displaying them will have any significant effect.
    • Define a set of leadership principles. These must be developed with participation from many contributors. Don’t assign the task to a single group or outsource it to a consultant or service provider. Do it yourselves. Hash out the details. Revisit the principles from time to time and revise if and as necessary. Then, as with the aspects of the culture, bring the principles into every process, from hiring to product development.
    • Depict your flywheel. What are the drivers of growth for your company? Make a picture of them that shows how they act upon the flywheel. Evaluate everything you do in light of its positive or negative effect on one or more drivers of the flywheel.