Amazon is one of the biggest companies in the world. Their core products of them are their marketplace and AWS, a cloud computing platform used by the biggest companies in the world. AWS is also the product that generates the highest profit margins for Amazon.

As a software engineer at Amazon, you are challenged every day. It is expected that you deliver results and apply the leadership principles in every day's work. Even when you are not working at Amazon, you can apply these principles to your job. Share them with your colleagues to create a more collaborative and productive environment. So let us explore some tips on how you can apply the leadership principles.

The 16 leadership principles

The principles at Amazon are the DNA of how Amazon works. The 16 principles make sure that everyday life at Amazon is going smoothly. A simple example is discussions on how to solve a problem. A team gets consists of many people and different experiences. Of course, disagreements will occur at some point. To solve these arguments employees at Amazon will reference the leadership principles during a discussion to solve the arguments. Foremost some should state that discussions in technology companies like Amazon are always looking for actions. Discussions can evolve but should reflect in tasks that can be executed to discover the topic more like gathering data or solving the problem. This can be based on the leadership "Bias for Action" for example.

The current leadership principles consist of these 16 right now:

• Customer Obsession
• Ownership
• Invent and Simplify
• Are Right, A Lot
• Learn and Be Curious
• Hire and Develop the Best
• Insist on the Highest Standards
• Think Big
• Bias for Action
• Frugality
• Earn Trust
• Dive Deep
• Have Backbone
• Disagree and Commit
• Deliver Results
• Strive to be Earth's Best Employer
• Success and Scale Bring Broad Responsibility

You can find an older version of this list also on our career ladder explorer. The list of principles included 14 principles in the past years. But since then Amazon added two more principles "Strive to be Earth's Best Employer" and "Success and Scale Bring Broad Responsibility". The list can change from time to time, but the most updated list can be found on Amazon’s site.

To understand how the leadership principles can be used for software engineers, not just at Amazon, let us have a look at the next chapters. We will explain what software developers spend most of their time on and how leadership principles can be applied to the different work.

To understand how the leadership principles can be used for software engineers, not just at Amazon, let us have a look at the next chapters. We will explain what software developers spend most of their time on and how leadership principles can be applied to the different work.

What do Software Engineers spend their time on

Software Engineering is mostly understood as programming. Writing code to fulfill business requirements. As software engineers, we do a lot of other tasks as well like the following

Meetings, management, and operations

• Product Decision Discussions
• Technical Decision Discussions
• Writing Documentation
• Organizing technical work
• Planning technical projects
• Work on reporting metrics, building dashboards
• Discovery work to come up with new feature proposals
• Interviewing

Code maintenance

• Fixing old TODO comments
• Making sure the system is reliable
• Code Reviews

Testing

• Tests as code
• Manual tests
• User Tests

Security

• Testing for security problems

Writing Code

• Creating new features
• Fixing bugs

So we have a wide range of topics that a Software Engineer needs to deal with. Some topics depend on what team or company you will work for. But in general, these are the duties of software engineers. Do you miss anything? Happy to add them. Feel free to email getworkrecognized@gmail.com. So how do we apply the leadership principles to the different activities?

How to apply the leadership principles during the day

As we have seen in the last chapter, software engineers deal with a lot of duties during their job. Let us look at some examples and use cases for Amazon’s Leadership Principles.

Creating new features or Fixing bugs

This is hands-down coding most of the time. During coding, Software Engineers can apply multiple leadership principles. Let us look at some of them.

Invent and Simplify

Coding is most often consists of two activities: Changing existing code or adding new code. Both ways of working will contribute value and opportunities to invent new coding patterns or simplify the existing code. You could add some new coding pattern that makes the code easier to extend in the future. That is most of the time the main reason for this leadership principle to be applied.

Insist on the Highest Standards

When creating new features or working on refactoring code you should make yourself accountable for the highest standards of code. After all, code is most of the time read, rather than writing. So make sure to put you into the perspective of a new hire and ask yourself if the code is understandable for them.

Deliver Results

Making changes to the code is difficult. Try to aim for a specific amount of Pull Requests within a month or so. When creating Pull Requests make sure to do incremental changes. It is ok if a Pull Request is not complete, but smaller and easier to review. Split up your Pull Requests so you deliver results more incrementally.

Product and Technical Decision Discussions

A big part of the life of a software engineer is product and technical decision discussions. Normally they consist of you, the team, the engineering manager, and the product owner. The product owner is optional when it comes to technical decisions. But in general, these discussions come up most often and require actions that will solve the problem. Of course, the decision process can be rigorous, but Amazon tries to keep the discussions short based on leadership principles. Let us look into how.

Are Right, A Lot & Customer Obsession

As a software engineer, you will have a headstart in discussions with two simple things. Use the product yourself and gather data before the discussions are happening. Gathering data will result in backing your arguments and that you are right about the outcome.

If you do not have the data, then try to make it an action out of the discussion and reschedule the discussion. You will show ownership of the issue and customer obsession to solve the customer’s issue.

Think Big & Frugality

When thinking about new features or technical decisions, always ask yourself: How will this work in 3-5 years? Ask yourself and make a plan and discuss with the team what they think. It is important to get feedback but also write down what you think so it is manifested somewhere. Write a product proposal document with a 5-year plan. It will help everyone.

