(by Colin Bryar, Bill Carr)

Chapter 1: Building Blocks (Leadership Principles and Mechanisms)

  1. Customer Obsession. Leaders start with th customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.
  2. Ownership. Leaders are owners. They think long term and don't sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. They never say, "That's not my job."
  3. Invent and Simplify. Leaders expet and require innovation and invention from their teams and always find ways to simplify. They are externally awware, look for new ideas from everywhere, and are not limited by "not invented here". As we do new things, we accept that we may be misunderstood for long periods of time.
  4. Are Right, A Lot. Leaders are right a lot. They have strong judgment and good instincts. They seek diverse perspective and work to disconfirm their beliefs.
  5. Learn and Be Curious. Leaders are never done learning and always seek to improve themselves. They are curious about new possibilities and act to explore them.
  6. Hire and Develop the Best. Leaders raise the performance bar with every hire and promotion. They recognize exceptional talent, and willingly move them throughout the organization. Leaders develop leaders and take seriously their role in coaching others. We work on behalf of our people to invent mechanisms for development like Career Choice.
  7. Insist on the Highest Standards. Leaders have relentlessly high standards--many people may think these standards are unreasonably high. Leaders are continually raising the bar and drive their teams to delivery high-quality products, services, and processes. Leaders ensure that defects do not get sent down the line and that problems are fixed so they stay fixed.
  8. Think Big. Thinking small is a self-fulfilling prophecy. Leaders create and communicate a bold direction that inspires results. They think differently and look around corners for ways to serve customers.
  9. Bias for Action. Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk-taking.
  10. Frugality. Accomplish more with less. Constraints breed resourcefulness, self-sufficiency, and invention. There are no extra points for growing headcount, budget size, or fixed expense.
  11. Earn Trust. Leaders listen attentively, speak candidly, and treat others respectfully. They are vocally self-critical, even when doing so is awkward or embarrassing. Leaders do not believe their or their team's body odor smells of perfume. They benchmark themselves and their teams against the best.
  12. Dive Deep. 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.
  13. Have Backbone; Disagree and Commit. Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting.Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.
  14. Deliver Results. Leaders focus on the key inputs for their business and deliver them with the right quality and in a timely fashion. Despite setbacks, they rise to the occasion and never settle.

Annual Planning: OP1 and OP2

Autonomous, single-threaded 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. Planning for the calendar year beings in the summer, a painstaking process that requires four to eight weeks of intensive work.

The S-Team begins by creating a set of high-level expectations or objectives for the entire company. Once these high-level expectations are established, each group begins work on its own more granular operating plan (OP1) which sets out the individual group's "bottom up" proposal. Through the narrative process (Chap 4), 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:

