Working Backwards

This is a summary of a great 🌳 tree book. Working Backwards: Insights, Stories, and Secrets from Inside Amazon is the first book that explains how Amazon really works, written by two insiders who were there when the techniques were invented. This is not a comprehensive summary; tree books don’t lend themselves to easy summarisation. You should buy the book and read it — the stories that the authors tell about the origins of each technique are absolutely critical if you want to apply them; do not rely on this summary alone. Read more about book classifications here.

Amazon is a fascinating company, for about the same reason that Koch Industries is a fascinating company: most American companies are good at doing ‘one’ thing, but Amazon and Koch Industries are good at doing a great many things.

By this I mean that both Amazon and Koch are able to enter, invent, and then dominate many disparate industries. As the CEO of a Fortune 100 company complains (retold by Bill Carr in the book): “I don’t understand how Amazon does it. They are able to build and win in so many different businesses from retail, to AWS, to digital media. Meanwhile, we have been at this for more than 30 years, and we still haven’t mastered our core business.”

Working Backwards was written by two Amazon insiders. Colin Bryar worked as Jeff Bezos’s ‘shadow’ — a highly coveted position that is Amazon’s equivalent of a chief of staff. (The first ‘shadow’ was Andy Jassy, who moved on to become CEO of AWS, and is now Bezos’s successor.) Bill Carr started out as a product manager in video (VHS and DVD) and eventually moved upwards to help start Amazon’s digital businesses. Carr was in the front-lines when Amazon launched the Kindle, the Fire tablet, the Fire TV, Amazon Prime Video, Amazon Music, Amazon Studios, the Echo speaker, and the underlying Alexa voice assistant technology. The two authors are as Amazonian as they come.

Working Backwards has two goals: first, it attempts to explain how Amazon does what it does. Second, it argues that you may apply these techniques to your own company. The first goal is an exercise in justification: the authors will explain how a technique originated in Amazon, and then use that as an explanation for how the company is able to achieve certain unique results. After they explain this, the authors switch modes to argue that you, too, may apply these methods to your company. Presumably, the latter argument assumes that you are in a position of power; many of the ‘mechanisms’ that Bryar and Carr describe are difficult to implement if you do not have buy-in at the highest levels of leadership.

Is the book sufficient to explain how Amazon does what it does? No. Amazon is in many ways like an onion — it consists of layers that must be peeled back. Interested observers have long pointed out that Amazon’s capital allocation process is interesting, with a focus on absolute dollar free cash flow (2004 shareholder letter; Justin Fox’s HBR article; Tren Griffin’s Twitter commentary, taken from a conversation with Cliff Asness.) Also interesting is Benedict Evan’s observation that ‘everything at Amazon has an angle’, when discussing Amazon’s ads business. But the key contribution of this book is that it provides a layer of the onion that many Amazon analysts have not had access to before — the authors offer up an explanation of Amazon’s day-to-day execution. That is, they explain how Amazon is able to achieve its operational excellence, and what it does differently from others.

Let’s take the first goal by itself: what lies at the heart of Amazon’s operational excellence? The core argument that Bryar and Carr make is that Amazon is able to do the things they do because a) the company has a set of leadership principles that it takes very seriously, and b) it has a set of five mechanisms that allow the company to achieve its unique results.

The book is structured along those lines. The first six chapters explain each of these ideas:

1. Chapter 1: The Leadership Principles — Bryar and Carr describe Amazon’s leadership principles, and explain that it is the basis on which every mechanism is measured against. They also explain the core concept of ‘principles’ vs ‘mechanism’.
2. Chapter 2: The Bar Raiser Process — The authors describe a hiring process that ensures Amazon maintains a) the quality of its people while b) gatekeeping against people who aren’t a good fit for its leadership principles.
3. Chapter 3: The Single Threaded Leadership Model — This chapter describes a decentralised org design that enables Amazon to spin-up, enter, and dominate new markets.
4. Chapter 4: The 6-Pager Narrative — Bryar describes how they came up with a replacement for Powerpoint in company meetings. Amazon replaced slides with ‘6-pager narratives’, a form of memo-writing that allows teams to synthesise and evaluate complex streams of information. Coincidentally, this ‘6-pager narrative’ format enables Amazon to execute on its decentralised org structure, because it frees leadership to make complex decisions even as the org grows.
5. Chapter 5: The Working Backwards Process — This is Amazon’s famed PR/FAQ product development process, which I’ve covered in a previous blog post.
6. Chapter 6: Controllable Input Metrics vs Output Metrics — This explains how Amazon measures itself, and why this is the foundation for their operational excellence.

The rest of the book tells the stories of four products — the Kindle, Amazon Prime, Prime Video, and AWS, as an illustration of these leadership principles (and mechanisms!) in action.

I’ll be up front here: this piece will not be a comprehensive summary — you cannot take these techniques and apply them to your company without first understanding the conditions that led to their creation. This will become abundantly clear once we get through the next section, on Amazon’s leadership principles.

Table of Contents

• The Leadership Principles
• The Bar Raiser Process
• Single Threaded Leadership
• Narratives and the Six Pager
• PR/FAQs — The Working Backwards Process
• Controllable Input Metrics
• Wrapping Up

The Leadership Principles

Amazon has a list of 14 leadership principles, which are available here. They are:

1. Customer Obsession
2. Ownership
3. Invent and Simplify
4. Are Right, A Lot
5. Learn and Be Curious
6. Hire and Develop the Best
7. Insist on the Highest Standards
8. Think Big
9. Bias for Action
10. Frugality
11. Earn Trust
12. Dive Deep
13. Have Backbone; Disagree and Commit
14. Deliver Results

Yes, I know, you’re probably reading this right now and rolling your eyes. (A friend who read Working Backwards stopped reading after the first chapter, telling me “Ok, so Amazon has got a bunch of nice leadership principles — but they’re unique to their company! What’s the point of reading about them? If I want to use these, I should come up with a list of my own.”)

This is both correct and incorrect. 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:

1. 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).
2. 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:

1. 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).
2. 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?”)
3. 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 authors write:

What distinguishes Amazon is that its Leadership Principles are deeply ingrained in every significant process and function at the company. In many cases, the principles dictate a way of thinking or doing work that is different from the way that most companies operate. As a result, 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.

When seen in this light, 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. Former Head of Partner and Framework Marketing Jesse Freeman writes, of his experiences working there:

I think the last few bits of advice I’ll leave you with are how important the leadership principles come into play when reviewing a document and receiving feedback without taking it personally. The leadership principles give you a sort of rules of engagement on how to be direct with a co-worker and walk away civil. While I don’t fully drink the kool-aid, it’s impossible to survive at Amazon without weaponizing these principles in your meetings. Sometimes it’s to attack and others times to defend, but most of all, you want to always “dive deep.”

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

Over the next few sections, we will cover the five ‘mechanisms’ that make up the bulk of the book. These mechanisms are processes and techniques that Amazon developed to achieve its goals, and they are best understood as things that work in the context that is Amazon. I don’t want to understate this point: I spent about 3000 words describing Amazon’s product development process in my previous blog post, but one question that nobody seems to have asked is: “why does it not spiral into a ‘design-by-committee’ type situation?” The answer, of course, lies in Amazon’s unique culture, best exemplified by its leadership principles. You really do have to read the book to understand the context in which Amazon’s mechanisms work.

Ultimately, this is why I’m not writing a comprehensive summary here — I believe that you should buy the book, and read it!

What follows is a short sketch of each mechanism, to give you an idea of why Amazon is able to do the things it does. Just keep in mind that my summary isn’t enough if you want to apply these techniques to your own organisation. You’ll need to adapt it to fit your org, and such adaptation demands that you understand the original conditions the process was originally created for.

The Bar Raiser Process

As I’ve mentioned in the previous section, Amazon’s leadership principles enables it to deliberately shape internal culture, which it does by a) indoctrination, b) careful hiring of people who are already likely to fit into said culture, and c) mechanism design.

The Bar Raiser process is Amazon’s hiring methodology. The authors write about this process:

It is impossible to quantify how successful this process, which we called the Bar Raiser, has been or to establish its importance, relative to other factors, in Amazon’s rapid growth. What we can say is that it was common for experienced newcomers to assert that the Bar Raiser process was (a) unlike anything they had ever seen and (b) one of Amazon’s secret weapons. We don’t claim that this process is the only good one, or that it will entirely eliminate poor hiring decisions. What we can promise is that it is significantly better than the methods (or lack of methods) many companies rely on, and that it will likely raise your ratio of hits to misses significantly. We can also point to countless examples of leaders whom we would hire externally, place them immediately into strategically critical roles, and watch them thrive and in many cases stay with the company for ten-plus years.

The bones of Amazon’s hiring process is basically a structured interview process (which we last talked about here, and which is widely considered to be the best type of job interview process). In a structured job interview:

• The interviewer has a predetermined set of criteria to assess. This is often spread across multiple members in the hiring team.
• During the interview, the interviewer scores the candidate on each criteria they are assigned to assess, before doing an overall judgment at the very end.
• Interviewers are not allowed to discuss the candidate until they have all done their evaluations. Only after all interviews are done may they come together to pool their judgments.

Together, these properties make it possible for interviewers to come to a standardised assessment, while resisting confirmation bias and groupthink. So far, so standard. Amazon’s contribution is to add the following twists:

• Every hiring loop is assigned someone called a ‘Bar Raiser’. A Bar Raiser belongs to a special class of individuals within Amazon who are effectively the ‘guardians’ of the interview process. (They are so named to signal to everyone that every new hire should ‘raise the bar’). In the beginning, the first Bar Raisers were gifted interviewers who consistently made good hires. Over time, these people invited other promising interviewers into the fold, and created a special training program to lock in the principles and details of the process. This meant that the knowledge transfer was effectively tacit in nature.
• The Bar Raiser is given the power to veto any hiring decision. If they say no, the candidate is out.
• The Bar Raiser is also the person that teaches Amazon’s hiring process, ensures that it is followed, and coaches all participants — from hiring manager to recruiter, to each individual interviewer — on the right standards for hiring. They are expected to review even the job description, and to hold everyone up to Amazon’s standards throughout the entire process. (Basically, if you write substandard interview notes, or if you submit your interview notes late, expect a visit from your Bar Raiser).
• You are only able to become a Bar Raiser if you have consistently made good interviewing choices in the past, and if an existing Bar Raiser invites you to the program. Even then, you may fail the special training that you would have to undergo to become one yourself.
• Amazon does not pay extra compensation for Bar Raisers; it merely gives you a badge in the internal employee portal. The benefit, presumably, is that you enjoy working in an idiot-free place, and you belong to the special class of people whose job is to ensure no idiots get into the company.*

(*Presumably this method fails somewhat, at scale — like any large org, there are pockets of badness. But when an org becomes large, you evaluate it by how badly it does compared to all the other orgs of equivalent size, and on this front Amazon seems to be marginally better. Or at least that’s what my friends tell me.)

Why does Amazon do things this way? The answer is rooted in simple incentives. Imagine that you are a manager, that your team is understaffed, and that you are behind on your quarterly goals. It is extremely tempting in such a scenario to temporarily drop your hiring standards, in order to get people in quickly so you can hit your goals.

But repeat this a few times, across multiple teams, and you’ll end up with a shitty organisation. Amazon created this process so that the urgency to hire never overwhelms the minimum acceptable standard for talent. Bar Raisers never belong to the team that is hiring; they come from other parts of the company. They are given absolute power to veto a hiring decision. And they have very different incentives from the hiring manager’s and the recruiter’s.

Single Threaded Leadership

I’ll let the authors open this one:

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.

Of the five mechanisms that are covered in Working Backwards, the ‘single threaded leader’ idea is likely the most difficult to put to practice. Amazon needed to reorganise its entire company to implement this idea (and the book tells the full story!) — but the point is that anything less than that is likely to fail.

The core insight behind ‘single threaded leadership’ is that teams that are autonomous, and led by a single person with a clear mandate, are able to move quickly to achieve its goals. The problem with that statement is with the word ‘autonomous’. Most teams in most companies aren’t autonomous. Think about what it means, for instance: let’s say that you want to implement a new feature on the Amazon web site. In 1998, Colin Bryar wanted to implement the feature that tracked purchases from anyone who came to Amazon.com from an Amazon Associates referral link. Bryar had to do the following things:

1. He had to get his team to make the relevant changes to the Amazon.com monolithic webapp. This required code reviews from every other team whose features were connected to the proposed referral feature: this meant teams that were responsible for creating a product page, putting the product in the shopping cart, finalising an order, tracking a return, and so on. On top of that, Bryar’s team had to review all the changes made to their code from every other team that intersected with them.
2. He had to submit to a design review by Amazon’s ‘DB Cabal’, a team of three leaders who managed migrations to Amazon.com’s underlying relational database. The submission had to join a queue of every other database change request — and there really wasn’t any way around it; the whole rigmarole was necessitated by the complexity of Amazon’s monolithic webapp. The company couldn’t afford to have Amazon.com go down, so painstaking design reviews it was.

In other words, Amazon’s pace of execution was limited by the number of dependencies they incurred in the org — both technical and organisational. Bryar noticed that he could move quickly in every other area that was decoupled: for instance, the reporting, accounting, and payment changes for the referral feature happened rapidly. But then he was blocked on the parts that depended on other teams.

