Forem: getworkrecognized

6 examples of Bias for action for Software Engineers

Kevin Peters — Thu, 20 Jan 2022 22:14:39 +0000

Bias for action is a principle that appears in many leadership principle lists of companies, like Amazon. Let us explore what it means and how software engineers apply this principle.

What is Bias for action?

In business, time is money. Many judgments and acts can be reversed and do not need in-depth research. Risk-taking is something that is appreciated.

As software engineers, we have to take risks, decisions and need to judge decisions all the time. This depends of course on seniority and your current level, but in any job as a software engineer - even if you do not work at Amazon - you will show this principle.

The principle can also be described as a calculated risk. Not every decision will be the right one but with a bit of data, you can measure the risk of each option for doing a specific task. If the risk is acceptable you should be open to taking any path that leads to completion of the task, ideally with the lowest friction. If it was wrong, then change.

The characteristics making out a person that fits this leadership principle are consisting of different things. For once, we have the doer. When considering "Bias for action" people that are not scared of doing mistakes will show this leadership principle more. They are willing to do certain things without overthinking. They take the risks required which other people might not take. Additionally, they will also have the courage to own the outcome when taking an action. If the action might lead to failure, they are there to fix it, iterate, improve and maybe iterate based on the action. True ownership.

Which companies use Bias for action?

Next to Amazon there is GitHub who is uses a similar principle called "Ship to learn". It is similar to the details of "Bias for Action" by Amazon. So here is a short list with all the companies using this principle:

With a lot more companies adapting leadership principles "Bias for action" will become more important. Companies also get more technical and analyze the impact they have, making sure that you can pivot from your initial decision if it does not work out. So let us check what software engineers can do in detail to show this leadership principle.

Situations for Bias for action

As a software engineer, you might ask yourself initially where you show bias for action. It is really difficult when you think about it but there are a lot of opportunities and day-to-day activities where you show this principle.

During arguments

A situation where it is quite common to use "Bias for action" is in discussions with the team. It could be any discussion on how to implement a specific feature. Or talking about a past decision on what went wrong. Often, participants in the discussion do not focus on the actions they can take from the discussion but because they like to discuss. In these situations, the leadership principle can be applied. Disagreeing and focusing on actually taking an action, even if you do not agree with it necessarily.

Decisioning Process

As mentioned in the last chapter, most decision processes will be decided based upon discussions. In any way, as software engineers, we will also have the ability to make decisions ourselves. Especially because as a software engineer you will most likely have access to the data to make the decisions. If you know in a meeting that a discussion might help to take any action, but to take a really good decision it will take a bit more time to gather data, delay the decision. The action will be to get more data to make sure whatever action you will take, will make the whole process a success for your customer. To the person or organization, you are writing software for. Push for this principle.

Helping people to make decisions

When you think about discussions, you mostly think about yourself and how you interact in the discussion. But it is also important to put yourself into the other participants' perspective. If you understand the other person and make sure their voice, their concerns, and their decisions are well respected, it is the first step to making good decisions. You can help to convince them of your ideas by giving them a little nudge, to rethink approaches. For example, this works well with gathering data on the problem and presenting it to them. It might make them rethink their decision and take action instead of just arguing with the team.

How do you measure Bias for action?

If you read this article you probably want to know what you have done which relates to this principle. But first, let us check how we can measure Bias for action. It is probably one of the leadership principles that is the most difficult to track. But what you can do is create a brag document every week or month and write down the situations when you took a risk rather than waiting out on deciding something. The more detailed timeline you have of the discussion and decision processes the easier it will get for you to summarize where you acted based on this principle.

Another good tip is to keep a brag document with getworkrecognized and keep records of when you showed a bias for action so you can reference it in the future. With getworkrecgonized, you can keep a diary of all your achievements at work.

Examples of how to apply Bias for action

Programmers show bias for action most of the time by default. But pinpointing specific examples in your career is always feeling difficult. In the following section, we list some examples where bias for action can be shown.

Solutions

Coming up with a solution to solve a problem can be applied to many problems. It can be a technical problem but also a team problem, but we will discover them later in this chapter. In general, solutions should be built minimal. When a problem arises try to focus on thinking of an MVP - a minimum viable product. So to say. A better term would be probably a minimum viable solution that fixes the problem.

Feature Discussions

Discussions about product features are probably the most common one for software engineers to be involved in. For example, it could be a simple discussion of which user interface is better and should be chosen for the next feature. A lot of preferences come into play here like personal experience with UI and experiences at your old company how they have done things. Most of the time an A/B test can help with actually choosing the right UI. Instead of arguing which UI is better, focus on actually choosing a metric that will help you to see which is the better UI.

Another example is purely technical feature discussions. For example, like choosing the right database type for your new application or service. For such decisions, the principle "Bias for action" might not be applied because database migrations are difficult to do in the long term. So you should be still open to listening to other people's opinions but decide on the best long-term solution. Be careful of the risks of your decisions. Note them down.

A different situation can occur during sprint planning with your team. Which feature should you focus on? Normally sprints are taking 2 weeks and there is a goal for the sprint to achieve. People hesitate about what to choose normally and what has the highest impact. Gather data on the impact and effort to finish the different projects, which are also called epics in some companies. With that, you can measure the risk of actually delivering a feature within a sprint and measure the outcome.

Team Issues

Most modern and agile teams follow some sort of sprints. What most of the sprints have in common is a retrospective at the end of each cycle of the sprint. During this meeting, the participants discuss the last cycle and what can be done better. But more importantly, they discuss concrete actions that can improve the team's health and performance. The focus should be on actions rather than discussing the issues. Sometimes though, discussing the issue will clear up specific arguments, so feel free to discuss from time to time, but push the participants of the meeting to take action and remind them that sometimes it is ok to disagree if you have any action and can measure the success in future retros. Especially if the issue is not critical to running your current team's processes.

Mentoring

An engineer will have many opportunities to mentor other employees in the company. More junior people need a helping hand from time to time with easy but also difficult problems. More senior people need guidance on how to navigate the product the best, how to contribute, and what are core parts of the code are.

During mentoring it is important that you can tell the other person that you do not know everything and if you get into a situation where you do not have an answer to a question, you can simply answer you do not know. But it is important to also give them the feeling that if they fail with their actions, failures are appreciated because you can learn from them. This is the most important part. Push them for a decision soon and let them reevaluate if it does not work out. An important part though is to encourage them to also gather some data around their issue, and see if what they thought is right, is working out.

Meetings

The principle can be also shown in meetings. As we learned in the discussions chapter before it is important to take action from a meeting. What you can do to push this action-taking and make it quicker is to just research some data regarding the meeting before the actual meeting. Take 30-60 minutes the next time before a meeting and gather data around the issues that will appear. It will help to drive your meeting forward. And even if the meeting does not go in the direction of actions, take an action to gather data around the issue to see if there is any impact. We also wrote another article on how to structure your meetings.

Documentation

Writing documentation comes short most of the time for developers. A problem that many software engineers have is that they can't put themself into another perspective. So the reader of the documentation will suffer. It is good to create some personas for your documentation and then write the documentation.

It's important to roll out this documentation quickly and gather feedback. Most of the time some documentation is better than none. Take action and write that piece of documentation everyone is needing. For internal customers or external customers.

Summary

Bias for action is a weird leadership principle. It is not clear immediately how this principle is actually manifested in your work and especially in interviews at Amazon, it might be weird to answer this question. Find one of the examples above in your work and prepare them for the interview. And feel free to track your work with getworkrecognized. It will help you to figure out your actions towards "Bias for action".

How to Apply Amazon's Leadership Principles as a Software Engineer

Kevin Peters — Wed, 05 Jan 2022 07:39:26 +0000

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.

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.

3 free Brag Document Templates [Google Docs]

Kevin Peters — Tue, 14 Sep 2021 06:53:18 +0000

Brag documents are an effective way to get recognized by your manager and peers for your work. It will help you to get promoted or simply get a salary raise. Getting a template and what to write into that is difficult, that is why we have prepared some templates for you. All of the templates are free and can be accessed via Google Docs.

You might be a startup that is trying to set up their performance evaluation processes to finally create alignment for leveling and ranking within the company, or simply a worker who wants to get a promotion. A brag document can help to convince your manager to get promoted.

How to work with the templates

Open the URL of the template, you can find them in the next chapters
Press on File → Make a copy
Fill the document with your data
Send it to your manager, ideally discuss it in a 1-on-1 meeting and see if you can reach for the promotion

Brag Document Template #1: The general one

Template Link: "Brag Document Template 1: For Everyone"

This brag document is made for every profession. After a short introduction on where you describe yourself in a short profile, you will jump over to defining the goals from past years. If you do not know what goals you had a year ago, feel free to write down what the company’s goals were.

Once those are written down it is time to think about your past year’s performance. What tasks have you done that impacted the key metrics of the company? Most people struggle with this but think back, month by month what you have done.

Then write down what the situation was, without describing what you have done and how the situation was impacted. All that and you will have a good overview of what your performance looked like.

Brag Document Template #2: Software Engineers & More

Template Link: "Brag Document Template 2: Software Engineers & Tech"

This brag document is specially made for Software Engineers but can be used for other professions as well. It is also written based on the popular article "Get your work recognized: write a brag document" by Julia Evans. It will go through your Goals, Projects, how you have collaborated with colleagues and how you progressed the company. Overall it is super focused on software engineers that have clear projects on what they work on and surely this cannot be found in every job that is out there, but if you have some structured way of working towards some KPIs this template might be for you.

The only chapter that does apply to Software Engineers is "Design & documentation". Ideally, you skip this chapter from the template to make it a generic one that works for everyone. But in general, this template is really popular as it was featured on Hackernews with more than 300 upvotes.

Brag Document Template #3: Based on Leadership Principles

Template Link: "Brag Document Template 3: Leadership Principles"

This brag document template is the best if your company works with Leadership Principles, also called operation principles in some companies. You can find a big selection of leadership principles in our free Career Ladders Explorer.

The template is structured quite simply. You have three sections that are like the following:

Good Leadership Principles/Actions
Room to improve based on Leadership Principles
Outlook

The important thing to consider in this template is to overweight the good parts and leave out the bad things. Ideally, you should have started with listing "okish" achievements and getting to the best achievements, then starting with the worst parts where you need to improve and top it off with improvements that are possible for you to reach in the next performance review cycle.

In the final self-evaluation section try to focus on reasons why you should get promoted. Most of the time the main reason should be that you act on the next level already when it comes to leadership principles. And write as well that you want to get promoted now, because of all your achievements and your output.

Other brag docs

Do you have any other brag documents that you want to share? Feel free to shoot us an email at: getworkrecognized@gmail.com. We are happy to have your template listed here as well and we are looking to extend this collection of brag documents soon.

8 examples to show Customer Obsession as a Software Engineer

Kevin Peters — Sat, 21 Aug 2021 15:41:46 +0000

Customer Obsession is manifested in many of the career ladders of the top technology companies. But why is that and how can you, as a Software Engineer, show this principle right now at your current job?

What is Customer Obsession?

Customer obsession is a principle that describes your effort to make your customer happy. It can be applied to almost all positions in a world where you are working on problems that not only you have. This goes from end-customer-facing roles to internal roles where your customer is another employee.

To make your customer happy there are different methods you can apply to make it work. The most important one is to know what your customer wants and for that, you have to be able to put yourself into the customer’s perspective and try out the work you have been doing from that perspective. See where you can improve things and be proactive with your actions to make the customer love your work.

Who is using Customer Obsession as a Leadership Principle?

The biggest technology companies are actively using this principle:

A lot of companies have made this principle a core principle of them, and that has a reason. Within the last 10 to 20 years our software was getting closer and closer to the end customer. Everyone has experience with top-notch experiences provided by big apps like Instagram, Facebook, TikTok, or Uber to name a few. They just work, as expected, and without any problems. Why? Because the customer loves them.

So let us jump into the examples.

Examples you can do to show customer obsession

Practicing customer obsession is difficult on day to day basis as a software engineer. This is because they do not have everyday contact with the customers of the product they create. But there are many indirect touchpoints, you can have. Let us discover them!

Supporting the customer when needed

Ever got asked a question by your support or salesperson in the company about a customer problem? This is a big opportunity to show customer obsession. Try to understand the salesperson or the support person first. Listen. And ask a lot of questions. And also if possible get to the direct words of the customer. Once you have gathered enough information you can answer questions quite easily, but get the whole picture first.

In bigger companies, you are mostly shielded away from direct customer feedback, and your product owner will probably talk to you regarding the "customer’s" problems. Make sure that the data backs this up, and that this is something the customer wanted.

Seek to understand the customer

In the example presented before you could see already that you should be able to understand the customer by listening to third parties like someone in the company. But now let us go one step further. Someone in the company will have calls with customers from time to time. Ask them to join from time to time. Maybe once per month for an hour will work out. But this will be a worthwhile hour, you will learn a lot. And in these sessions, take notes of what the customer wants, how they think, and how you could affect them with your work.

Think ahead, exceed customer’s expectation

Features and bugs are normally driven by the customer. A customer wants something to be done in your company’s product or found a mistake blocking their workflow in one way or another. The special skill to have now is to think more ahead, especially for features. The customer requests a feature, but the problem might be that the customer wants to achieve a lot more than they requested. To solve this, you need to think like the customer and think what are the next steps for this feature. Is there a relation or can it be made easier? For example, if you do frontend development it would be a simple idea to count the clicks till a customer will achieve what they wanted. Is there a way to reduce the clicks for the customer by prefilling fields in a clever way like they have used it last time, or based on other suggestions? Or when it is a backend problem, you can put extra focus on error messages and guide the customer to a solution or what they should have done instead. Most errors are simply describing only the state, good errors will give hints what the customer should do instead.

Put yourself into the customer’s shoes

As we have learned in the last examples you will have to get a feeling of how the customer is seeing your product. This is difficult:

If there is any secret of success, it lies in the ability to get the other person's point of view and see things from that person's angle as well as from your own. - Henry Ford

But no problem, you can learn it. Listen to the customers and use your product. Write down the smallest things that are problematic for you. Wrong colors, wrong behavior, and whatnot. You will get a feeling of what the customer "could" feel. Not all humans, and also not all customers, are equal. Some see one thing as a problem but others look at different problems. Try to understand each perspective. It will be golden for your whole career.

Find Problems within your product

As we mentioned before, finding problems and barriers in your product is worthwhile. From now on simply spend 1 hour with your product every week where you write down annoyances when you are using it. Gather these thoughts and present them to your product owner or create tickets for these problems.

Find data to understand customer satisfaction and loyalty

A problem most companies have with customer obsession is that it is not measured. Most companies just have abstract KPIs like revenue or user numbers. But what impacts the customer obsession is probably two metrics:

Customer Churn
Customer Satisfaction

Both can be measured. Customer churn is easy to measure but customer satisfaction is difficult. For this, you could work together with your product owner to send out surveys to the users of your product every month. If response rates are low, invite them to an "interview". People love being interviewed instead of being just a data point. But work on getting these metrics and make sure the company is using them for product development.

Create documentation for your customer

Earlier we mentioned that customers ask questions and have demands. A problem is mostly that customers are not dumb but cannot find the answer they are looking for. This can be a user experience problem but also simply because there is no content. So what can you do? It’s easy, write documentation and guides on how your product can be used. For example, if you get asked a question twice by internal teams, write that question down in a FAQ and share it with your team and company peers.

If it is external even write some documentation for them. Most of the time something is better than nothing. A big point should be made that documentation is hard to write. A good guide can be found here though: The documentation system. Read through this guide and make it a goal to write down questions in a FAQ and provide documentation.

Look at competitors how they make the customer happy

Good artists copy, great artists steal. - Pablo Picasso

With that quote, it becomes clear that it is fine to look at other customers and how they show customer obsession. For example, just simply look at competitor’s documentation and write down why it is better to use them instead of your company’s product. The same can be applied to everything else, like how APIs are designed, how many clicks you need to get to the result the customer wanted, or when your customer is an internal person, how you present them with a solution that should be of high quality. So spy on your area of work on how competitors are doing, what they might do better, and what you can improve for your customers. Copy the good parts.

Understand what customer problems might appear in the future

Outlook is a big part of the higher you want to climb the career ladder. Employees that can establish a vision on behalf of the customer are golden. Based on KPIs and data from existing customers it should be clear already what is needed in the future. Formalizing this data and bringing the company or even team on the right track is important. Especially when it is about revenue and how the product could generate more profits for the company. Have a look at customer support requests and other data and see if you are observing trends in the whole industry that could be a business opportunity, whether it will be a completely new product or just a new feature. But with enough data, you can present it to your product owner to get validation and lead a project that will be successful. But more importantly, you will tackle the problems of customers that they mostly do not even recognize yet.

Conclusion

We hope we could give you some ideas on what you can do as a software engineer to do when you want or need to show more customer obsession. After all, there are many more examples of how you can show customer obsession. If you want to have a free lifetime license, feel free to reach out to us with an example of how you showed customer obsession at your job.

I am not Getting Promoted at Work - How to Escape the Endless Loophole?

Kevin Peters — Tue, 17 Aug 2021 20:00:33 +0000

