It’s so famous that probably you already have heard of them: it’s Amazon’s leadership principles.
In this series, I will explain in-depth every single one of all the 14 leadership principles — what they are, how they are defined, how they are used in everyday work, how you know you are doing it right or wrong. At the end of this series, I will also explain the STAR interview technique and which ones I think are the more important principles.
If you want to land a job in Amazon and you have heard that learning these leadership principles is extremely important to your interview's success, this is the right series of articles to follow.
Or, maybe you just are interested in how Amazon does things and want to learn from this global giant, in which case, this is also the right series of articles to follow.
Or you are just curious or bored — I guarantee you, you will find this series interesting.
Let’s start with some personal rant as a preface to this series, which is —
I am old enough to have worked in quite a few different types of companies, be it global software giants or local unknown start-ups. I’m also lucky enough to have worked in quite a few different cultures: Chinese, Eastern European, German, Portugal, British, American, etc.
No matter where the company headquarter is, and no matter how big the company is, when it comes to company culture, there are generally two types of companies:
One type of company has a company culture but is often overlooked. It’s most likely written down in the employee handbook and probably even written on the office wall as well. But that is it; most of the time, nobody thinks about it. Having that culture doesn’t make a difference.
The culture itself is normally composed of a few sentences, which seems to be gold, but once you think about it, you will find out that they are so true that they become nonsense. It’s like putting “you have to drink water in order to live” in the employee’s handbook as a culture: it’s a bit unnecessary.
The other type of company doesn’t have a culture.
Amazon kind of belongs to the first type, but it’s different.
It’s similar to the first type in the sense that all the culture seems to be “golden nonsense” — like “customer obsession” — which company shouldn’t be obsessed by their customers?
But at the same time, it’s different. It’s different in the sense that those principles, unlike in most other companies, are not overlooked. Instead, they are practiced in every day’s work.
That’s what makes those principles valuable to Amazon, and potentially, to you too.
With that said, now let’s start with the first leadership principle —
Amazon’s definition goes as follows: 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.
You might be confused because why it says “leaders?” Maybe you are just a developer, not a manager. Does this apply to you?
The short answer is yes. In Amazon, they want you to think that everybody is the owner of Amazon, and everyone is a leader in their project, and everybody is responsible. When you are developing an internal service, the users of the service are your customers, and you lead the project. When you are doing consulting work for internal teams or external customers, those teams are your customers, and you should lead the project.
Well, apparently, not everybody can be a leader in the project, but it doesn’t hurt to think from a leader’s standpoint, take ownership, and deliver.
The next thing to explain is, working backwards.
Amazon is famous for “working backwards”; so famous that it wrote a book on it. The good news is, you just saved yourself 20 bucks because if you are reading this article, you don’t have to read the book anymore.
Typically, you have an idea, you collect information around that idea, you build something based on that information, and this thing you built is enjoyed by your customers and changed their life. Or, it isn’t, and it gets abandoned. Think how many start-ups failed because they built a perfect solution to a problem that doesn’t even exist.
Working backwards means literally reversing this process: you think what your target customers want, how something can significantly improve their experience, you know what you are going to build, you see what information you need to collect to build this thing, only then you arrive at the starting state of the work cycle which is the idea and the design.
Keep Customer Trust
Trust is something easy to lose but very hard to gain. Since there is another specific leadership principle on “earning trust,” we will cover this in later articles of this series.
One of the fastest ways of losing trust worth pointing out now is not able to deliver. You can be obsessed with the customers all you want and work backwards as hard as you can; if, in the end, the project isn’t delivered, you quickly lose trust.
Competitors / Customers
It’s not a secret that Google Cloud, Microsoft Azure, even Alicloud, or something you have never heard of is the competitors of AWS.
On the one hand, AWS is definitely paying attention to those competitors. You should know what others are doing to stay competitive in the business. On the other hand, your goal isn’t to defeat those competitors but to keep your customers happy. Theoretically, if you always keep your customers happy, you will defeat competitors, but the thing is, to pay more attention to the customers instead of competitors.
How to Be Obsessed with Your Customers
To apply this principle in your daily work, there are a few things you can do:
First of all, you should be able to identify what your customers need. As aforementioned, instead of building a perfect solution to a problem that doesn’t exist, figuring out what real problems your customers are having is the key. One way to achieve this is by collecting feedback from your customers. Listen to your customers. Dive deep and learn what problems they have.
Then you can use what you collected as the input of your function and start working backwards. Listen to the customer, hear what they want and what bothers them, take actions toward that, work hard for that. If things change (well, in the software world, things change fast) and the project you are working on doesn’t improve the customers’ experience anymore, drop it. You don’t want to create something technically perfect but useless in the real world.
If you are building things because you want to build them or because other companies are building that and it’s popular, you probably are not obsessed with customers. Competitors are important, but you should always start with your customers.
If you don’t or can’t collect feedback from your customers, you are not doing it right. If you have some feedback, but you are making decisions without utilizing them, without considering the impact on the customers, that’s worse. If you can’t even figure out who is your target customers so you can’t know what you should build, that’s the worst.
There are a few key aspects of this leadership principles:
feedback — this is where you start to work backwards
customer experience — think from the customers’ standpoint and invent a project to solve their problems, rather than building something generic in the business
If I were an interviewer and wanted to see if you are obsessed with your customers, I could focus on these three key aspects.
On the feedback part, I could ask: tell me about a project you worked on and how you collected feedback from the customers. What did your customers say? Did you, and if yes, how did you use the feedback to take action and improve the project?
On the customer experience part, you could be asked: have you worked on a project which wasn’t something the customers wanted, but something you discovered that could improve the customer’s experience? How did you figure out that they might need this?
While I do have a perfect project for this question (where I felt the pain and introduced something the team didn’t know; if you haven't read this article yet, now is the time), I know it could be a tough question because the chances are, you as a developer have never worked in such an important position where you can decide what to build. I know this sounds cruel, but it might be true because I once was there too.
Then maybe I could focus on the “deliver results” part, and ask you how you have improved customer experience in the past, with questions like: have you overachieved some goal, gone the extra mile to make it even better?
Note that these are only imagined questions invented by myself; they are not real, not what I was asked when I was interviewing with Amazon, and not what I would ask when I act as an interviewer inside Amazon.
Nevertheless, you can use them as a guideline to prepare for your interviews.
Think about what projects you have done before and think of some examples of collecting feedback, working backwards, improving customer experience, and delivering results.
Sr. DevOps Consultant | Global Financial Services | Professional Services at AWS