The 14 Amazon Leadership Principles explained

As for every article that I post, my thoughts and opinions are my own and I am in no way representing Amazon.

Amazon has 14 “values”, called the Leadership Principles, that are used every day and drive mechanism on how to solve problems and how to approach new projects. Some are easy to understand, but a big part is not that straightforward and could use some explanations and examples. In this article, I will explain all those principles, and what they represent.

All leadership principles are important for every team and everyone working at Amazon, but I feel like some are particularly relevant for software engineer and I will be highlighting them throughout the article (hopefully they should come as no surprise).

Customer Obsession

Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.

This is probably the most important leadership principle, and the one that I keep in mind the most, as it drives decisions related to most of the other principles too.

Customer Obsession is relatively straightforward to understand, but to talk about it I will mention a “methodology” that is central in Amazon: Working Backwards. What this means is that we start from the customer’s needs, and work backward from there to design a solution that will answer to those needs. In this setting, cutting on some profits is not going to be unreasonable if it means a better user experience for the customer.

Note that it is important to understand who is your customer. Someone working on the retail website will not have the same customer as someone working on the Alexa team, or a developer producing software for internal analytics teams. That said, the end customer is always the individual that will use the public services of Amazon, and this is always kept in mind.

Ownership

Leaders are owners. They think long term and don’t sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. Leaders never say “that’s not my job.”

I think that Ownership is especially important as a leadership principle for Software Engineers. We write code that might use libraries or services developed by other teams, or write some common code used by our teammates, and it is necessary to make the effort of never saying “it’s not my job”.

A personal example of Ownership was that I was just checking out an internal tool that I ended up having no use for, but I noticed a bug while I was trying it. I could have just walked away from the tool and thought that someone else would take care of it at some point, but instead I tracked down which team owned the tool and opened a bug report for them.

Invent and Simplify

Leaders expect and require innovation and invention from their teams and always find ways to simplify. They are externally aware, look for new ideas from everywhere, and are not limited by “not invented here.” As we do new things, we accept that we may be misunderstood for long periods of time.

People are sometimes stuck in the routine, or in an inefficient process. You might join a new company, and see something being done very poorly, only to be answered “Well that’s how we’ve always been doing it” when you ask why this is done the way it is. Invent and Simplify promotes the opposite behavior. If you see a process that is inefficient and that you can improve, improve it.

Again, I have a personal example. My team was receiving bug reports from our customers, and it we were wasting time on each ticket because we usually had to ask on which page they encountered the issue. We could have kept going this way, but instead I spent an evening and developed a new system which automatically adds the page on which the error happened to the customers’ tickets, saving both the engineers and the developers a lot of time.

Are Right, A Lot

Leaders are right a lot. They have strong judgment and good instincts. They seek diverse perspectives and work to disconfirm their beliefs.

Alright, this one is a bit more complex to understand, and to explain. It doesn’t mean that you are expected to be right all the time. Essentially, it is to be expected that you will sometimes be wrong, but you need to be able to look at yourself, and realize that you were wrong. Amazon is a data-driven company, and when you have a belief, you should back this belief with data.

Another aspect that is captured by this leadership principle, is that everyone’s opinion is considered, interns and senior engineers. This is a very important value to have if you want to have a cohesive team and make sure everyone is valued. It is much easier to be motivated to contribute when you know that your opinion will be listened to and taken into account.

Learn and Be Curious

Leaders are never done learning and always seek to improve themselves. They are curious about new possibilities and act to explore them.

I talked about it in my article “One day in the life of an Amazon Software Engineer“, even just within my small team, we use a huge amount of different technologies, and we all are accomplishing a wide variety of tasks, going from frontend & backend development, to devops, data engineering, etc.

This means that we always have to keep learning about new infrastructure choices, new frameworks, or even new programming languages. The code that you are working on today might be replaced in 6 months, and you will need to learn and adapt to the new stack to keep performing appropriately and to be able to contribute to the team.

Amazon encourages constant learning, and we are offered a lot of different trainings and conferences, either remote or in conventions (sometimes public ones, like AWS re:Invent).

Hire and Develop the Best

Leaders raise the performance bar with every hire and promotion. They recognize exceptional talent, and willingly move them throughout the organization. Leaders develop leaders and take seriously their role in coaching others. We work on behalf of our people to invent mechanisms for development like Career Choice.

I love doing interviews, which I think are very enriching experiences, and Amazon gives everyone the possibility to participate in the recruitment process by doing interviews for their team. One of the most commonly heard phrases is about “raising the bar”, and it is a big part of the recruitment process, and also after.

All members of a team are responsible for the continual growth of its member, and everyone has the potential to contribute in a meaningful way to the development of their teammates. Even the most junior developers have the opportunity to share their knowledge with the team, and mentoring is highly encouraged. Mentoring can be new hires for interns, or senior developers for new hires, but it can also go the other way, as we all have complementary skills.

Insist on the Highest Standards

Leaders have relentlessly high standards — many people may think these standards are unreasonably high. Leaders are continually raising the bar and drive their teams to deliver high quality products, services, and processes. They ensure that defects do not get sent down the line and that problems are fixed so they stay fixed.