Everyone in the workforce has some drive. For most employees, it is the payment at the end of the month that makes them work in their job. A lot of people are also doing their job because they love it. But in our capitalistic world, the salary of a job is an important aspect for every one of us. Because of inflation, our cost of living is rising nearly every year by around 2%. This also would mean that everyone working should get a 2% raise every year, right? Unfortunately, this is not the case for every employee. Some companies just hand out raises for promotions and similar things. Getting promoted is difficult. A lot of companies have structured plans on how to get promoted, which requirements need to be fulfilled to get to the next level. But it is not the case for every company out there making it a frustrating experience to not get promoted even if you might think that you are worth the promotion. In this article, I will explain how you can get over this and finally work on your promotion hands on. After reading this article you will have an actionable plan on what to do in the next week, month, and year to get to the next level in your job.

Get over your frustration

Do you read this article after getting denied a promotion the last time? We all know this feeling sucks. But you need to get over this feeling. See it as feedback and that you might be not ready yet. Yes, there are always other jobs and of course, you could apply for the targeted position in another company. But it won’t improve your immediate current situation. It sucks, but it is what it is. You cannot change the past, focus on the future.

Speak to Your Manager

The first thing after a failed promotion that you should do is seeking a conversation with your manager. In a lot of companies managers and their employees maintain regular 1-on-1 sessions. These sessions can be informal but most often employees talk about their growth there and the manager is supporting the employee in this regard. If your manager is not supportive, you can still ask the right questions on how to get actionable results. Make sure to say that you want to get to the next level but first review your current position. We need to make a reality check.

For example, you could ask what are the current expectations of your position to see how your manager reacts. They usually show emotions and say what you need to improve on. If they do not, try to ask generic questions like what is the focus of the company and how can I provide value towards this goal for example. Now when coming to the expectations and goals, make notes. Share these notes with your manager so you are on the same base on what should be achieved.

Define Goals

In the previous chapter, we have learned that you should try to find the talk to your manager and figure out what they expect from you directly or indirectly. After the meeting, you should revisit your notes and figure out what the goals would be that you can contribute to the company to achieve the goals. These notes should be defined in Objective Key Results (OKRs). Objective Key Results are defined by having an objective, measurable goal. This is because these goals should be trackable over a longer time frame. A goal like “Need to learn more about Topic XY” is not a good OKR because no one can track objectively how far you got with achieving this goal. If you have such generic OKRs it might be worth it to always split them down into individual OKRs. For example, you could do different processes to achieve the overall goal “Need to learn more about Topic XY”:

Finish the course … by End of April (0 out of 14 chapters done)
Read the book … by End of June (0 out of 8 chapters)
Apply principle … 6 times by the end of August
…

With going into more details you can always find measurable OKRs. Even if it sounds stupid, it will give your manager and peers some overview of how well you are doing inside the company. Every OKR should also be linked to one of the leadership principles of your company if they exist. You can read how Klarna’s Leadership Principles work in another blog article.

After figuring out what the goals are, discuss them with your manager. Present them and ask for validation. Your manager might think you are over motivated or something but just says you want to have a track that you can follow to advance your career. Also, talk with your manager about how realistic the goals are. I would always give a lower estimate than what you have initially thought because overpromising is never working out in the way you want it. Underpromise and overdeliver is where you can shine and exceed expectations.

Track the goals

Now that Objective Key Results are defined, you can start working on them. It is hard to keep track of your work. Getworkrecognized offers a solution by reminding you via email notifications to track down on what you have done. Creating this backlog takes a lot of continuous work, but when you finally want to look back at what you have achieved you can create an easy overview. For example, in our application, you can see the log of your past weeks notes easily like this:

In general, we also recommend summarizing your goals regarding the OKRs once per month. It will give you an easier time to summarize goals on a large scale.

Speak to Your Manager...again...and again

After tracking your work notes for 2-3 weeks, you should talk to your manager again. Bigger companies might have scheduled 1-on-1 sessions between managers and their employees. If you do not, ask your manager if they have a time slot of 30 minutes left per week. Normally they agree to this and you can organize the meetings normally. Review the notes you have done before the meeting for 10-15 minutes and point out things you are struggling with. In the 1-on-1 session ask your manager how they can help you or would behave in your situation. Always see it neutral and review what your manager said also. Have an open mind. Also, from time to time, mention your achievements and how the OKRs are getting followed so your manager is not just seeing the asking/demanding side of yourself.

After having 1-on-1s for quite some time you should see progress in your notes. It could be hard to visualize but one indicator is how much in percent you are close to finishing your OKRs. Another way to visualize your achievements is by tagging your notes and run analytics over them. Different graphs could help you with how frequently you are working on different topics. getworkrecognized provides these graphs out of the box. Just keep your notes in our application and you get some graphs like the following for free:

Act Like you are on the Next Level

After having your OKRs defined, regular 1-on-1s, and being on track towards your goal, it is time for the next phase in your career. In one of the meetings with your manager, you should speak about what the expectations of the role above your level are. A lot of companies have a career matrix ranked by different levels and different areas.

Find the full table here: Google Sheet Example - Career Matrix

As you can see there are different topics and different levels. Assuming you are a Level 1 Engineer and aspire to get promoted to Level 2, you can have a look at the different topics. If you are strong already in Communication, have a look at the responsibilities and key areas that you could apply already. Create some OKRs regarding these requirements to act on the level. If you have room during your work left, even follow these principles of the targeted level.

Review Your Actions

As you read already in previous chapters, reviewing your actions is mandatory throughout the whole process. Reviewing the actions is hard though. A technique that helped and is supported in our application is tagging the notes. Every action you take regarding an OKR or even in a generic way can be tagged with a specific label. These labels are normally the company values or leadership principles. An example could be the Klarna Leadership Principles, that are also described in more detail in one of the recent blog articles.

Customer Obsession
Deliver Results
Let the team shine
Challenge the status quo
Start small and learn fast
Courage
Hire and develop exceptional talent
Detailed thinkers

The leadership principles differ from company to company, and some companies do not even have a vision or these principles. In these cases, you can look through a collection of different company frameworks since a lot of them are also quite generic. In our application you can find the LinkedIn 2020 Leadership Principles that include the following principles:

