(by Colin Bryar, Bill Carr)
From https://commoncog.com/working-backwards/:
It is true that the list of principles are unique to Amazon, and that they cannot be copied wholesale to your org. But the list serves two purposes:
- It helps explain the organisational context in which the mechanisms are used (this achieves the book’s first goal, as an explanation of how Amazon works).
- More importantly, the authors use Amazon’s leadership principles to make a larger, more critical point: the leadership principles are made explicit because it is used as an organisational design tool.
One way of reading Working Backwards is that it is a book about organisational design. Why is Amazon able to do what it does? Well, the glib answer to that is that Amazon, as an organisation, is designed in a way that makes it easier for it to accomplish its goals. Working Backwards is partly a story of that org design in action: it contains multiple case studies of how Bezos and crew iteratively developed the five mechanisms that take up most of the book. But hidden in those stories is a meta-mechanism: that is, the methods and principles Bezos and others used to come up with new mechanisms in the first place.
Bryar and Carr do not explicitly describe their principles — they just tell you stories of what they (and Bezos) thought, what they tried, and what worked in those early years. But the one explicit thing that they do describe, that belongs in this category of ‘meta-mechanism’, are the leadership principles. By making these leadership principles explicit, Amazon makes it possible to scale the culture of its organisation, even as it expands to multiple new industries, and multiple new locations around the globe.
The gist of the method are as follows:
First, Amazon distils a set of principles from what its best leaders already do. (In a 2015 shareholder letter, Bezos wrote: “You can write down your corporate culture, but when you do so, you’re discovering it, uncovering it — not creating it.”) The first iteration of the leadership principles was done by Robin Andrulevich, an early member of Amazon’s HR team (and eventual Head of HR).
This is then followed by a laborious process where leadership settles on the exact wording of every principle. Bryar describes the period as a series of intense meetings (“I remember one particularly intense debate that centred on the proposed phrase ‘Leaders do not believe their own body odour smells of perfume’ ... Was it ok to use quirky language when communicating with a wide audience?”)
Finally, Bezos emails the list of principles to every manager in Amazon, to formally announce the leadership principles. Of course, this wasn’t the end of things — over time, Amazon leadership refined and added to the original list of ten principles, in order to better capture what Amazonian culture had become. There are now 14 principles. Presumably there may be more in the future.
It may seem a little bizarre that Amazon takes so much time to refine and update its list of leadership principles. But a better way to understand it is to see it as a form of cultural technology. With these leadership principles made explicit, for example, Amazon is able to do three things:
First, it drills these principles into every new hire, with a multi-month process that can best be described as ‘cultural indoctrination’. ... the principles are a form of cultural defence — a method of ensuring that a very specific way of working and seeing the world is maintained throughout the entire company. (The authors note that the principles are not memorised — they are internalised. So the principles are somewhat reflexive: they describe the culture, but they also help keep the culture in place). ... In practice, the leadership principles are so heavily enforced that they become a ‘rules of engagement’ type thing, used in every meeting.
Second, Amazon uses these leadership principles to guide their hiring. We'll talk more about this in the next section (on the Bar Raiser program), but suffice to say, Amazon tries its hardest to hire people who are a natural fit for their leadership principles. They have carefully tuned incentives in their hiring process to ensure bad fit employees rarely get through. In this manner Amazon is able to defend their culture from invasive cultural change — which is, by the way, a real thing: you don’t want to hire a whole bunch of ex-Googlers, only to find that a part of your org is now effectively a mini-Google.
Third, and most importantly, Amazon uses these leadership principles to design new mechanisms. There’s a famous saying in Amazon that goes: “Good intentions don’t work. Mechanisms do.” Sure, your existing culture is one way you can control organisational behaviour. But when you see deviation from your desired behaviour, you don’t want to let things lie; you want to change your systems to ensure that such deviation doesn’t happen again. What do you do? Well, you do incentive systems design, or process design; you create what Amazon calls ‘mechanisms’.
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.
(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 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:
Some interviews may focus on specific functional skills that are necessary for the role. Interviewers are also trained to maintain control of the interview--to politely cut the candidate short and move on to the next question.
Written Feedback: Every interviewer must take detailed notes--as close to verbatim as possible. Use these notes to develop the written feedback you'll give your fellow interviewers; if you do not take complete and detailed notes, expect a visit from your Bar Raiser. Written feedback is expected to be specific, detailed, and filled with examples from the interview to address the Principles assigned to the interviewer. The write-up should be thorough and clear enough that the author need not be present for their conclusions to be understood. This is not an optional exercise: oral feedback offered in lieu of the written is simply unacceptable.
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.
"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.
From the book:
"Speed, or more accurately velocity, which measures both speed and direction, matters in business. With all other things being equal, the organisation 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. In this chapter we’ll explain what these terms mean, how they came to be, and why they lie at the heart of the Amazon approach to innovation and high-velocity decision-making."
From https://commoncog.com/working-backwards/:
The book goes into great detail on every version of this idea before they settled on ‘single threaded leadership’, but the actual single threaded leadership process is simple enough to articulate:
- Each team must be headed by a ‘single threaded leader’. A single threaded leader means a leader with no other responsibilities apart from the team’s charter.
- The team must be separable. The team must be autonomous, with little to no dependencies. In Jeff Wilke’s words: “Separable means almost as separable organisationally as APIs are for software.” (Amazon admits that certain teams can’t help but have dependencies on other teams, e.g. the Payments team, or the Order Pipeline team, so those are evaluated differently).
- Each team must be established with a composition, charter, and set of evaluation metrics. This is because autonomous teams can move quickly, so leadership must check that they’re moving in the right direction before they let them off to execute. As an example of each of these requirements:
- The team must have a well-defined purpose. One example of a team purpose is the Inventory Planning team’s — “This team intends to answer the question, ‘how much inventory should Amazon buy of a given product and when should we buy it?’”
- The boundaries of ownership are well understood. For example, the Inventory Planning team may ask the Forecasting team what the demand will be for a particular product at a given time, and then uses that answer as an input to make a buying decision.
- The metrics used to measure progress are agreed upon in the beginning. The Inventory Planning team’s initial set of evaluation metrics was In-stock Product Pages Displayed divided by Total Product Pages Displayed and Inventory Holding Cost.
From the book: "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."
Dependency discoveries inside of Amazon on Obidos, a monolithic massive executable:
The system was tightly coupled.
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.
"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.
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.
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:
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.
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.
"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?
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.
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)
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.
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.
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.
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 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.
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.
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 7: Kindle; Chapter 8: Prime; Chapter 9: Prime Video; Chapter 10: AWS
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."
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.
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:
Last modified 23 August 2025