Table of Contents
Jeff described Amazon this way: “Our culture is four things:
Amazon’s 14 Leadership Principles
95% internal, 5% external
atypical — 95 percent of the time I spent with Jeff was focused on internal work issues rather than external events like conferences, public speeches, and sports matches.
Place many bets
Jeff often used an analogy in those days when describing our efforts to innovate and build new businesses. “We need to plant many seeds,” he would say, “because we don’t know which one of those seeds will grow into a mighty oak.”
Hands-on leadership with informal communication of Amazon’s philosophy
He wrote the job descriptions, interviewed candidates, packed and shipped boxes, and read every email that went out to customers. Taking part in every aspect of the business allowed him to communicate the Amazon philosophy informally to the relatively small group of employees.
Processes embedded everywhere
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.
Principles shouldn’t be memorised, but internalised
People often ask, “How do you remember all 14 principles?” The answer is not that we are particularly good at memorization. In fact, if a company’s principles must be memorized, it’s a warning sign that they aren’t sufficiently woven into the fabric of that company.
Company-wide processes
Three foundational mechanisms are: the annual planning process; the S-Team goals process (the S-Team consists of the senior vice presidents and direct reports to Jeff Bezos); and Amazon’s compensation plan, which aligns incentives with what’s best for customers and the company over the long term.
Urgency bias in hiring
One of the major pitfalls of needing to hire a lot of new people very quickly is urgency bias: the tendency to overlook a candidate’s flaws because you are overwhelmed with work and need bodies. The Bar Raiser provides teams with methods to make the strongest hires efficiently and quickly, but without cutting corners.
Bar Raiser program for hiring
The Amazon Bar Raiser program has the goal of creating a scalable, repeatable, formal process for consistently making appropriate and successful hiring decisions. Like all good processes, it’s simple to understand, can be easily taught to new people, does not depend on scarce resources (such as a single individual), and has a feedback loop to ensure continual improvement… The Bar Raiser could not be the hiring manager or a recruiter. The Bar Raiser was granted the extraordinary power to veto any hire and override the hiring manager.
8 steps in the Bar Raiser hiring process:
Feedback loop in the hiring process
Amazon tracks and reports on the volume and rate at which candidates pass through the entire recruiting funnel and uses these data to make process changes as well as to coach and train recruiters and hiring managers. This is the hallmark of a well-run recruiting process.
How many interviewers
Typically, the most effective loops consist of five to seven interviewers. The company has found that the returns on having more people than that involved tend to diminish, and that when there are fewer people involved, there are often gaps in knowledge about the candidate. Whatever the exact number of participants, the loop always includes the hiring manager, the recruiter, and a Bar Raiser.
Training interviewers
Amazon runs a half-day course on how the interview process works and how to conduct an interview (more on this shortly). After training, the interviewer is required to pair up with an experienced senior interviewer to jointly conduct at least one real interview before they do one on their own.
Who should not interview
Second, no loop participant should be more than one level below the level of the position the candidate will hold. Nor should there be an interviewer who would become a direct report of the candidate… it is a mistake for direct reports to interview a prospective boss. It’s uncomfortable for the candidate during the interview, and the direct report will learn about the candidate’s weaknesses, and other employees’ views of those weaknesses, during the debrief—which could lead to problems for the future functioning of the team.
bad questions
General, open-ended questions such as “Tell me about your career” or “Walk me through your résumé” are usually a waste of time and will not produce the kind of specific information you’re after.
Good question
The method that Amazon interviewers use for drilling down goes by the acronym STAR (Situation, Task, Action, Result): “What was the situation?” “What were you tasked with?” “What actions did you take?” “What was the result?”
Leave a good impression on all candidates
Amazon interviewers are reminded to keep in mind that every candidate—whether qualified for the job or not—is a potential customer of the company and a source of leads. Assume they will tell their friends and co-workers about their interview experience.
Only written feedback
Written feedback is expected to be specific, detailed, and filled with examples from the interview to address the Leadership Principles assigned to the interviewer. The feedback should be written shortly after the interview is complete to ensure that nothing of value is forgotten. We found it wise to block out fifteen minutes immediately afterward to complete the feedback.
A single leader, single line of accountability
The basic premise is, for each initiative or project, there is a single leader whose focus is that project and that project alone, and that leader oversees teams of people whose attention is similarly focused on that one project.
Leaders get deep into the details
At many companies, when the senior leadership meets, they tend to focus more on big-picture, high-level strategy issues than on execution. At Amazon, it’s the opposite. Amazon leaders toil over the execution details and regularly embody the Dive Deep leadership principle,
Creating the team and the single-threaded leadership
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.
Written format
We found, instead, that a six-page narrative written by a given team is the method that best enables everyone in a meeting to get up to speed quickly and efficiently on the project that team is working on. At the same time, the process of composing that narrative requires the team itself to reflect on the work they’ve been doing or propose to do, and to articulate it clearly to others, thereby sharpening their own thinking about that work.
When growth is linear, communication grows exponentially
As Amazon grew, we realized that despite our best efforts, we were spending too much time coordinating and not enough time building. That’s because, while the growth in employees was linear, the number of their possible lines of communication grew exponentially.
Too much dependancy creates disempowerment
Too much of any kind of dependency not only slows down the pace of innovation but also creates a dispiriting second-order effect: disempowered teams.
Remove communication
In my tenure at Amazon I heard him say many times that if we wanted Amazon to be a place where builders can build, we needed to eliminate communication, not encourage it.
Independant teams with APIs as outputs
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.
Independant decoupled teams
Jeff proposed that instead of finding new and better ways to manage our dependencies, we figure out how to remove them. We could do this, he said, by reorganizing software engineers into smaller teams that would be essentially autonomous, connected to other teams only loosely, and only when unavoidable… A two-pizza team will: Be small. No more than ten people. Be autonomous. They should have no need to coordinate with other teams to get their work done.
Ownership
If multiple teams have direct access to a shared block of software code or some part of a database, they slow each other down… The solution is to encapsulate, that is, assign ownership of a given block of code or part of a database to one team. Anyone else who wants something from that walled-off area must make a well-documented service request via an API.
Building the infrastructure before new products or features
The most successful teams invested much of their early time in removing dependencies and building “instrumentation”—our term for infrastructure used to measure every important action—before they began to innovate, meaning, add new features.
Make decisions faster with less information
Jeff suggested that “most decisions should probably be made with somewhere around 70% of the information you wish you had. If you wait for 90%, in most cases, you’re probably being slow. Plus, either way, you need to be good at quickly recognizing and correcting bad decisions.
The deployment test for team autonomy
a good rule of thumb to see if a team has sufficient autonomy is deployment—can the team build and roll out their changes without coupling, coordination, and approvals from other teams? If the answer is no, then one solution is to carve out a small piece of functionality that can be autonomous and repeat.
Disagree and commit
Disagree and Commit: “Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.”
6-pager or PR/FAQ
Amazon uses two main forms of narrative. The first is known as the “six-pager.” It is used to describe, review, or propose just about any type of idea, process, or business. The second narrative form is the PR/FAQ.
When do bullet points not work?
Tufte identified in one sentence the problem we’d been experiencing: “As analysis becomes more causal, multivariate, comparative, evidence based, and resolution-intense,” he writes, “the more damaging the bullet list becomes.” That description fit our discussions at the S-Team meetings: complex, interconnected, requiring plenty of information to explore, with greater and greater consequences connected to decisions.
Writing is harder than a slide
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.
Interruptions in a presentation
We’ve all seen presenters interrupted and questioned mid-presentation, then struggle to regain their balance by saying things like, “We’ll address that in a few slides.” The flow becomes turbulent, the audience frustrated, the presenter flustered.
Good-looking slides are not required
The time now spent upon crafting gorgeous, graphically elegant slide presentations can be recaptured and used for more important things. We can give back the time and energy now wasted on rehearsing one’s time at the podium and relieve a major, unnecessary stressor for many team leaders. It won’t matter whether the presenter is a great salesperson, a complete introvert, a new hire out of college, or a VP with 20 years of experience; what matters will be found on the page.
Time saved in reading
Tufte estimates that people read three times faster than the typical presenter can talk, meaning that they can absorb that much more information in a given time while reading a narrative than while listening to a PP presentation.
Reading the narrative to seek ou questions
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.
Work back form the customer experience
Working Backwards is a systematic way to vet ideas and create new products. Its key tenet is to start by defining the customer experience, then iteratively work backwards from that point until the team achieves clarity of thought around what to build.
What not to focus on
In the early stages of its development—before we got started on the press release approach and when we were still using PowerPoint and Excel—we had not described a device that could do all these things from the customer perspective. We had focused on the technology challenges, business constraints, sales and financial projections, and marketing opportunities.
What to focus on
When we wrote a Kindle press release and started working backwards, everything changed. We focused instead on what would be great for customers. An excellent screen for a great reading experience. An ordering process that would make buying and downloading books easy. A huge selection of titles. Low prices.
How long?
Over time, we refined and normalized the specifications for the PR/FAQ. The press release (PR) portion is a few paragraphs, always less than one page. The frequently asked questions (FAQ) should be five pages or less.
Key elements of the press release:
Internal and external FAQs
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.
Feasibility
Above all, keep in mind that the PR/FAQ is a living document. Once it is approved by the leadership team, it will almost certainly still be edited and changed (a process that should be directed by or reviewed with the leadership team).
Can you outsource product development?
You can’t outsource a customized, integrated, end-to-end experience. Furthermore, outsourcing in this context offers a classic example of short-term decisions with devastating long-term implications. Practically every day, Amazon could tweak its offering to make things a little better. And so practically every day, the distance between itself and its competitors widened. Outsourcing turned out to be the more expensive path.
Focus on the doable vs uncontrollable like revenue or stock price
Our emphasis is on what we call controllable input metrics, rather than output metrics. Controllable input metrics (e.g., reducing internal costs so you can affordably lower product prices, adding new items for sale on the website, or reducing standard delivery time) measure the set of activities that, if done well, will yield the desired results, or output metrics (such as monthly revenue and stock price).
Input metrics
Amazon takes this philosophy to heart, focusing most of its effort on leading indicators (we call these “controllable input metrics”) rather than lagging indicators (“output metrics”). Input metrics track things like selection, price, or convenience—factors that Amazon can control
Output metrics
Output metrics—things like orders, revenue, and profit—are important, but they generally can’t be directly manipulated in a sustainable manner over the long term. Input metrics measure things that, done right, bring about the desired results in your output metrics.
Flywheel
Amazon’s virtuous cycle, also called the “Amazon flywheel.” This sketch, inspired by the flywheel concept in Jim Collins’s book Good to Great, is a model of how a set of controllable input metrics drives a single key output metric—in this case, growth.
Trial and error with what kind of input metrics to use.
You’ll notice a pattern of trial and error with metrics in the points above, and this is an essential part of the process. The key is to persistently test and debate as you go.
Failure is part and parcel of creating new products
Jeff also wrote in that same shareholder letter, “I believe we are the best place in the world to fail (we have plenty of practice!), and failure and invention are inseparable twins. To invent you have to experiment, and if you know in advance that it’s going to work, it’s not an experiment. Most large organizations embrace the idea of invention, but are not willing to suffer the string of failed experiments necessary to get there.”
Underpromise overdeliver with a surprise
Amazon should always underpromise and overdeliver, to ensure that customer expectations were exceeded. One example of this principle was that the website clearly described standard shipping as U.S. Postal Service First-Class Mail. In actuality, all these shipments were sent by Priority Mail—a far more expensive option that guaranteed delivery within two to three business days anywhere in the United States. This was called out as a complimentary upgrade in the shipment-confirmation email.
Everyone is involved in Customer Service (CS)
Every two years the corporate employee is required to become a customer service agent for a few days. The employee gets some basic refresher training from a CS agent, listens in on calls, watches email/chat interactions, and then handles some customer contacts directly.
Using Andon cord for a CS agent
One technique they used in their automobile assembly line was the Andon Cord. The car-in-progress moves along the line, and each employee adds a part or performs a task. When any worker notices a quality problem, they are authorized to pull a cord that stops the entire assembly line.
Andon cord for the website
Jeff blurted out, “We need an Andon Cord for customer service.” There was no assembly line to halt, but the CS agent would be given the authority to click on what we called “the big red button” on their control screen. Once that button was clicked, two things happened: the “Add to Cart” and “1-Click” buttons would disappear from the product page so no customers could buy that product,
Good intentions don’t work
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.
FAQs that we have found useful: