PDF Summary:Working Backwards, by Colin Bryar and Bill Carr

If you want to start a successful business, many would argue that Amazon is the one to imitate. In just a few decades, Amazon has grown from an obscure internet startup to a household name, raking in hundreds of billions of dollars by offering a vast range of products and services. In Working Backwards, Amazon insiders Colin Bryar and Bill Carr explain how the company achieved its meteoric growth and argue that any organization can do the same.

In this guide, you’ll learn the specific tools Amazon used to rapidly scale their startup into an online empire. You’ll see how Amazon designs its meetings to facilitate rigorous thinking and how they use narrowly focused teams to execute their plans. In our commentary, we’ll expand on Bryar and Carr’s advice with tips from business books like What You Do Is Who You Are and The Lean Startup. We’ll also offer counterpoints to Amazon’s business philosophy with alternative strategies from books like Range and It Doesn’t Have to Be Crazy at Work.

(continued)...

In It Doesn’t Have to Be Crazy at Work, Jason Fried and David Heinemeier Hansson also seek to replace traditional in-person presentations with a meeting format more suitable for deep thinking. However, they conclude that the best format for such thinking is asynchronous discussion.

Like Bryar and Carr, Fried and Hansson recommend that employees distill everything they would put in a presentation into a detailed text document. However, rather than call a meeting to discuss this document, they recommend just posting it somewhere everyone can see it, like a shared workplace server. Then, allow the team to read and consider the document over several days before posting feedback.

Fried and Hansson find that workers discover their best insights when they can consider a set of ideas nonlinearly over several days. For instance, an employee might re-read the document five times in its entirety or keep referring back to a single page of data while developing their response.

If a DTD empowers presenters to pose complex ideas, as Bryar and Carr claim, their audience arguably needs more time to digest those ideas. Amazon allows meeting participants to engage with the document nonlinearly at their own pace but only within certain time limits—they just have the beginning of the meeting to digest the presenter’s ideas. According to Fried and Hansson, such time-sensitive meetings lead to knee-jerk reactions from the audience, which result in poorer business decisions.

Tool #3: The DMAIC Process

The next tool we’ll discuss is the DMAIC process—Amazon’s five-step procedure for evaluating progress and discovering business solutions. DMAIC is an acronym for Define, Measure, Analyze, Improve, Control—the five steps to improving any part of your business. Amazon didn’t invent this process; rather, they adopted it from a set of business practices invented in the 1980s called Six Sigma.

(Shortform note: This Six Sigma process was invented in 1986 by Bill Smith, a senior engineer working for Motorola. Nowadays, you can earn a “Six Sigma certification” by taking a course to master the five-step DMAIC process (among other Six Sigma tools). Many independent organizations offer these courses, and certifications are in demand among many employers. Earning a Six Sigma certification can increase your earning potential and job opportunities in a wide variety of fields, from human resources to IT.)

Let’s take a look at each step of the DMAIC process, spending a bit more time on step one (which is more complex), then briefly covering the other four steps.

Defining Your Metrics

Bryar and Carr assert that Amazon uses the DMAIC process to implement its principle of prioritizing the customer experience and working backwards, as we can see in step one: Define.

Specifically, define a set of metrics to track and optimize that accurately represent the quality of the customer experience. In other words, you must identify ways to assess how well you satisfy customers before working backwards to figure out how to satisfy customers even more (in the rest of the DMAIC process). These metrics should be quantitative—expressible in numerical data—so you can analyze them clearly and precisely. For example, if you’re managing a fast food restaurant, one of the metrics you define could be “average time between customer order and food delivery.”

Additionally, Bryar and Carr stress that the metrics you define should be input metrics rather than output metrics. In other words, focus on aspects of your business you can directly control rather than those you can’t. Speed of food delivery, as in the example above, would be an input metric, while statistics like your total number of customers or percentage of five-star user reviews would be output metrics.

Using the Scientific Method to Choose Metrics

In The Lean Startup, Eric Ries offers a more specific technique that entrepreneurs can use to choose metrics that accurately reflect their business’s success. Ries contends that the best way to learn how to improve your business is to run it like a science experiment: Develop hypotheses about what you’re selling, then launch and see if your hypotheses are true. In particular, develop a “value hypothesis,” which theorizes that customers want to pay for what you’re selling, and a “growth hypothesis,” which is a theory that describes how your company will grow after early success.

According to Ries, the best metrics are typically those with the power to prove or disprove these hypotheses. If your core assumptions about the business are false—if it’s not valuable or doesn’t have the potential for growth—your business is doomed to fail. Thus, metrics that verify these hypotheses are the most accurate indicators of your business’s health.

For example, if your business is an app that helps pet owners find pet-sitters, your value hypothesis might be “If people can instantly find pet-sitters for a low enough price, they’ll gladly pay strangers through my app.” Your growth hypothesis might be “If users have a good experience on my app, they’ll refer enough of their friends to support the business.” Then, you could identify metrics to track that prove or disprove these hypotheses: Track the number of customers you get on an average day (value hypothesis) and the number of referrals per 100 users (growth hypothesis). You decide that if you get 10 users a day and 10 referrals per 100 users, your hypotheses are correct.

Bryar and Carr would likely admit that these metrics reflect customer satisfaction (more users and referrals indicate that your product is better). However, they might argue that they’re output metrics rather than input metrics. That is, even if you track these statistics, they don’t tell you how you can improve. Bryar and Carr might instead recommend you measure input metrics you can directly influence, like the price at which you can afford to offer the pet-sitting service.

Measure, Analyze, Improve, Control

As Bryar and Carr explain, after you define your metrics, step two of the DMAIC process is Measure: Set up tools for continually gathering data on the metrics you’ve defined. Step three is Analyze: Identify all the determining factors that influence your input metrics. Then, Improve: Change the determining factors you’ve identified in a way that improves your metrics. Finally, Control: Monitor your improved processes and make sure your input metrics don’t show signs of backsliding.

Let’s return to our restaurant example. If you’ve defined one of your restaurant’s input metrics as the speed of food delivery, the last four steps of DMAIC might look like this:

• Measure: You create software that automatically times how long it takes for your fast food employees to cook and serve each meal.
• Analyze: You discover that the speed of food delivery depends on how long the food takes to prepare and how busy the restaurant is.
• Improve: You simplify the recipe of your most popular menu item to shorten the time it takes to prepare.
• Control: You continue monitoring your food delivery speed and investigating if it ever slips up.

DMAIC and DMADV

The DMAIC process closely mirrors another Six Sigma process, DMADV. This is a five-step process used for product development. The steps are:

• Define: Identify the customer problem your new product will solve and the resources you have to solve it.

• Measure: Identify your customers’ most pressing needs and find ways to measure how well your product fills those needs.

• Analyze: Generate multiple possible designs that fulfill those needs.

• Design: Choose the most promising design and turn it into a working prototype.

• Verify: Test the prototype and decide whether to produce it at scale.

Arguably, this process will typically yield less revolutionary results than Amazon’s product development process (which, as we discussed, starts with the Product Development Proposal). DMADV is a way of working forwards rather than backwards, since the Define step prompts you to limit your vision to what you currently have the resources to create.

Tool #4: Big-Picture Planning

The last of the strategy development tools we’ll be discussing is the big-picture planning process. Bryar and Carr explain that this is the procedure Amazon uses twice a year to determine what universal company goals all employees should prioritize.

First, the highest-level executives in the company set some broad goals that all teams in the company can collectively work toward; for instance, for the company to earn a certain amount of revenue this year. Then, leaders from each team write DTDs proposing numerous strategies and projects—the ways their specific team will help the company reach its goals in the coming year. In these narratives, they formally request the funds and other resources they need to accomplish their goals.

Last, executives review these proposals, and the highest-level executives choose a certain number of them for each team to prioritize over the others. For example, if a marketing team proposes a social media advertising campaign, a new email newsletter, and a partnership with a YouTube influencer, the executives might approve all three goals but request that the team prioritize the email newsletter.

This back-and-forth process where team leaders and executives build off of each other’s proposals ensures that team leaders and executives agree on what each team can and should be doing.

Amazon’s Big-Picture Planning Enables Emergent Intelligence

