(by Colin Bryar, Bill Carr)
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.
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.
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 30 May 2021