Creativity: Employees need to be creative. The ability and focus on bringing up new ideas let companies strive and grow. Creative people are contributing massively to this. Persuasion: For companies, it is important to share the “why” behind decisions so everybody is onboard and pursues the common goal. People can also question the “why” that is supported, but communication to colleagues and stakeholders why the “why” might not be the best reason is encouraged.
Collaboration: Working in a team motivates everyone. Every colleague is trying to be the best but also praising other people’s successes is an important part of the team culture. It increases trust and improves the productivity of the whole team and the company.
Adaptability: Businesses and companies are in constant change. During the digitalization age more than ever before. Employees need to adjust to new situations, team changes. This requires an open mind, professionalism, and the will to change according to the situation.
Emotional: Emotional intelligence is the ability to perceive, evaluate, and respond to your own emotions and the emotions of others. This describes how you react to other people’s opinions but also how you can present your thoughts to other people in a recognizable way.

These principles are quite generic and can be applied to most jobs and professions. Tagging your notes will help you to keep the notes organized somehow and this will be useful later on.

With tagging the notes you can also create better reviews. Most often the leadership principles contribute to specific OKRs defined in the process before. Connect them and see with your notes how these notes might be related to the OKRs.

The review cycle should be something you can also plan. Getworkrecognized recommends summarizing your notes monthly. With this monthly review, it will be also easier to focus on more important goals during your Self-Review or Performance Review. It will exclude unimportant notes but also highlights your most impactful contributions.

The monthly reviews can also be used in the 1-on-1s with your manager to discuss progress on the OKRs. In general, they will help you to have an overview of your biggest achievements helping you in your whole career.

Ask for your Promotion

One important of every promotion is starting the process. Companies normally do not want to give out promotions since they do not get a lot of value out of the promotion itself. It is expected for most employees to act on the next level already for getting to the next level. When the company is not appreciating this, not increasing the salary they can play with their employees, letting them do work outside of their responsibility additionally to what they get paid for. Companies most often act in their interest and deny or delay promotions to keep the pay of their employees low and increase profits of the company overall. Because of this process, an employee should be always showing the desire to get promoted and speak up. Otherwise, you might get ignored and left behind. Take your shot.

Preparation

As we learned previously, you should always ask for your promotion by yourself. But preparing for the promotion is an important part that should be done before actually requesting the promotion.

The first two steps are described in earlier chapters: Tracking your Work Achievements and Tagging + Grouping the notes. The Review is also mentioned in the last chapter. After all of this, you can go through your work achievement notes again and create a good Self-Review or Brag sheet. This document is the baseline for your promotion. It should include all major achievements but also weaknesses. We wrote a guide already on what to focus on while writing this document. Basic learnings are:

Structure by KPIs or Leadership Principles
Start with the "bad" things, give a good last impression
Write an outlook

The Talk

After preparing your brag sheet or Self-Review, you can contact your manager. Instead of asking for a regular 1-on-1, you can ask them if they have more than 30 minutes to review your current work. Regarding this talk, you can also say that you prepared a summary of all the work achievements you have reached in the past time. Link your brag sheet or Self-Review. Then wait for the talk.

Start the talk like a normal 1-on-1. Ask some soft questions first and get more serious over time. Try to bring up the promotion topic quite fast in the meeting. Something along the lines that you are doing work that is exceeding expectations heavily and you are acting already on the next level. A promotion would be the right next step for you so that you can even try to grow more and impact the company even more in a positive way. Now your manager will react. Pay close attention to their words and how they are laying these words out. If they are happy with you, they will promote you. Ask about a salary increase and all the legal stuff as well. If they react negatively ask why they do not want to promote you and what is missing for you to get promoted.

After the Promotion

If the promotion was successful, hey congrats. If not, work on the things that your manager has told you. One thing that stays always there is to write down your work achievements because work is getting forgotten quite quickly. Use getworkrecognized to have an efficient way to do this. Try now!

From Junior to Senior Software Engineer at Klarna in 2.5 years

Kevin Peters — Mon, 31 May 2021 12:23:50 +0000

A promotion to senior level in a software engineering career brings many benefits: More compensation, more responsibilities, and a better position in your career progression. Getting promoted is difficult though. But let me tell you how I have applied simple tips and tricks to get promoted to senior-level at Klarna, one of the technology companies in Europe.

After graduating from university in 2017 in Germany, I found a job based on an internship done during graduation. A small startup. But after 1.5 years I could not see my career progressing so quickly and growth opportunities were rare. So I decided to look around and after many rejections, I got an interview at Klarna. I do not know how but I completed the interview and got an offer and was hired as a Junior Software Engineer.

A reason I wanted to join Klarna was that finally, I would have many other software engineers around me that would teach me how to build products at scale. In startups, the requirements for a software engineer are completely different from what big companies want. You need to focus more on the product. Have to tinker with marketing and work closely with Sales. It is a great opportunity for most people since you will learn a variety of skills. In the end, the dream of most software engineers is to work at a big company. You will have more dedicated time to actually focus on engineering and of course, the money is better as well.

So let us look at what my progression at Klarna has been like.

Career Levels at Klarna

Klarna is really good at telling at which stage in your career you really are. They have a detailed career ladder based on different metrics. These metrics are symbolized through 8 Leadership Principles:

Customer obsession
Deliver results
Let the team shine
Challenge the status quo
Start small and learn fast
Courage
Hire and develop exceptional talent
Detailed thinkers

Based on these leadership principles there is a matrix that is built up similar to something like this:

Level 1 - Customer obsession:

An employee can put themself into the shoes of the customer
An employee understands how working on specific tasks helps customers

Level 2 - Customer obsession:

An employee is able to create tickets based on customer’s needs
An employee deeply cares for the customer and builds features that overdeliver on the scope of the ticket