In Team of Teams, Stanley McChrystal contends that the most effective organizations display emergent intelligence—this is when a collection of teams can solve complex problems without any central part of the organization coordinating their actions. By allowing lower-ranking team leaders to propose the specific goals of their own teams’ work, Amazon creates the conditions for this emergent intelligence to arise. Individual teams know better than executives how their specific team can be most effective, so they’re better suited to dictate their actions.

McChrystal also notes that workers make better decisions when they understand how the organization works as a whole. At Amazon, high-ranking executives are the ones with the most big-picture knowledge of how the different parts of the company work together. This makes them well-suited to set overarching company goals and prioritize the goals of the teams below them.

However, McChrystal notes a potential risk of the Amazon planning process that Byrar and Carr don’t mention: To be effective, the members of all teams (not just executives) need to understand how the organization works holistically—at least at a basic level. If you implement a planning process like this, make sure that executives give their subordinates enough broad information about the organization for them to formulate the best goals.

That said, it’s possible to take information-sharing too far. It would be a waste of everyone’s time if all leaders had to be aware of every little detail of what goes on in the company—this is likely why Amazon only has these big-picture planning sessions twice a year.

Big-Picture Planning Requires Detailed Information

According to Bryar and Carr, one way in which Amazon’s big-picture planning process is different from that of other companies is how it incorporates another one of their guiding principles: Leaders should constantly probe for details until they understand their subordinates’ work at a granular level. Whereas most managers only care about what their subordinates do, Amazon leaders concern themselves with how their subordinates get things done. This way, they can do everything in their power to ensure that those below them are making progress toward the company’s goals. If they see their team is using an ineffective strategy, they may choose to intervene.

For example, whereas a traditional head of a marketing department would tell their subordinates to launch an email newsletter and report back when it’s done, an Amazon manager would request much more information before ordering their team to prioritize the newsletter. They might ask their team to sketch out a strategic timeline for the first few months of the newsletter, request a more detailed budget breakdown, and ask to see a sample email before giving their team the go-ahead.

Counterpoint: Beware of Micromanagement

When engaging with the granular details of your subordinates’ work, be careful not to cross the line into micromanagement. In The Dichotomy of Leadership, Jocko Willink and Leif Babin warn that leaders who take responsibility for their team’s success may try to control everything their subordinates do to accomplish that goal. However, such a micromanaging manager teaches subordinates that their way is the only “right” way to do things, encouraging the team to wait for instructions instead of inventing their own paths to success.

For this reason, Willink and Babin recommend that managers be much more hands-off than Bryar and Carr advise. If a manager even checks in on their team’s progress too frequently, their subordinates may perceive it as micromanagement.

Amazon’s Tools for Building Productive Teams

So far, we’ve discussed a handful of tools that Amazon uses to rapidly develop strategies with the greatest chance of success. In the final section of this guide, we’ll explore two more tools Amazon uses for consistent success—this time, tools that Amazon uses to build productive teams that can execute the strategies they develop. These tools are meant to reinforce more of Amazon’s guiding principles.

• Tool #1: Rigorous Hiring Process
• Tool #2: Single-Responsibility Teams

Tool #1: Rigorous Hiring Process

The first tool for building teams we’ll discuss is Amazon’s uniquely rigorous hiring process. Amazon strives to perfect their hiring process because of another one of their guiding principles: Only hire applicants with the potential to be better than the existing team.

According to Bryar and Carr, hiring top talent is important because the quality of new hires determines your organization’s culture. As your company grows, new hires will quickly outnumber veteran team members and make up the vast majority of the team. If your lenient hiring process leads to new hires with low standards for their work, it can create a permanent culture of low standards across the organization.