Each group works in partnership with its finance and HR counterparts to create their detailed plan, whic is then presented to a panel of leaders whose level (director, VP, 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, and iterate.

The OP1 process runs through the fall and completed before fourth-quarter. In January, OP1 is adjusted as necessary to reflect the fourth-quarter results, as well as to udpate the trajectory. This shorter process is called OP2, and it generates the plan of record for the calendar year.

Chapter 2: Hiring (Bar Raiser Process)

Bar Raiser Process

(The need for a rigorous interview process. Bezos: "We want missionaries, not mercenaries.")

(What's wrong with a conventional approach: interviewers who lack a rigorous model for their role in the hiring process leave themselves open to a range of pitfalls; even the smartest interviewer can wander off-script and ask questions that lack a clear objective, leading to answers that reveal nothing about a candidate's likely job performance. Interviewer feedback is often communicated to the broader team with insufficient clarity and unintentional bias. Focusing on candidate qualities that don't reliably predict performance can also skew decisions in the wrong direction. Unstructured hiring decision meetings can give rise to groupthink, confirmation bias, and other cognitive traps that feel right at the time but produce poor decisions.)

The Bar Raiser Solution

The name of both a larger process and the group of individuals (Bar Raisers) central to that process. They get special training in the process. One participates in every interview loop. Cannot be the hiring manager or a recruiter; can veto any hire and override the hiring manager. By raising the bar with each new hire, the team would get progressively stronger and produce increasingly powerful results.

Eight steps in the hiring process:

Track and report on the volume and rate at which candidates pass through the funnel and use this data to make process changes as well as to coach and train recruiters and hiring managers.

Chapter 3: Organizing (Separable, Single-Threaded Leadership)

"The best way to fail at inventing something is by making it somebody's part-time job."

"Single-threaded leadership": a single person, unencumbered by competing responsibilities, owns a single major initiative and heads up a separable, largely autonomous team to deliver its goals.

Technical Dependencies

Dependency discoveries inside of Amazon on Obidos, a monolithic massive executable:

The system was tightly coupled.

Organizational Dependencies

Scaling up had created long distances to find the people you needed; project teams needed to pitch their request to other project teams, who in turn had their own requests to pitch. Org structures had become tightly coupled as well.

Better Coordination Was the Wrong Answer

"If we wanted Amazon to be a place where builders can build, we needed to eliminate communication, not encourage it." Solution: API-centric standlone entities, loosely-coupled.

NPI (New Project Initiative)

Global prioritization across all projects.

Force-Ranking Our Options: Teams would submit one-pagers describing their project that required outside resources; small group would screen all NPI submissions through several rounds of filtering before it goes in front of a review board; that small group would then true up the resource/payback estimates, and decide which projects would actually go forward.

Choosing Our Priorities: Predictions (costs, consumer behavior, etc) were largely too broad or too difficult to predict to be helpful. Feedback loop introduced, but it took year(s) to complete the cycle of estimate-judge-review-refactor.

First Proposed Solution: Two-Pizza Team

Reorganize into smaller autonomous teams connected to other teams only loosely, and only when unavoidable. Plan: A two-pizza team will:

Tearing Down Monoliths: Werner Vogels quote about service-orientation: "Encapsulating hte 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." Microservices.

The First Autonomous Teams: Autonomous teams are built for speed; when they are aligned, they can go a long way in a short time; when they are poorly aligned, the team can veer far off course just as quickly. Before any two-pizza team was approved, they needed to meet with the S-Team to discuss team's composition, charter, and fitness function; meeting the following criteria:

  1. The team had a well-defined purpose.
  2. The boundaries of ownership were well understood.
  3. The metrics used to measure progress were agreed upon.

Teams needed to focus on removing their dependencies from upstream areas; those that focused initially instead on features, failed.

A well-instrumented two-pizza team also were better at course correcting--detecting and fixing mistakes as they arose.

Some Challenges Still Remained

Two-Pizza Teams Worked Best in Product Development: Attempts to implement them in retail, legal, HR, and other areas didn't work due to the lack of tangled dependencies.

Fitness Functions Were Actually Worse Than Their Component Metrics: Teams spent a lot of effort to construct meaningful fitness functions. Some of these functions combined seven or more metrics, a few of which were composite numbers made up of their submetrics, and it was often impossible to discern what the team was doing right/wrong and how to respond. Eventually reverted to relying directly on the underlying metrics instead of the fitness function.

Great Two-Pizza Team Leaders Proved to be Rarities: They turned out to be hard to find. (duh) 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 (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.

Sometimes You Need More Than Two Pizzas: We came later 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. "Single-threaded leaders" and "Separable, single-threaded teams" were born.

Bigger and Better Still: The Single-Threaded Leader (STL)

"Seperable means almost as separate 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 resilience or impact upon others. Appointing a single-threaded leader is necessary but not sufficient. 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 the other teams begin and end. Good rule of thumb is deployment: can the team build and roll out their changes without coupling, coordination, and approvals from other teams?

Chapter 4: Communicating (Narratives and the Six Pager)

Amazon relies far more on the written word to develop/communicate ideas than most companies, which makes for a competitive advantage. Two forms of narrative: the "six-pager" and the PR/FAQ (next chapter).

"The Cognitive Style of PowerPoint: Pitching Out Corrupts Within" by Edward Tufte: "As analysis becomes more causal, multivariate, comparative, evidence based, and resolution-intense, the damaging the bullet list becomes." That description fit the S-Team meetings: complex, interconnected, requiring plenty of information to explore, with greater and greater consequences connected to decisions. Such analysis is not well served by a linear progression of slides that makes it difficult to refer one idea to another, sparsely worded bits of text that don't fully express an idea, and visual effects that are more distracting than enlightening. Tufte proposed a solution: "For serious presentations, it will be useful to replace PowerPoint slides with paper handouts showing words, numbers, data graphics, images together. High-resolution handouts allow viewers to contextualize, compare, narrate, and recast evidence. In contrast, data-thin, forgetful displays tend to make audiences ignorant and passive, and also to diminish the credibility of the presenter. ... Making this transition in large organizations requires a straightforward executive order: From now on your presentation software is Microsoft Word, not PowerPoint. Get used to it."

Reaction was less than positive. But a good presenter could make a bad idea look good, and a bad presenter could make a good idea look bad. Bezos offered a short explanation of the reason behind the change:

"The reason writing a good 4 page memo is better than "writing" a 20 page powerpoint is because the narraative 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."

Settled in on a standard format: Maximum length, six pages. Appendices with further information or supporting detail could be attached, but would not be required reading in the meeting itself.

How to Write an Effective Six-Pager

Mockup (from the book) includes two optional sections that many presenters at Amazon have found helpful:
1. the call-out to one or more key tenets that the proposal relies on--a foundational element of the reasoning that led us to make this recommendation. Tenets give the reader an anchor point from which to evaluate the rest. If the tenet itself is in dispute, it's easier to address that directly rather than take on all the logical steps that derive from that position.
2. the inclusion of an FAQ. 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.

Six-page narratives can take many forms. Amazon quarterly business review might be broken down like this: Introduction; Tenets; Accomplishments; Misses; Proposals for Next Period; Headcount; P&L; FAQ; Appendices (including supporting data in the form of spreadsheets, tables and charts, mock-ups)

The New Meeting Format

It works best if the entire audience reads the narrative, in the room, at the beginning of the meeting. There is a massive amount of useful information being transferred in those first 20 minutes. (Reading speed of 3 minutes/page, which led to the six-page limit. For a 30-minute meeting, a three-page narrative would be more appropriate. Leave 2/3 of the meeting time for discussing what we've read.)

When everyone has read the document, the presenter takes the floor. Resist the temptation to "Let me orally walk you through the document"; 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 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. Pick a method that works for you.

Then the discussion begins, which esentially means the audience asks 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 this 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. It is 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.

Feedback and Collaboration

Providing valuable feedbcak and insight can prove to be as difficult as writing the narrative itself. 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. Bezos has an uncanny ability to read a narrative and consistently arrive at insights that no else did: 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.

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

Final Thoughts About Narratives

Narratives are designed to increase the quantity and quality of effective communication in your organization. Creating such solid narratives requires hard work and some risk-taking. Good ones take many days to write. 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 to what is presented, but it carries the sme weight as a full-blown critique.

Chapter 5: Working Backwards (Start with the Desired Customer Experience)

What turned out to work best was relying on the core Amazon principle of customer obsession and a simple yet flexible way of writing narrative documents. Relying on "starting from the customer experience" and "working backwards from that" yields "writing a press release that literally announces the product as if it were ready to launch and an FAQ anticipating the tough questions."

A half-baked mock-up is no better, and perhaps worse, than no mock-up at all; it's half-baked thinking. Need to think through the plan in detail.

The idea had to be in the writing.

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

The Features and Benefits of 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 i 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 or more of the PR/FAQ, and to meet with their senior leaders five times or more to iterate, debate, and refine the idea.

The PR/FAQ process process creates a framework for iterating 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 it, it is addicting; people start using it for everything.

The PR portion is a few paragraphs, always less than one page. The FAQ section should be five pages or less. The goal isn't to explain all the excellent work you have done but rather to share the distilled thinking that has come from the work. (Restricting the length of the document is a forcing function to develop better thinkers and communicators.)

Creation of the PR/FAQ starts with the person who has the idea or the project writing a draft. When it's shareable, that person sets up a one-hour meeting w/stakeholder to review the document and get feedback. At the meeting, they distribute the PR/FAQ, and everyone reads it. When they have finished, the writer asks for general feedback. Once everyone has given their high-level responses, the writer asks for specific comments, line by line, paragraph by paragraph. The 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

Heading: Name of the product in a way the reader (target customers) will understand. One sentence under the title.

Subheading: Describe the customer for the product and what benefits they will gain from using it. One sentence only underneath the heading.

Summary Paragraph: Begin with the city, media outlet, and your proposed launch date. Give a summary of the product and the benefit.

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.

Solution Paragraph: 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.

Quotes and Getting Started: Add one quote from you or your company's spokeperson 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.

FAQ Components

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.

(Sample "Melinda" device PR/FAQ.)

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:

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

Chapter 6: Metrics (Manage Your Inputs, Not Your Outputs)

Part Two: The Invention Machine at Work

Chapter 7: Kindle; Chapter 8: Prime; Chapter 9: Prime Video; Chapter 10: AWS

Appendix A: Interview Feedback Examples

Appendix B: Sample Narrative Tenets and FAQs

Dave Glick (Amazon VP):

"We had gotten through these bad metings and to a place where we could have a discussion about our strategy. At the end of the discussion, we had agreement on the strategy, an we summarized it in five bullet points. Jeff said, 'You should write these down and put them at the top of your document every month, so we remember what we decided last time.' And thus, tenets were born. The next month I showed up with my document with the tenets front and center. It helped us all reload the cache, and made the rest of the meeting productive since we didn't have to rehash our previous decisions."

Sample Tenets

Speed and quality are always important, but, when forced to make a choice between the two, we will always prioritize quality.

Tenet: We don't make money when we sell things. We make money when we help customers make purchase decisions. This guided some challenging and controversial decisions in Amazon's early days, one of which was about product reviews posted on our website. Negative reviews could potentially discourage a customer from buying a product and thus reduce revenue. So, if we are in the business to make money, why would we post negative reviews? But the tenet states that we make money not by selling things, but by helping customers make purchase decisions.

Tenet: When forced to choose between building something that's convenient for customers or convenient for ourselves, we'll choose the former. Case in point, product packaging that is impossible for the customer to open but convenient for the company to use to ship items.

Tenet: We don't let defects travel downstream. When we notice a defect, we will not rely on good intentions to solve the problem. We'll invent and build systematic methods to eliminate that defect. Useful in any continuous improvement environment. In order to prevent a defect from traveling downstream, you may need to build systems to detect and measure the defect and create a feedback loop to make sure the defect doesn't happen again. The problem will not be solved by encouraging people to try harder or relying on the good intentions of customer service people. The heartfelt "I'm sorry you had this problem, we will try harder to meet your needs in the future" does not result in the improvement of a flawed system.

Sample FAQs

An honest, objective, and nonemotional tone tends to work best when answering questions. There's no point in sugarcoating things, and it helps to state the tough issues up front. Amazon's Earn Trust principle states, "Leaders listen attentively, speak candidly, and treat others respectfully. They are vocally self-critical, even when doing so is awkward or embarrassing. Leaders do not believe their or their team's body odor smells of perfume. They benchmark themselves and their teams against the best."

Some useful FAQs we have found useful:

Tags: reading   books   management  

Last modified 30 May 2021