I recently finished reading “Working Backwards” a book by two tenured Amazon execs about the principles and processes that helped Amazon become the company it is.
It goes without saying that not every process that worked for Amazon will work for other companies, but this week I’ll go into a few key ones that I thought were interesting and at least somewhat unique in their implementation, versions of which may apply to other companies.
1. The Bar Raiser Program for Hiring
Given the potential impact of a new hire (in both a positive and negative way), many companies don’t tend to take hiring seriously or rigorously enough.
Given that hiring managers often have an urgent need to fill a role, they can sometimes be tempted to go for any candidate that is good enough than waiting for a great candidate for the role. Amazon’s bar raiser program helps counteract this.
The origin of the bar raiser name comes from the philosophy that every new hire should raise the bar (i.e., be better than the other members of the team in some important way).
While the interview process at Amazon is fairly similar to those of other companies, I thought the presence of the bar raiser was an interesting aspect. Here’s how it works:
Bar raisers are specially trained interviewers, one of whom is present in every interview loop. They ensure the right process is followed and bad hiring decisions are avoided.
They are explicitly not the hiring manager or recruiter (meaning they aren’t necessarily under pressure to fill the role) for a given role and conduct one of the interviews in the final round.
They lead and facilitate the debrief and help get the room to a decision on whether the candidate is a hire or no-hire. They also have veto power if they feel a candidate is not raising the bar, although in practice it is rarely exercised.
2. Single-Threaded Leadership for Organizational Structure
From an organizational perspective, Amazon came up with the idea of two pizza teams, especially when it came to new projects to speed up product development. These were:
small teams: under 10 people (can be fed by two pizzas)
autonomous: could largely work via “APIs” and didn’t have too many dependencies on other teams
own the business results of its area of focus and have a clear set of goals and metrics (measured by one fitness function): this helps reduces such excuses between say engineering and business.
While they worked quite well, especially in product development to increase the velocity, it didn’t spread a lot through Amazon. One of the big reasons was that for many projects it became clear you needed more than two pizzas.
What Amazon found was that the size of the two-pizza team didn’t matter as much in its success as whether the leader had the appropriate authority and ability to get the job done, and was solely focused on that.
That led to an evolution of 2-pizza teams into something known as single-threaded leadership.
One of the guiding principles behind it is best illustrated through this quote:
The best way to fail at inventing something is by making it somebody’s part time job - Dave Limp, SVP at Amazon
Here’s how single-threaded leadership works:
The team leader is solely focused on the team’s charter and objective and isn’t juggling multiple areas or initiatives
The team is autonomous and separable in that it can largely interact with other teams via APIs and has minimum org dependencies
The team has unambiguous ownership of specific features and functionality and can drive innovation with minimum reliance on others
The benefits of single-threaded leadership are:
teams can move quickly with minimal dependencies considering the size of the company
teams have clear focus and accountability across the team
the leader can take a broad view across functions as it relates to the team’s area.
The last benefit is highlighted by the anecdote below from Working Backwards:
For example, with Amazon Echo and Alexa, were it not for the fact that Amazon VP Greg Hart was assigned to be the single-threaded leader, there might have been one person in charge of hardware and another in charge of software for all of Amazon’s devices—but no one whose job it was to create and launch Amazon Echo and Alexa as a whole. On the contrary, a single-threaded leader of Amazon Echo and Alexa had the freedom and autonomy to assess the novel product problems that needed to be solved, decide what and how many teams they needed, how the responsibilities should be divided up among the teams, and how big each team should be.
3. Six-Page Memos for Decision Making and Reviews
Perhaps one of the more famous of Amazon’s mechanisms is the use of a six-page memo in place of presentations.
Bezos was famously not a fan of Powerpoint, believing it leads to the loss of nuance and was often used as a crutch.
In June 2004, an email circulated to the leadership team, “No PowerPoint presentations from now on”. And ever since then Amazon has used narratives in the forms of memos rather than presentations.
Here’s how it works:
What: The memo is a document of up to six pages that includes a thorough analysis of the ideas presented and is typically self-contained (i.e., doesn’t need a supporting oral presentation). The page limit excludes supporting appendix items.
Structure: While the exact structure of the memo varies depending on the context of the meeting, memos typically contain several sections and often contain supporting graphs and charts. Typically, an introduction section is followed by a Tenet’s section which outlines the key ideas that the proposal relies on. Many also contain an Options and Recommendation section.
Meeting Format: The memo is shared at the start of the meeting and is read in silence by all attendees (the appendix is typically not read) for the first 20 or so minutes. The rest of the meeting time is used for discussion.
For the writer: While six-page memos are more difficult to make than PowerPoint presentations, they force clarity of thought and more nuanced and rigorous thinking.
For readers: 6-page narratives have ~7-10X the number of words as a presentation, and so are a lot more information-dense. They also allow for non-linear arguments to flow more naturally compared to presentations, and so make it easier to interconnect ideas.
For those not present: Memos are self-contained and so are scalable and can be shared easily with those not present, without any loss of context.
Removes biases: Memos are ready silently, and so remove any biases that stem from presentation style and focus on clarity of thought and communication of ideas. They elevate the written word over body language and the spoken word.
4. The PR/FAQ for Product Development
A widely known tenet of Amazon has been to start with the customer and work backward. But perhaps one of the lesser-known things is the PR/FAQ narrative document used in product development to help work backward while developing new and innovative products.
The PR/FAQ document stands for Press Release/Frequently Asked Questions and is a document used to pitch new products at Amazon. The point of the document is to consider things from the customers’ point of view rather than the companies point of view.
What: The PR/FAQ contains two portions: the press release and the frequently asked questions.
The press release, which is typically under one page, is a potential press release of the product when launched (though prepared before work on the product has begun) and highlights the customer experience and benefit. It typically contains the following sections:
Heading: “ABC co announces the launch of Product ABC”
Subheading: description of product and benefits to the customer
Summary Paragraph: Summary of the launch
Problem Paragraph: Describe the problem the customer currently faces today
Solution Paragraph: Describe the product and how it simply/easily/cheaply solves the customer problem
Customer Quote / Link: A quote from the team and customer and a link to the product / how the customer can purchase it
The FAQ portion contains both internal and external questions that might come up and goes into the details of the customer experience and how difficult it will be to deliver the experience to customers and is typically under five pages long. The FAQ typically contains the following:
Consumer needs and TAM
Economics and P&L of product/service
Dependencies / Partnerships needed to build / launch
Use: The PR/FAQ is prepared by the team or individual who originated the idea. It is shared with stakeholders in a meeting, where everyone provides detailed feedback. It then goes through revisions based on feedback and eventually is taken up the chain to senior leadership and greenlit or dissolved. The typical PR/FAQ may go through multiple revisions, which often means that the product idea is changing as well, as the messaging and details are changing.
One important point to note is that the PR/FAQ doesn’t have to result in the product being greenlit to be successful. It may be a quicker way to invalidate an idea in terms of recognizing that the market wasn’t big enough, the pain point wasn’t big enough, the economics couldn’t work or there were too many constraints to build.
In that sense, it is a way to enable the team to gain a thorough understanding of the opportunity and market and whether a solution is feasible, without necessarily going out and building it.
If you liked this, I recommend the book Working Backwards which goes much further into depth into these and other practices, and covers how some key products at Amazon were built.
I also recommend an earlier piece I wrote on some lessons from Bezos’s Shareholder Letters.
Thanks for reading! If you liked this post, give it a heart up above to help others find it or share it with your friends.
If you have any comments or thoughts, feel free to tweet at me.
If you’re not a subscriber, you can subscribe below. I write about things related to technology and business once a week on Mondays.