There are of course a lot more levels for employees at Klarna. Currently, employees range from Level 1 to Level 8, where for Software Engineers level 1 is Junior and level 3 is senior. Further levels are harder to achieve and split up into an Individual contributor or management path which will be discussed later.

Initial rating during the hiring process

During your interviews with Klarna, you will get rated against these principles. Klarna’s interview process is quite standard in the technology industry and is built similar to this:

Recruiter call
Homework task, Leetcode-style questions
On-Site, normally a review of the homework task + additional whiteboarding problem
System Design
Behavioral Interview with the hiring manager

During this process and based on your resume you will get rated. Is this process fair? Might be, but you always have the option to negotiate your level at that stage. Especially the round about system design will decide how you get leveled.

Personally, I had little to no experience with system design tasks before since working in a startup did not expose me to such things. Luckily the system-design-primer guide exists that you can learn with and excel at those tasks.

Promotion rounds

As within every bigger company, there is a promotion window at Klarna. It appears to happen once to twice per year, even though the process is currently changing. But the windows are build up the same. Normally you start a conversation with your manager first when the promotion window is coming up (1-2 months before) and in that conversation, you have to feel if your manager is willing to put in your promotion request. Once this is validated you can ask them in the same meeting if it would be ok to send out feedback for a 360-degree review. This means that you send out a form to all your colleagues and they rate you. Of course against the leadership principles. This can take some time!

Once you have received all the feedback you gather and summarize it and present it to your manager. Your manager then has to decide if they put you forward to the next round of the promotion process. If they decide on it, then you have to basically write a short elevator pitch on why you should get promoted. That should be really short and be readable within a minute. Once that is done, the control is out of your hand. The promotion case will be discussed in a bigger group of engineering managers and stakeholders. Once approved you will receive your promotion.

I went through that process twice and what really helped me was reminding my colleagues of what I have done in the past 6 months or year. Most of the employees forget what they have done themself in the past period so they will definitely not remember what you have achieved. For this, I track my work on a daily basis, and before sending out the form to collect feedback I am summarizing my achievements in a small brag document. 1 to 2 pages long. This will help my colleagues to remind them of where we actually worked together. This brag document I will attach to the form to collect feedback so the colleagues have an easy way to fill out the form.

The career path for a software engineer at Klarna

The engineering paths in Klarna are described quite clearly. As a software engineer, you will rise through the ranks from junior to senior normally with a focus on management but also contributing characteristics. Once reaching the senior level you will have to learn what you want to do in the future life. Stay on the individual contributor path or go into management. Both paths are valid approaches. Up to senior-level, it will not really make a difference on what you focus on, you need to have a substantial amount of skills within core engineering but also management.

Opportunities I took

So how did I rise through the ranks? As there is a system with rising through the ranks, you can game the system of course. There are different parameters that you will work on during the promotion process but it is, of course, an individual approach.

Once I landed at Klarna, I realized people give a lot of thought to leadership principles. If it is about product decisions or just how to implement a new feature. The leadership principles should be applied. A good way to see that is in the discussion. If someone’s decision is violating the leadership principles a lot of people will argue against that decision. In general, it is driving the development at Klarna forward. So make use of these leadership principles in discussions.

Follow the career ladder

As said before, Klarna focuses a lot on Leadership Principles. In my first promotion/feedback round I got a lot of stellar feedback, but also a lot of points on what to improve on. I had a lot of 1-on-1’s with my manager to focus on my growth goals. For example, we discussed what I could do within the next month regarding development work that will help me. At the beginning at Klarna, I struggled with the “Let the team shine” principle a lot. I did not had ideas on how to present the team. So my manager proposed different things:

Join a group outside of the team for voluntarily work like maintaining third-party libraries used by the team within Klarna
Or joining the engineering blogging or open-source group

I decided on the second step and quickly checked what is needed to get to the next level to fulfill these requirements. I represented my team within those meetings, but also myself.

But also on the team side, I got assigned to interesting tasks that helped me to grow. Working on creating new services and making sure they are scalable to millions of requests. I got put together with more senior engineers to do pair coding with them, but we also include mob programming within our team, a technique where the whole team gets together and codes something.

These things really helped me to go from level 1 to level 2. For the transition from level 2 to level 3 the circumstances are a bit different. You have to work on different categories that are mentioned now.

Lead the Team

When reaching level 2 and trying to get to level 3 another skill is getting a lot more important: Leadership. What does this mean? As a senior engineer Klarna expects from you two important things basically:

Can you influence the product and lead implementations that your team creates or you come up with?
Are you teaching people to code in a well way and can make developers at Klarna more efficient?

All of these things can be tackled and be focused on. Once I reached level 2 I put a lot of focus on that. I introduced the technique of creating technical design documents in our team. These are documents that sketch out the feature and architecture. They also lead the conversation about trade-offs of implementations and are living documents for taking decisions with the product manager. It helps us to get a clear mind about a feature. Once that is done it is collaboration time with your product owner on creating JIRA tickets for that feature. Once tickets are estimated and assigned, maybe go over them with the assigned person to help them understand each part of the ticket. Be descriptive in the ticket descriptions and help to give pointers on what to look out for. This is especially useful for team members that are new to the team. What I always like to do is pasting the paths of the core files that would need to be touched for the files. Based on that even junior developers would be able to code the feature mostly independently.

This gets us to the next point as well: Leading developers. To get to level 3 at Klarna you have to support the engineers in your team. It is more a job of educating and pair coding with them. Give them space and the right tips and the right time. This is important for your team level. But it can get even more important outside of the team.

Opportunities outside of your team

As mentioned before, teaching developers to be more efficient outside of your team is also a huge priority to get promoted to level 3. Next to it, it becomes important that you work together with people outside of your team. This will eventually bobble up to other engineering managers that you are doing good work with their engineers. There are different activities like changing code for other teams and so on. Just receiving recognition. I did it a bit differently.

Within the Domain