(Shortform note: In No Rules Rules, Netflix CEO Reed Hastings takes this idea further, arguing that managers should not only exclusively hire employees with the highest standards on the market, but also fire employees who let their work slip below the organization’s standards. He concurs with Bryar and Carr that an organization's culture is determined by the standards held by the majority of employees. If everyone on the team performs at an elite level, each employee will be motivated to do their best and excited to work with such talented coworkers. According to Hastings, if all new hires understand that they might be fired for poor performance and that this is nothing to be ashamed of, you can make this high turnover relatively painless.)

In this section, we’ll first explore what makes Amazon’s interview process unconventional; then, we’ll take a look at the company’s unique tactic of appointing a special team of elite interviewers with the power to veto any hire.

Amazon’s Interview Process

Bryar and Carr contend that Amazon has crafted a unique hiring process that can consistently identify the most talented applicants: First, each applicant is separately interviewed by many Amazon employees—typically five to seven. Each interviewer submits their written judgment of the candidate before learning what the other interviewers think—this keeps the group from influencing one another, fostering objectivity. Finally, the interviewers meet and discuss the candidate, ideally coming to a consensus on whether to accept them (although the final decision is usually made by an experienced hiring manager).

Why Do Employers Request So Many Interviews?

Conducting five to seven interviews may seem excessively thorough, but such hiring processes are becoming more common. This is especially true in the age of remote work, as some employers assume that because online interviews are more convenient for applicants, they’re justified in requesting more interviews.

Although Bryar and Carr explain that Amazon assigns many interviewers to each applicant to maintain objectivity, some experts contend that companies do this to deflect individual responsibility. That is, if a new hire turns out to be a poor fit, no one interviewer has to take all the blame. Critics might argue that Amazon does this—when many interviewers convene to define a consensus, it could obscure who’s at “fault” for a botched hire.

With that said, the other elements of Amazon’s hiring process seem to contradict this theory. The company has written records of each interviewer’s pre-written judgment of each candidate, so a judgment that’s accurate in hindsight can be easily traced back to the interviewer who made it. Additionally, since each decision is made by a single hiring manager, they implicitly take some responsibility for each hire.

Culture Protectors in the Interview Process

Another way that Amazon’s hiring process is unique involves a group of specially trained interviewers that we’ll call “Culture Protectors” (Amazon calls this group the “Bar Raisers”). Amazon selects the best interviewers to become Culture Protectors and trains them into masters by coaching them through countless interviews.

The purpose of this group is to ensure that the company doesn’t accept a single low-quality employee. At least one Culture Protector interviews every new employee, and they have the power to reject any applicant, even if the hiring manager wants to hire them. This bias toward rejection ensures that every member of the organization is above a certain baseline of quality, even if it results in understaffing in the short term.

(Shortform note: To further protect their culture, some startups choose to give this veto power not only to a specially trained group of interviewers but also to every employee at the company (at least in the early stages of their business). This ensures that every new employee is more than a highly skilled worker—they’re someone the other team members want to work with. Additionally, new hires feel valued and motivated once they’re told that everyone in the company wanted to hire them.)

Tool #2: Single-Responsibility Teams

The second and final tool for building teams is what we’ll call single-responsibility teams (what Bryar and Carr refer to as “the single-threaded leader model”).

What are single-responsibility teams? Generally, teams at Amazon only work on a single mission; for instance, to expand the business into foreign markets, or to operate and improve a customer service hotline. Each single-responsibility team has a single-responsibility leader whose only job is to lead the team to accomplish its mission. Bryar and Carr argue that this narrow focus ensures that every team accomplishes what it sets out to do.

In contrast, traditional companies typically assign many responsibilities to each team and each employee. If a new project comes up, managers often end up adding it to someone’s to-do list rather than hiring someone new or assigning someone to concentrate on it full-time. Consequently, many workers divide their attention among a wide range of projects, leaving many projects under-prioritized and ultimately unfinished.

How Do Single-Responsibility Teams Implement Amazon’s Guiding Principles?

Bryar and Carr don’t explicitly specify which of Amazon’s guiding principles apply to single-responsibility teams. One of Amazon’s guiding principles is “Ownership,” which states that leaders should take responsibility for every success or failure in the entire company. Later, Bryar and Carr state that single-responsibility teams help their employees take ownership, but they seem to be using the word to mean the opposite of the guiding principle: Single-responsibility teams help employees take narrow ownership of the projects that are exclusively theirs, rather than broad ownership of every success in the company that the guiding principle promotes.

Amazon’s guiding principle of ownership instructs employees to never say “That’s not my job,” but the whole point of single-responsibility teams is to designate the many things that aren’t an Amazon employee’s job. It’s unclear how Bryar and Carr would resolve this contradiction.

Contrasting Single-Responsibility Teams With Single-Function Teams

In High Output Management, Andrew Grove refers to an Amazon-style single-responsibility organization as following a “Mission-Oriented” structure: Each team has a single mission and is responsible for doing everything they need to accomplish it. Grove contrasts this kind of organization with a “Functional” structure, in which each team is only responsible for performing a single function in the service of various missions across the organization. For example, a Functionally structured organization would have an IT department that services computers throughout the company, while a Mission-Oriented organization would have an IT professional on each team working only on that team’s mission.

According to Grove, the Functional structure comes with a number of advantages. For one, it’s more economical—paying a single IT department is typically cheaper than paying IT professionals across the entire organization, as all the teams can share a smaller group of workers. Contrary to Bryar and Carr, Grove contends that Functional structures are also better than Mission-Oriented structures at focusing and completing individual tasks since teams can concentrate on their sole function instead of worrying about other bureaucratic tasks—for instance, an IT department doesn’t have to spend time answering customer service complaints.

However, Grove notes that the Mission-Oriented structure comes with advantages as well—for one, Mission-Oriented teams are flexible and can resolve sudden problems much more quickly because they’re in charge of all the resources they need to do their job. Thus, Grove argues that the most successful companies are those that find ways to combine Mission-Oriented and Functional structures in their organization.

One way in which Grove recommends companies do so is through dual reporting—where one employee reports to two managers who are each responsible for different parts of the employee’s job.

For example, an IT professional might report to a technical manager responsible for the quality of their computer-related work across the company as well as a project manager responsible for one of the specific projects the IT professional is working on. Although the IT professional has more than one responsibility (keeping them from being totally mission-oriented), they report to various single-responsibility leaders whose job is to ensure that each project gets done.

Single-Responsibility Teams Eliminate Dependencies

Another reason single-responsibility teams are so effective is that they’re designed to minimize dependencies, which cause inefficiency. Bryar and Carr explain that dependencies are areas in which a team lacks the resources to solve a problem they’re responsible for and must depend on another team to resolve the issue for them.

If there’s a dependency impeding a single-responsibility team from doing their only job, they work to resolve that dependency rather than work around it. Eventually, every team will resolve all their dependencies, empowering them to accomplish their mission without any outside input. Although resolving dependencies this way takes some time and money, the company empowers teams to do this because it results in a massive increase in efficiency: Fully autonomous teams no longer need to coordinate with other parts of the company (a task that takes a significant amount of time and effort).

For example, imagine a single-responsibility marketing team is trying to expand the business into a foreign country. Initially, they rely on the company’s only translator, who works on the web development team, to review and translate all their marketing copy. This is a dependency, and the marketing team wastes a lot of time waiting for the translator to get back to them. The marketing team realizes it’s their responsibility to resolve this dependency, so they hire a new team member from the country they’re expanding into to help them write their marketing copy. This allows them to roll out their marketing campaign much more quickly.

Dependencies Obstruct Flow at Work

In The Unicorn Project, Gene Kim asserts (through a business-centered fable) that dependencies between teams are particularly damaging to an organization because they prevent workers from entering the flow state. The flow state (as defined by psychologist Mihaly Csikszentmihalyi in Flow) is the state of total immersion in a challenging task. When workers are “in flow,” they feel more confident and capable of doing their job well. Being in flow is also an intrinsically enjoyable experience, so they’ll feel motivated to work more. This increase in confidence and motivation will help any team to be even more productive and efficient.

Dependencies prevent workers from entering flow by depriving them of the power to get their work done autonomously. When workers hit a dependency, they’re forced to do the bureaucratic work of coordinating with other teams. Then, they have to wait around, feeling useless, while the other team handles the problem for them. Both of these tasks are unconducive to the flow state.

In contrast, the act of independently resolving dependencies is arguably conducive to the flow state. To enter the flow state, you must feel like you’re successfully progressing toward your goals. When a team is permanently resolving a dependency, they know that in doing so, they’re making the rest of their work easier for the entire foreseeable future—an attractive goal that no doubt feels satisfying to achieve. This is another reason that empowering teams to resolve dependencies is a wise investment for any company.