Software engineer performance review
One of the key tasks in leadership positions is speaking to your team members and give feedback. That's the »make people awesome« part of your job as a team lead / engineering manager. Therefore I have regular one-on-one meetings with each of my team members every second week. Additionally to that, we do quarterly performance reviews at Scout24 as one tool of our people development process. I put the focus of this reviews on performance, behavior, and goals. All these elements are put on a one-pager (A3 paper) like this one:
Now I want to walk you through the one-pager and describe the different review areas.
Good & bad things
Usually, I start at the bottom left corner of the one-pager. Here is a list of everything mentionable happened in the past time frame (at Scout24 we use a quarter). This includes positive things, questions I got and negative observations. This is the start for my preparation of a review to get rid of feelings and have a more precise idea what happened. It's also the first thing I talk about at the review meeting. Usually, this is the hardest part to remember concrete actions and behaviors. I categorize the important actions and behaviors of a software engineer in different areas, something like a framework.
The 5 performance categories of a software engineer
On the top left corner of the sheet is a bar chart with 5 different performance categories. This chart represents the performance of a software engineer as I see them. This is the first part of the performance framework I use.
Within a career level, the results should be comparable. An example for different career levels could be junior, professional, senior and lead/senior specialist. But a high chart for a junior isn't the same as a high chart of a senior. These performance categories are:
- Technology and architecture
- Product and Business understanding
- Thinking smart and user-centered
- Agile behavior and teamwork
- Visibility internal and external of the company
For more details about my performance framework, you can read the dedicated article on how to evaluate the performance of a software engineer.
Core Values
Beside of the pure performance, I also want to review the behavior of a person. This is the second part of my performance framework. Therefore I use the core values/company values. These values describe how we as a company want to behave. The core values are not connected with the carrier level, so they should be comparable within a group of people with the same profession. I wouldn't compare groups of people from different professions because they could be interpreted differently: I would define different behaviors to be important for a software engineer than for a sales person. In the time when I worked for Scout24 we had these core values: Agile, One Team, Winning and Data-Driven. Maybe you noticed, that the sheet talks two times about agile. I see there a difference: Agile and teamwork from the performance area concentrate more on the agile software development process and teamwork. Agile in our Core Values is more about people's flexibility and fast delivery.
Action Items
At the end of a Quarterly Dialogue, I talk about some action items I consider as relevant to improve for the next evaluation. Usually, they are focused on one or two areas, more isn't helpful. I try to come up with as concrete action items as possible - but sometimes they are a bit fussy. In both cases, it's very important to talk about the action items in the further one-on-ones to support the improvement goals.
During the Quarterly Dialogue (feedback meeting)
That's the theory, now we need to go into practice. The person needs to get the feedback. Otherwise, it's worthless.
At Scout24 we had a structured meeting format called Quarterly Dialogue. This is the most impotent part of the performance review. If you like to have a different behavior it's critical that the other person knows what's good and bad (based on your opinion - they may have other options).
In this meeting, I present the review one-pager. My main goal is to discuss the different areas as much as possible. Sometimes the person feels treated unfair, that's why I ask after finishing with the explanation of the one-pager for their opinion for this feedback (if we didn't discuss the feedback during the presentation). Feedback, even a performance review, is just one point of view. It's likely to have different views on the topic. So it's important to discuss each of the findings. Maybe I missed some positive behaviors, or I mixed something up. Direct feedback is important and I adjust the rating on the one-pager if I get convinced that I reviewed wrong.
It's always a good idea to include some 360-degree feedback from the direct peers / other team members in the review to eliminate some biases of oneself.
The action items are the final thing that should be clear and agreed on. My suggestions in the one-pager are just suggestions. I prefer if the people come up with own ideas how they could improve themselves. To get a commitment on the action items one good way is to write the action items somewhere (shared document, flip chart...) and share it with each other. (Best: the person who gets the action items should write them down)
This was part one of the software engineer performance series. You find part two of the performance framework here.