At Klarna, we have a concept called domains. Domains are small subsections of the business. For example, we have a merchant domain that just deals with the merchant-aspect of the business but also a domain for the Klarna app. Some are more B2B focused, some more on the B2C side. Overall you can say the teams work closely together but each team has its own KPIs. But what becomes more important are the domain KPIs. Your team’s KPIs will be looked at by some people but if you made larger contributions to the domain’s KPIs people will start recognizing you.

For example, in our domain, we are using a monorepo. A big repository that holds almost all services used in our domain. Improving this monorepo helps everyone in your domain to build better products and focus on features and implementation rather than infrastructure. I found many tasks like that, like creating a project to automatically update package dependencies throughout the monorepo. This will give you exposure to a wide audience and will make your case for promotions stronger.

Open Source

Most of the technology companies promote open source in one way or the other. For Klarna it was always the plan to open source part of the software to give back to a community of developers. The process was not there, so the company initiated a group regarding open source at Klarna. This group was the catalysator to set up a workflow, make sure legal requirements are met, and promoting open source when possible. I joined that group initially and build up the processes and many more things regarding the topic. For example, we wanted to have an incubator set up where projects live in private first before getting open-sourced. This and many other smaller projects helped me work with various other engineers and get recognition. I even presented the results of a hackathon during an engineering all-hands meeting in front of the hundreds of engineers working at Klarna, challenging but rewarding.

Blogging

Branding is really important for Klarna. It blends in with their leadership principle called “Hire and develop exceptional talent”. Blogging about the technology used at Klarna will help with hiring in the long term because it will create some kind of trust in people applying. The biggest companies blogging about their technology are probably:

All of them succeed because of great engineers that get hired. And part of the reason might be the blog as well. By sharing technological information you can create an environment of learning and discovering new things.

I helped authors within Klarna to create blog articles. I found ideas and asked if people would be willing to create a blog article regarding some interesting topics. I helped them with graphics, copywriting, proofreading, and many other things. And here is the important part again: I worked with other engineers. They will know about me and their manager will most likely also know about me by then. A better standing for me in the company.

Be proactive, Think ahead

A big part of my promotion rounds was that I was proactive in my action, plans, and projects. It all starts with asking for feedback. I prepare other people to remember what I have done so they can give me feedback in an easier way. I focus on my weaknesses and try to improve them actively.

In general, I was also looking at what the company’s or domain’s KPIs were and how they played with the KPIs of our team. I challenged my product owner a lot and made it clear that I want to work on certain things because it will help the company in the long term. I also had the opportunity to join a temporary team dealing with major support problems that were brought up at the domain level. It was great exposure to a new development space, I worked again with many new people, but most importantly, we solved the domain’s problems in record time. It was stressful but rewarding and the promotion was part of it. Look out for teams or projects that will help the company grow. Do not just sit there and grind the tickets you are assigned to.

Write up your achievements

An important part of my journey was gathering feedback and having strong evidence of my achievements. How have I made this possible? I wrote it down.

Writing is an essential skill in your career but keeping a work diary is not difficult. Just at the end of every day write up what you have done throughout the day. Remind yourself of your weaknesses and how you improved them. Keeping these notes will be super important. With getworkrecognized, I tracked more than a year of work notes and it helped me to write my self-review but also receive stellar performance reviews from my peers.

A simple system I have used is to track all work but tag the notes. Assign them to the leadership principles Klarna has, and you will see where you have to grow or where you need to focus on in the next weeks a bit more. Make a plan and put some tasks around that into the sprint or your upcoming weeks.

How to Write the Perfect Self-Review

Kevin Peters — Fri, 04 Sep 2020 21:47:06 +0000

Writing a Self-Review is a mandatory step in most companies' promotion cycles. The process of creating the Self-Review itself unveils a lot of challenges though. In this blog article, we will cover the most common problems writing this document and provide some tips, so you can excel at your next Self-Review.

The Promotion Process

As mentioned, nearly every company has a process to promote employees. On one hand, bigger companies might have promotion cycles that occur twice per year or in any kind of cycle. On the other hand, smaller companies might have an informal process where the initiation of the process might get triggered by the employee asking for a promotion or the manager mentioning that a promotion might be deserved. In most of these cases, an employee will have to figure out what they have done to get promoted. Most companies expect that you are acting on the next level and contribute outside of your responsibilities already to get promoted. Mentioning this in regular 1-on-1’s might be not enough. Write these things down in a Self-Review. With the Self-Review you can interact with the manager on another level because written down achievements will not be viewed as something informal like a talk during a 1-on-1. After writing the Self-Review you will probably have this meeting with your manager where you discuss the things written down in the Self-Review. Make expectations clear on what you want and why you deserve your promotion. Focus on this but also mention in which areas you can grow more to impact the business. Then it is up for the manager to get you promoted.

As you can see the Self-Review is an essential part of the promotion process and to write the perfect Self-Review, convincing your manager to get you promoted is hard. So let us start to discuss what is important.

Your Current Level and Responsibilities

The first part of the Self-Review should show what your current responsibilities are. It gives the readers a good understanding of what your current skill set should look like. Throughout reading the document it gives the base on what people compare you to. If you over-deliver throughout the whole document later, people will compare it to your original responsibilities and decide in their mind already that you are outgrowing the responsibilities and act above your job title level. In bigger companies, you normally have a level attached to your job title. The leveling system is kind of generic and also depends on the department the employee is in. For Google, these are defined from L2 (Intern) to L10 (Google Fellow). Most of the higher levels are reserved for outstanding persons and most Software Engineers cannot get above L5 or L6 since spaces to these positions are of course limited because not everyone can lead the full organization.

When not having a leveling system in the organization, it is worth listing the responsibilities of your current position. Normally these can be taken from the job description that is on the recruiting site. If you do not have access to them, it might be worth it to book a 1-on-1 with your manager to clear out the responsibilities you have right now. Keep them documented and also accessible for your manager.

In the Self-Review, you can then put the level or the responsibilities on top of the Self-Review to give the readers the information on the current state of your work. In getworkrecognized the level showcase is established within the profile overlook which you can also find in the following section:

Check your last Performance Review

An important part to prepare for your Self-Review is the review of your previous performance review. If you never had a performance review, for now, you can skip this part but in the future, you might find this useful.

Every performance review should have a result. A promotion is one result but you and your manager should have talked about long-term development and how you can grow into this position. This feedback can be just written down but most often managers create Objective Key Results (OKRs) that are a trackable result. An example of this could be for example written blog articles. It is a definite number and Objective Key Results should be always measurable. Sometimes this is really hard, but most often it is doable. When having these Objective Key Results defined, you can check them back and see if you have achieved them in the time range they were defined in. If you know of any - write them down somewhere but not in the Self-Review as an own section. Just keep track of them.

Otherwise, your last Self-Review might also contain other things that are important to see if you have grown throughout the last period. Write all these neat little things down.

Structure by KPIs or Leadership Principles

Now, after all the preparation is done. Self-Review writing can actually start. The first problem you will have is to structure the Self-Review itself. You could just write down the Objective Key Results from last time but it does not need to start with that if you do not have the resources.

Another way to start is to write down the Key Performance Indicators or Leadership Principles as different headings. For example, this could look like the following:

Hint: These are the leadership principles of Klarna. Check out this article to understand how leadership principles are working.

After structuring the main content of the Self-Review we can start by filling out details and events contributing to the individual leadership principle or key performance indicator. Also, these notes should follow a specific format which is explained in the next chapter.

Describe with Situation - Behavior - Impact

A common methodology to describe actions - both good and bad is the “Situation - Behavior - Impact-Methodology”. When people write down notes they normally write down the behavior they showed like “I created a marketing campaign for xyz”. This is the behavior the employee showed. The reason why this behavior was shown is explained by the situation though. The situation could be quite different like:

My boss told me to do the xyz marketing campaign
I researched what is the most worthy marketing campaign to do

Two different situations, where the behavior might be the same but the impact is different. The first option just shows that you are delivering results when you are told to. But the second option shows that you can work independently and figure out how to use your time most effectively. The impact should validate the behavior in a sense when the outcome is positive. It is also ok to admit mistakes made where the impact might harm the company or the team. The impact should always refer to the situation.

In general, this methodology helps you and the reader to showcase a clear thinking process. It will show you care about the things you do at work, and you want to be recognized and can see the effects of your work.

Start with the "bad" things, give a good last impression

When reading the Self-Review the reader normally goes from top to bottom of the document. To give the best impression to the reader it should start with some smaller successes, followed by some bad behaviors, and finally ending with the best behaviors. Readers normally remember the first things and last things of a given context the best. With this technique, you can make sure your positive contributions will get kept in their minds for a longer period.

Start with the worst KPI/Leadership Principle

The principle in the previous chapter can be applied to a general level in the first place. As we learned throughout this Blog we should start organizing the Self-Review first into Key Performance Indicator or Leadership Principle sections. These sections should be also sorted. Start with a mediocre one and then continue with some sections where you do not follow the expectations in comparison to the other sections. And finish with the sections where you think you might have over-delivered. Always compare the responsibilities you have listed in the profile section of your level or the job description to the actual achievements of the section.

Sort Description of KPIs and Leadership Principles

The principle of sorting the “bad” things and the good things can be also applied to the individual sections of the actual Self-Review. You will probably list multiple notes in the form of the “Situation-Behavior-Impact”-Methodology that will influence the perception of the leadership principle or key performance indicator. Even start here with listing a good, but not perfect, note first, continue with the bad ones and leave the last impression with the really good notes where you had the most impact on the company-level.

Write an outlook

After all of the tedious work of listing your achievements is done, you can start with working on the outlook of your review. The outlook can be quite generic. Do not fall into requesting a higher title or promotion just yet. Focus on growth in the future. You probably have a goal already on what position to reach soon and your manager might know this goal already - if not, maybe talk in the next 1-on-1 about your future career goals.

Since you are talking about your growth in this chapter you should start with listing the opportunities you have first. Tell how great the company is in providing you these opportunities, this will keep your manager into this chapter since they get appreciation out of it somehow. Next list which growth opportunities you want to tackle and explain to them why. You can follow the "Situation-Behavior-Impact"-Methodology here again by explaining the current state. The expected behavior and the expected outcome.

On top of that, you should define the Objective Key Results (OKRs). They are measurable goals that you can somehow achieve. For example: “I write 15 Blog Articles until the 10/20/2020”. The goal should be optimistic and reachable. Compare it to your last results probably and predict what you can do more and how you can extend on that. Also, discover new possibilities on what you can achieve. Out of your Self-Review descriptions of the leadership principles or Key Performance Indicators you should derive the good Objective Key Results that will help you to grow in your weakest areas. These should be listed at the top though again, based on what we learned in the last chapters.

In general, the outlook is about realistic goals you can achieve. List the goals that you will reach with a high percentage at the end. These measurements will stick in the head of the manager for the next time which is important for your future work career.

Convince your manager for the Promotion

After writing the review itself, but also pointing out growth opportunities it is time to evaluate your current position, responsibilities, and salary. Most often an increase in the number of responsibilities or contributions to the company is acknowledged the most for promotions or salary increases. So give a clear comparison on why the current state exceeds the original requirements mentioned in the first parts of the Self-Review. It gives you a good opportunity to get the promotion. Try to put the contributions in a good light and say that you over delivered expectations. After all your boss also needs to validate your promotion in front of their managers and they rather have hard facts and data at their fingertips rather than saying this person is just worth it. End the Self-Review with a clear statement like “After all of these accomplishments, I want to get promoted to the next level that is … and receive a salary increase of x% to y salary.”. That will give the manager a clear light on what you want. Do not ask for too little and rather ask for too much. You can always go lower but won’t be able to go higher.

And remember: You miss 100% of the shots you do not take.

You can also read this full story on our hosted blog here.