Are Amazon’s Leadership Principles Wrong?
Do you follow their leadership principles to the letter?
In the IT industry Amazon is so much more than just one of the biggest e-commerce sites out there. In fact, they’re so big and grew so much, that they were forced to make a choice: either push technology forward and own it or rely on others to solve their multitude of needs.
Lucky for us, they went with the first option, and turned into a giant. Amazon became one of the biggest tech companies in America (and even the world), and because of it, working for Amazon is something many developers wish they could do.
One piece of public information they have about the “working for Amazon” experience, is their Leadership principles. In other words, they’re quite open about how they consider their leaders should act and think. So here I wanted to go over those 14 principles, and openly discuss them with you.
Disclaimer: I am not, nor have I ever been an Amazon employee, so this is just my opinion, based on my 18 years of experience of what these principles mean for a leader. You might think otherwise, and I invite you to leave a comment if you disagree, open discussions are a great way to grow as professionals.
Customer Obsession
According to Amazon, leaders need to focus on customers and then work their way backward.
I completely agree with this one. In fact, this should be the norm for everyone working on a product.
Any company that builds products or sells services needs to consider the customer first. What needs are they trying to solve for them? What are their pain points? And work towards solving those problems.
Going the other way and assuming you know what’s best for your customer can bring a lot of internal bias into the final solution. That bias will affect the final deliverable and you’ll end up with a product nobody wants.
Taking a top-down approach — that means listening to your customer’s problems— can be hard. Some customers don’t know how to explain what they want, and others don’t even know what they want. So you need to focus on the problems they’re having, not their needs. Your job is to provide the solution that best fits your customer’s problems. Not to create the solution they think they need. That’s also a case of bias influencing the final product, just not yours.
Ownership
Leaders own their work. They always keep the company’s interest in mind and they never say “that’s not my job”.
That’s a loaded sentence.
As a leader, you definitely need to own your work. This means being responsible for the project (or projects) you might be working on. It also means owning the team, being responsible for them and making sure they’re working under the best possible conditions.
You’re responsible when things don’t work out. If the team is not performing, it’s not your team’s fault, you should’ve seen it coming and acted accordingly. In fact, some would say you should’ve taken action so that whatever went wrong, never happened.
If problems were caused by an external condition, it’s still your fault. Did you have a plan B in case this happened? Why not? How crazy and unlikely was this external event? You should’ve accounted for it before it happened.
I mean, don’t get me wrong, when things go right, you’re there to get part of the credit as well. Of course, here is where you need to distribute credit where credit is due, that’s also part of being an owner.
Invent and Simplify
This one clearly reflects what I mentioned during the opening paragraphs.
Amazon had to push technology forward, and in turn, it asks all its leaders to do the same. Leaders should expect their teams to invent, to come up with innovative solutions to common problems.
This is a great place to be, knowing you’re not restricted by the company’s tooling choice or by your client’s requirements. Having this level of freedom is like a double-sided blade. You and your team definitely have the ability to come up with new ways of working, and that is always fun. But at the same time, working with new technology (or even creating it yourself) can cause a lot of problems until you manage to get it to a stable version.
Not being limited by the current state of technology should be a rule for every leader out there. Sadly that’s not always the case, so whenever you find yourself in this situation, make sure you take advantage of it.
Are Right, A Lot
Put like this, I just have to disagree.
Granted, if you read their explanation, they also say you as a leader should be questioning your beliefs all the time. And then I agree.
You as a leader should be completely open to being wrong. Being corrected by your team, or by someone else only means you’re learning, and that is something you should excel at. Understanding the project, the business case of your client, or any other knowledge about the project really, is a must-do for any leader.
You.need.to.know.it.all. (or as close as you can get)
And I think this is what they mean by “are right, a lot”. If you’re constantly open to being wrong, that means you’re constantly open to learning which in turn would cause you to be right, a lot (it’s just that they omit the fact that you’ll be wrong a lot more than right).
Learn and Be Curious
I think this one is covered with the previous one. They just split it into two.
Being right a lot is just a by-product of constantly learning and being curious.
Hire and Develop the Best
You want the best people on your team, that’s a given.
But having the best on your team also means helping them develop their skills. The potential to be a great developer is inside everyone. It’s not about hoping to hire the best Sr. devs, but instead, seeing the potential and interest in growth and help them do just that.
As a leader, you’re not only “in charge” of the project, you’re also the one responsible for:
- Giving your team feedback. They need to understand if they’re doing everything right, if they’re meeting your expectations. And even if they aren’t, giving them constructive feedback can help them get back on track.
- Helping them grow. Feedback is just one part of professional growth. You also need to help them understand what’s ahead on their career path and how they can achieve it. Giving them tasks to develop the skills they’ll need in the next step of their career is a great way of doing that.
- Making sure they feel safe. People do their best work when they don’t feel threatened, or pressed into a way of thinking or working. Having the proverbial Damocles’ sword hanging over you when you work is not great. Your job as a leader is to also shelter them from problems, obligations and conflicts that don’t really need to affect them, you’re the sponge for all of that negativity. A terrible leader sees the conflict coming and simply redirects it to the team, for them to deal with it.
Having a team of “rockstars” is what we all want, but remember: it doesn’t happen overnight and you need to put a lot of work into it to get it.
Insist on the Highest Standards
Yes, leaders need to aim for the stars with their requirements of their team, but they also need to have realistic expectations.
You have to remember you’re dealing with people, something we sometimes tend to forget — I’m to blame for that as well.
Aiming for the stars means asking your team for excellence, request that they also comply with the highest standards and that they follow all the rules. But like I said, they’re not machines, and thus your expectations should reflect that.
Expect them to make mistakes, to forget about something, and to sometimes let you down. It has to happen, probabilistically speaking it will, so expecting it not to is as valid and useful as covering the sun with your finger and pretending it’s not there anymore.
The key is not to let your team fail because they’re humans and move on. Instead, let them fail and make sure you put some process, mechanism or automation in place to ensure it doesn’t happen again. If you’re having a teammate that tends to be late for the daily stand-up, maybe it’s a good idea to move the time to a more convenient one for the entire team. If you’re having someone forgetting to run the unit tests before pushing their changes, it might be a good idea to set up a CI/CD automation, you get the point.
It’s better to find a solution around the problem, than trying to correct the problem. People have always and will always be unreliable by nature — let’s face it, life can get in the way, we should plan around it, not against it.
Think Big
How can you scale your solution? Will your algorithm be able to cope with the expected volumetry for next year? How about in 5 years? Will this solution be applied to other projects? What if we turn it into a library and share it with other teams?
Thinking big can mean a lot of things. It can be about looking at the big picture, constantly keeping in your head where the product is going and where it needs to go next.
Or it might be about looking out and seeing what everyone else is doing. Getting inspiration from others, or even learning about new technologies and techniques to utilize in your project and with your team; are also aspects of your tasks as a leader. So yes, thinking big is a must for leaders.
Bias for Action
Absolutely agree with this one.
Researching is great when you have the time for it. Learning about a new piece of technology is fantastic if you’re going to be using it anytime soon.
The best way to learn is by putting into practice what you read about.
As a leader, you can’t do anything with theory. Don’t get me wrong, research is required to solve some problems, but pushing to have early prototypes during the research stage can help to quickly prove or disproof the validity of your theoretical solution.
What I’m trying to say, and what I think Amazon is aiming for here, is that leaders should have a “build early to prove early” type of mentality. In the context of a project, it makes no sense to spend 3 months researching a topic and then 2 more weeks to understand you can’t use it to solve the problem you’re having. Especially not if you could’ve created a quick PoC on week 3 and arrive at the same conclusion.
As a leader you should be biased towards building, solving problems not always requires you to have full domain of the solution — the missing knowledge can come over time.
Frugality
I’m a bit on the edge with this one.
I come from a corporate culture where everyone has their place. Meaning, you have developers, manual testers, automated testers, business analysts, product managers, and the list goes on and on. And the best part? Everyone has their place.
Amazon on the other hand, likes to think constraints help grow innovation. There is no need for extra roles, when you can wear multiple hats and solve the problem. And yes, I agree that sometimes that can cause innovative solutions and at the same time, obviously, it’ll help keep costs low.
However, I’ve seen countless companies trying the same approach and failing. Thinking developers can fulfill the role of a tester, or that a tech lead can be a great product owner. I mean, some of them can, and some of them do, but lots of others fail because that’s not what they signed up for — and that’s not what they want to do either.
So no, I don’t agree with this one, in my experience it doesn’t work, and if you expect to make it work, I think you’ll have to turn a lot of great people down, simply because they can’t comply with this requirement.
Earn Trust
You can’t be a leader if the people you lead won’t put their trust in you, it’s that simple.
So yes as a leader, trust is something that you need to work on building.
Constantly.
How can you do that? I guess if we go deep enough, everyone puts their trust in someone based on different, subjective reasons. However, I think a good rule of thumbs would be:
- Be honest. Always. It can be very hard for people to trust you if they know you’re lying to them. And lies never live for too long, so it’s safer to be honest, even if it hurts you.
- Be up-front. When you have to say something, say it, don’t beat around the bush, get to the point. People tend to trust someone who’s a clear communicator, someone they always understand.
- Your word is everything. If you say you’re going to do it, then you’ll do it, no matter what. If you commit to your word, then people will trust you, implicitly. They’ll know that your word is the law, at least to you. And they’ll also know that if you can’t commit to saying “it’ll be done by Friday”, is because it really can’t be done by Friday.
A leader who follows these 3 principles can earn anybody’s trust. Mind you, I didn’t say it would be an easy task, but it’s a very solid start.
Dive Deep
Technical leaders should be able to go deep into any task and help wherever possible.
Notice how I phrased that, I didn’t say they should be able to take anybody’s job, or code any part of the project that requires it. Honestly, Amazon’s description on this one leaves the door open, and to me, that’s not good.
A great tech lead should be someone great at the technical level, but at the same time, someone who’s been focusing more recently on honing their leadership skills. And let’s be honest, you can’t do both, not for long at least. You can’t be a great coder and a great leader, you need a life as well. So no, I don’t think a leader should be able to, if required, take the place of any teammate.
However, I do agree that a leader should have the ability to be looking at the 5-year roadmap one second, and jump to do a quick code review of a particular commit on the next one. Only to find themselves discussing alternative implementations to a sprint task one hour later.
Context switch mixed with great technical prowess are definitely must-haves for great leaders. That part I can agree on.
However, the ability to code like any developer on the team should not be a requirement for leaders, we’ll have to agree to disagree on that one.
Have Backbone; Disagree and Commit
Don’t be afraid to speak up.
That should be lesson number one on leadership school. Own your words, that should be the second one.
Translation: if you don’t agree with me, say so, but be mindful, whatever you say can and will be used against you in the next promotion meeting.
As a leader, you can’t be afraid to speak your mind, mainly because if you don’t, you’re letting others decide what you have to do, and what your team will have to do. Then what’s the point of you? Don’t get me wrong, this doesn’t mean “complain to everyone and say no to everything”, it just means, if you don’t agree with something, say it. The corollary would be: “and be ready to explain why”.
Which is the second part of this principle: “commit”.
Once you decide on a direction, once you go against someone else’s argument and make your own, then you have to commit to it. Be ready to do it, and make sure that when you speak your mind, you’re sure of what you’re trying to say and why. If you aren’t, if you can’t back-up your claims, then you’ll lose any ground you might’ve gained by speaking up, in fact, you’ll probably lose more than what you gained originally.
I’ve been there, I made some decisions based on poorly researched solutions, and when asked a simple question: “why did you do that?”, I was just left speechless.
Be ready to answer the three basic questions: “why”, “what” and “how”, and if you can, add an answer (even a tentatively one) for “how long”.
Deliver Results
As a leader, you’re normally asked to deliver something functional, a half-ready feature that can’t be used is just as useful as half a chapter of a novel. You won’t be able to get an idea of what you’re reading or how the story started.
Leaders should focus on delivering results. Part of that process also involves handling expectations:
- What is a valid result in your context?
- When can those results be expected?
- Who will be able to use these results?
If you don’t handle the expectations, everyone will create their own, and trust me, they’ll all be different. That’s not a place you want to be in, because you won’t be able to meet everyone’s at the same time.
As the person responsible for the delivery, you need to take charge and control expectations. Make sure you explain to everyone what they’ll get, when they’ll get it and how it will look like. If you do that, you’ll be able to keep everyone happy, or at least know when someone won’t be pleased with the result. But that’s still a major advantage of finding out after the actual delivery. That way you can be prepared for their reaction and have an answer ready for it.
Deliver results, that’s key. But make sure you’re part of those defining what a “result” is.
What do you think? Do you think these principles are too demanding of a leader? Or do they feel just right to you?
I think most of them make sense. At least in my experience I’ve come to see that these make for great leaders. Not all of them, mind you, some of them are a bit too extreme or at least, too loosely defined so that they can be misinterpreted.
I’d love to know what others in the IT industry think about them and if you’d feel comfortable working under them, so leave a comment below and let’s chat!