Bezos’s solution for this problem? Get rid of it. Bryar writes:

In my tenure at Amazon I heard him (Bezos) 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. (emphasis mine)

And of course this was what they did, but it was a painful process that took them a number of years. (For another look at this process, read Steve Yegge's infamous Google Platform Rant, which discussed Bezos's ‘services first’ mandate).

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:

1. 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.
2. 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).
3. 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:
4. 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?’”
5. 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.
6. 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.

The authors conclude:

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.

Which, sure, this explains a lot, but I can't imagine the amount of pain it took them to get there. Kudos to Amazon; I look forward to hearing about another org that attempts to apply this idea to their operations.

Narratives and the Six Pager

Amazon very famously eschews Powerpoint presentations for meetings and instead does something it calls ‘Narratives’ — six page, incredibly dense written documents that it expects participants to read at the start of every meeting. The six page limit was chosen very deliberately — Amazon expects people to read at about three minutes per page, and sets aside the first 20 minutes of every hour-long meeting for silent, communal reading.

I’m going to do a very short summary of this idea, since it’s fairly well known, and instead point you to a good breakdown of the Six Pager format by former Amazonian Jesse Freeman.

The first thing to know about Amazon’s Six Pagers is that they were created in response to a very particular problem. Bryar and Carr write:

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

In those early days, each deep dive would begin with a presentation by the relevant team on the status of their work toward the goal. Typically, this involved an oral presentation by one or more of the team members backed up by PowerPoint slides. Too often, we found, the presentations did not serve the purpose for which they were intended. The format often made it difficult to evaluate the actual progress and prevented the presentations from proceeding as planned. The deep dives were, in short, frustrating, inefficient, and error prone for both the presenter and the audience.

Sometime in 2004, Bezos and Bryar spent a business flight reading Edward Tufte’s essay The Cognitive Style of PowerPoint: Pitching Out Corrupts Within. Tufte argued that ‘as analysis becomes more causal, multivariate, comparative, evidence based, and resolution-intense, the more damaging the bullet list becomes.’ He then closed the essay with the recommendation: “Making this transition in large organisations requires a straightforward executive order: From now on your presentation software is Microsoft Word, not PowerPoint. Get used to it.”

Which is what they did.

Bezos later articulated the reasoning for the transition, writing:

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.

As a result, Amazon’s Six Pager approach allowed leaders across the organisation to make better judgments on complex information flows. Writing a Six Pager is extremely time consuming, since it must withstand the scrutiny of every leader present. But I particularly like this segment in Working Backwards, where Bryar explains:

Because examples of excellent six-page narratives are disseminated throughout the company, and because expectations about their nature and quality are so well understood by employees, it rarely happens that a team presents a substandard narrative at a meeting. I did once receive a six-pager that was not up to snuff. The team who wrote it was glossing over hard problems with platitudes. I politely handed it back to them, said it wasn’t ready to be discussed, adjourned the meeting, and suggested they use the time to work on improving the narrative. But, as I said, those scenarios are extremely rare. Mostly it’s about supporting the team by giving robust feedback. 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. (emphasis mine)

The second thing to know about Amazon Six Pagers is that they are rarely ever six pages long — only the first six pages are intended to be read in meeting. The rest of the document is an appendix. In his how-to piece, Jesse Freeman writes:

The first thing you probably noticed is that my 6-pager is using 10 point font. These things are dense, and there is a strict rule around it being exactly six pages. The goal is to fill up all six pages without any filler. The other thing you may have noticed is that the document isn’t six pages, it’s much longer. The perceived length of a 6-pager is a bit of a misconception. I’ve written 6-pagers that were over 40 pages long. The reason for this is because of the appendix.

The main goal of authoring this kind of document is to craft the entire thing as a narrative. That doesn’t mean it needs to be an entertaining story. It merely means there are no bullet-point lists, no graphics, and no fluff in the document’s core 6-pages. Since it’s difficult to sum up the contextual information like data, graphs, or examples in narrative form, you can add it to the end of the document in an appendix. This allows the reader to choose what to look up for additional information as needed. It also allows you to store bulky, complex data visualisations without breaking up the narrative’s flow.

Freeman's sample Six Pager is ridiculously dense, I suggest you check it out in its entirety.

Unlike single-threaded leadership, Amazon Six Pagers seem like a more tractable change to most orgs. I look forward to trying them out.

PR/FAQs — The Working Backwards Process

I’ve covered the Working Backwards process in my previous blog post on the idea, so I’d encourage you to read that instead.

I'd like to cover only one idea here: that is, the question that I mentioned earlier in this piece, on “why does it not spiral into a ‘design-by-committee’ type situation?”

The answer seems to be that the ability to evaluate new product proposals is built up tacitly and passed down by osmosis (exactly like a tacit knowledge process would!); Bryar and Carr write:

The PR/FAQ review process can be stressful, no matter how constructive and unbiased the feedback. Gaps will be found! A PR/FAQ under serious consideration for implementation will typically require multiple drafts and meetings with the leadership. Senior managers, directors, and executive leaders who oversee the authors of PR/FAQs become skilled evaluators and contributors to the process. The more PR/FAQs they read, and the more products they build and launch using the PR/FAQ process, the more capable they become at identifying the omissions and flaws in the author’s thinking. And so the process itself creates a tier of master evaluators as it vets and strengthens the idea and aligns everyone involved in the project, from individual contributor to CEO (emphasis mine). It also increases the likelihood that a project will be approved and funded.

If you want to implement the PR/FAQ document at your company, know that there’s a tacit element here that can’t be easily explicated; you should expect to do it a few times before you get the ‘feel’ of it.

Controllable Input Metrics

The final mechanism that Bryar and Carr cover in Working Backwards is Amazon’s notion of ‘controllable input metrics vs output metrics’. This is a fancy name for what is more generally known as ‘leading indicators’ or ‘lagging indicators’, except that Amazon uses a different name, because … well, Amazon.

The book’s contribution is two-fold: first they outline the method Amazon uses to go from an output metric to a controllable input metric. This is a lot more profound than you might think! As I’ve written elsewhere:

(…) why do I find the idea so profound?

The simple answer is that we are not taught to think like this. When people say “be more data driven”, we immediately assume, “oh, we have to measure our business outcomes”. And so we measure things like number of deals closed, or cohort retention rates, or revenue growth, or number of blog visitors. These are all output metrics — and while they are important, they are also not particularly actionable.

Amazon argues that it’s not enough to know your output metrics. In fact, they go even further, and say that you shouldn’t pay much attention to your output metrics; you should pay attention to the controllable input metrics that you know will affect those output metrics. It is a very different thing when, say, your customer support team knows that their performance bonuses are tied to a combination of NPS and ‘% of support tickets closed within 3 days’. If you have clearly demonstrated a link between the former and the latter, then everyone on that team would be incentivised to come up with process improvements to bring that % up!

The second contribution that Working Backwards gives us is an in-depth description of the Weekly Business Review, or WBR — the single most important tactical meeting that Amazon conducts every week. It is intense, and regimented down to the prescribed designs of the graphs and charts.

Chapter 6 is probably the chapter that best demonstrates the thoughtfulness that Amazon brings to its operational excellence, and embedded within the chapter — in a blink-and-you-miss-it manner — is a set of ideas for preventing Goodhart’s Law-type scenarios. To give you a brief overview:

• Every metric has an owner, and every metrics owner is expected to understand what is normal variation and what is an anomaly.
• Metrics are audited by an independent department (finance), which prevents business owners from juicing metrics, or picking metrics that make them look good.
• Metrics are reviewed every week, at the Weekly Business Review meeting. (This occurs fractally — at the top level all the way down to each team).
• The finance department informs both leadership and business owners how they’re tracking for each of their yearly goals, on both input and output metrics.
• Execs and business owners are expected to critically evaluate the effectiveness of every metric, and are allowed to modify or remove them if they are no longer useful.
• Metric owners must have a process for auditing each metric, to check that it measures what it’s supposed to be measuring. The audit process triggers on a periodic basis.

I know, I’m quickly skimming through the ideas here, and the reason I’m doing that is because I’ve already written a comprehensive summary of Chapter 6 over at the Holistics blog. Go read that instead.

Wrapping Up

Working Backwards is a brilliant book. Amazon has been the subject of many essays, research notes, and long-form narratives by many authors over the years. What Bryar and Carr have contributed to the public with WB is that they’ve given us an extra piece of the Amazon puzzle. How does Amazon accomplish everything it’s done? Obviously the answer is some combination of strategic smarts, good cash flow management, savvy capital allocation, and operational rigour. Working Backwards tells us what that last piece actually looks like.

I think the biggest thing that I took away from the book is a particular benchmark against which to compare myself. I used to think that I was operationally rigorous. I used to think that I was pretty good at org design. Reading Working Backwards has been an exercise in humility: I now see that I’m not that good after all. I have a long, long way to go before I’m able to build something like Amazon. But I can’t wait to try.

Originally published 06 April 2021, last updated 13 November 2024.