I feel that this leadership principle is extremely important for Software Engineers. We write code that can have tremendous impact on our customers, and we should never cut corners for the sake of delivering “on time”. This leadership principle means that you should have high standards when it comes to the features you are developing, but also which features you choose to develop.

Sometimes what the customer wants and what is best for the customer is not the same, and it is your responsibility (talking about Ownership…) as a technical expert to make sure that you provide the right technical solution, and solve the right problem. This could mean that you will spend more time to develop a more suitable solution, and that the final delivery might be very far from the initial design.

An example that I have is about a project where the customer wanted to present the current state of some data on a calendar view. Instead we designed a solution where we presented a list of problems. They loved the solution, it was way faster to implement, and it turned out that the calendar solution just wouldn’t have scaled.

Of course an example usually fits multiple leadership principles, here it also exemplifies Invent and Simplify for example.

Think Big

Thinking small is a self-fulfilling prophecy. Leaders create and communicate a bold direction that inspires results. They think differently and look around corners for ways to serve customers.

Same-day delivery, Alexa, Amazon Go, and many other projects are examples of Thinking Big. It is hard to really explain what Think Big means, but basically you should always thrive to come up with ambitious solutions to the problems that we face at work.

It is hard to exemplify without mentioning very specific situations, and it is a leadership principle that might be hard to embody at first, but it could be translated by never saying “This is not going to work”.

Again, it is a leadership principle that is very important for software engineers, given that we are the ones proposing technical solutions to business problems.

Bias for Action

Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking. 

Bias for Action is my favorite leadership principle, and it is of utmost importance for software engineers. It is about moving fast and not letting risks add inertia to your work. Jeff Bezos keeps saying “It’s always day 1”, and there’s even one of the Amazon buildings in Seattle which is called “Day 1”. You can read about it in the 2016 Letter to Shareholders, but it basically means that Amazon tries to keep working like a startup, making decisions quickly and moving fast.

One quote that I like and that is heavily tied to this principle is “Ask for forgiveness, not for permission“, and it is a state of mind that is heavily encouraged in Amazon. In simple words, it means that if you see an opportunity, don’t wait and just act on it.

Frugality

Accomplish more with less. Constraints breed resourcefulness, self-sufficiency, and invention. There are no extra points for growing headcount, budget size, or fixed expense.

One of the key selling points of buying on Amazon is that it is cheaper than elsewhere. Of course this means that money should be spent sparingly by the business, and we should aim to lower operational costs. Frugality is just the translation of this need to reduce costs.

I don’t have specific examples in mind that relate to my job, but on a small scale it could be making sure that we have the smallest servers that will run our software, rather than using huge hardware “just to be safe”.

Earn Trust

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.

Earn Trust and Are Right, a Lot, are heavily tied together. I mentioned it already, leaders should try to disconfirm their beliefs, and every suggestion or decision should be backed by data. Engineers of all levels are given a great level of autonomy and responsibility, and it is not unusual that entry level developers will have to design the architecture of some new systems. This is where it will be essential to have your team trust you and your decisions.

You also have to admit your mistakes, it is absolutely key to growing as an engineer (or in any role), and most importantly, you have to learn from them. In Amazon, an individual’s error is a team failure, and we have mechanisms in place to learn from those mistakes.

Dive Deep

Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ. No task is beneath them.

I already had a full paragraph about Dive Deep in my article on the proper way to learn as a beginner, but Diving Deep is also about backing your decisions with data. One of the mechanisms that we have is the “5 whys?” which I mentioned aswell in the other paragraph.

We have used this rule many times while trying to fix the root cause of major bugs. The goal is not to apply a band-aid to a problem, but to Dive Deep, find the reason why it was failing in the first place, and patch that error.

Have Backbone; 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.

We have a lot of debates in Amazon! I talked about designs earlier, but every design comes with a design review, and those always spark a lot of conversation. We all have different opinions, and there are more often than not multiple solutions to a single problem.

Disagreeing is encouraged in Amazon, but once a decision has been taken, even if it’s not the one you were rooting for, you have to fully commit to implementing the solution, as this will be the only way to make it work for the whole team. You present your opinion as an individual, but you take decisions and execute them as a team.

Deliver Results

Leaders focus on the key inputs for their business and deliver them with the right quality and in a timely fashion. Despite setbacks, they rise to the occasion and never settle.

The last one is very straightforward, leaders are expected to Deliver Result. That said, one thing to keep in mind is how you measure the success of your delivery. What are the metrics that you monitor to see that your delivery was successful? Which data is backing up your claim of a successful delivery?

One example I have is that all of a sudden the latency of one of my endpoints increased drastically for no apparent reason. I investigated, and found out the root cause, after which I released a fix. To back the claim that the problem was fixed, I didn’t just look at the page and saw that the loading time was reduced, but I looked at the metrics about the latency that we publish, to make sure it was solved for all the customers using our tool.

---

This concludes this long article, which I hope helped you shed some light on the more obscure leadership principles that are used at Amazon.

I want to insist on the fact that those are way more than just the usual values that we find in other companies like “Teamwork”, “Honesty” or “Passion”. The Leadership Principles are part of our everyday work, we use them to drive all of our decisions and I strongly believe they are the pillars of how Amazon became what it is today. I really think that they bring a lot to the structure of how we work, and I am sure that they could be beneficial to any other company.