Nevertheless, it is important to move fast. And moving fast can be achieved with frugality. Not developing the whole feature or 5-year plan but doing a short-term solution. Leaving the long-term solution for later.

Disagree and commit

This is probably the most controversial leadership principle when it comes to discussions. Humans are opinionated. Especially software engineers. I was part of discussions where discussions drifted away far too much because of specific technical or product decisions. Sometimes it is better to just disagree and say "whatever" and follow the decisions of your peers. After all, we can track the results and see if they are satisfying or even A/B test your opinion to see if it would work better. Everyone is open to feedback after a decision, and you should be too.

Writing external documentation

An underestimated skill as a software engineer is to write documentation. Writing is difficult. Writing clear documentation is even more difficult. There is good guidance out there to write good documentation like the guide by divio: "The documentation system". But what is even more important than the structure are some other things that are related to the leadership principles.

Customer Obsession & Dive Deep

Good documentation can be written easily. But how do you know what the customer needs? You have to do the research. Watch the customer using the product you are working on. This is difficult from time to time. Especially when working on an internal product, but even then it is possible to just listen to a customer. See their struggles and get feedback on what could be improved. Any pain points. Document them and write proper documentation about them. Obsess with the customer, try to make sure every customer will understand how your product should or can be used.

Ownership

Software engineers hate to write documentation. Everyone does, maybe except technical writers. In any way, as software engineers, we should own documentation and make sure it is always in an exceptional state. And I do not only mean the API documentation, but also the general documentation on how to use the product. Make sure you gather feedback and iterate on your documentation to make it more useful.

Earn Trust

A big part of writing documentation is actually to gain the trust of the customer. With proper documentation that includes Tutorials, How-to-Guides, Explanation, and References you make sure the customer is earning trust in your system, understand edge cases, and is, in general, more likely to integrate the product.

So what did we learn from this? Make sure to write documentation in your daily life as a software engineer. Spend some time every week to write something, either for your team or externally, so your systems are more understandable.

Planning projects

The higher you are on the software engineer career ladder, the more important it gets to lead projects that affect your team and company directly. Leadership is a general skill but is composed of the leadership principles at Amazon. By following some of the leadership principles you will be a great leader in making sure smaller projects will get delivered.

Ownership

By planning and executing projects you are showing ownership already. Make sure everything will work out as expected and collaborate with your contributors.

Bias for Action

When owning a project, you are required to take decisions. This can be challenging. But take action instead of waiting and discussing. As long as you track the outcome of your actions and make sure it performs well, you will be fine. Everyone can fail with the actions, the important part is to realize it was a mistake and fix those decisions.

Frugality & Deliver Results

A core principle when planning projects is to plan them minimalistic. It is expected that you deliver a project. A smaller project is delivered quicker by nature. Keep the scope small so you and your collaborators, if existing, can deliver quick results. It is a lot better to roll out a project and gather data on how it performs rather than never releasing it.

Success and Scale Bring Broad Responsibility

You have finally finished the project. Now it becomes time to measure your success. The metrics should have been defined at the beginning of the project.

Summary

We have just listed some examples of how the leadership principles can be applied to your day-to-day work. If you want to get to know how to apply them in detail, have a read on how customer obsession can be applied for example. Try to apply the leadership principles. Reference them in some of these situations and make sure you stay productive. But the principles have an even more important meaning at Amazon.

Leadership Principles in Performance Reviews

At Amazon, Performance reviews happen yearly. A big part of the reviews is the self-review and the peer feedback you or your manager will receive. They are all based on leadership principles. Peers will have available a matrix for each leadership principle and the level. They will then choose the strengths and weaknesses of your past work performance.

This process is really difficult though. Think about writing a self-review of your past year’s achievements and base it on the leadership principles listed in this article. You will struggle, I will struggle, we all will struggle. Our human brains are limited. You simply can’t remember all the things we did. And that is where a brag document becomes important. I am keeping a journal in getworkrecognized of all achievements I have reached. I can tag the achievements with a tag and get a summarized version of what I have achieved and relate it to the leadership principles. Quite useful for the self-review. But where it gets even more important is when you ask for peer feedback. Your colleagues might not even remember what they did themself, and will even more likely forget what you have done. Send them a brag document with all your achievements listed in a compact form and you will get better feedback for sure. If you are unsure what a brag document could look like, have a look at our 3 brag document templates.

Once you get rated on your leadership principles the manager will decide if you get to put up for promotion or not. In most cases, they are required to write a promotion case, where they can reference the brag document again, which will be great for you because less work is required to get you the well-deserved promotion.

If you are not working at Amazon you can still make sure to follow the advice with the brag document. In any case, it will help you with the promotion in your current company. People like writing documents that underline a need for something. Think of the product/feature proposals I mentioned before. These should be manifested in a document as well, so you can reference them in the future and make sure the right decision will be taken - which should be your promotion.

So, this is how you can apply the leadership principles of Amazon at your current job, even if you do not work for Amazon. Amazing, is not it? It will make you a more productive and high-quality developer with an eye for the right thing.