Good performance reviews should be as fair and objective as possible, communicate expectations clearly, and point out concrete areas of improvement. For this, we use a skill matrix as a systematic assessment tool containing skills tailored to the role of a software developer. This post is a hands-on guide to applying a skill matrix in practice.

Performance Reviews and the Skill Matrix

Performance reviews are a formal and standardized way to assess the performance of a developer. The goal is to be more objective and fair.

Given a set of skills, each developer is asked to score themselves with 1 (need improvements), 2 (doing okay), 3 (doing very good). Moreover, the manager scores the developer in the same way. We created the following skill set, which bases on the one proposed by David Kofoed Wind:

Coding

• Speed. Tasks are solved fast. Produces code fastly and gets things done.
• Code Quality. Produces code that’s easy to understand and maintained by others. Ensures good test coverage. Writes efficient code. Adheres to the team’s coding conventions. Finds a good balance between pragmatic and generic solutions.
• Correct in Production. Delivers features and changes in production that fully live up to the requirements. Wrong things and bugs rarely end up in production.

Behavior

• Social Behavior. Shows respectful and friendly behavior. Is aware of and respects others' feelings. Contributes to a good team atmosphere. Adheres to feedback rules. Acts and communicates professionally even in difficult situations. Strives for and accepts compromises. Can “disagree, commit and continue”.
• Internal Communication. Communicates early and often, and understands what needs to be communicated to the team. Is good at using internal communication channels. Makes it easy to figure out where they are on their tasks.
• Mentoring. Proactively offers help, shares their knowledge, and contributes to the competence development of team members. Offers workshops and training in the area of their expertise.

Responsibility and Proactivity

• Monitoring. Proactively solves relevant problems without getting told so. Checks out metrics and logs regularly without getting told so. Detects problems on their own and informs about them. After releases, they check and verify that our products are running well and correct in production (e.g. checking logs, metrics, and the database).
• Platform Responsibility. Takes responsibility for not just own problems, but also problems created by others. Shows a feeling of responsibility for the quality of our products. Will go the extra mile to ensure that things are great and not just fine.
• Stakeholders Responsiveness. Reacts to problems raised by our stakeholders (in tickets or chats) and helps them out. Communicates new features clearly.
• Technical Suggestions. Suggests and/or implements reasonable technical additions or upgrades to the current tech stack. Learns diverse technologies, techniques, and topics out of curiosity. Dives deeper into known stacks and discovers refactoring potential. Uses learnings to improve our code and processes. Shows engagement during discussions.
• User Empathy and Product Understanding. Understands how our users use our products. Spots things during development that would make the user experience better. Can think beyond the specs of a specific task. What does the user actually want? Are there any other solutions? Thinks about empty states, warning messages, notifications and generally strives to provide value to users.

The Workflow

First, I create the following skill matrix and assess every developer on each skill. I recommend assessing the whole team at once.

Next, I sum up the score to a total score, which gives you an indication about the overall performance but I would not rely too much on this number.

Next, the developer is asked to assess themselves in each skill.

Finally, In the performance review, you and the developer compare their assessments. You talk about it and agree on areas of improvement.

Advantages

• Better argumentation for or against a promotion or salary raise. You can clearly specify which behavior is required for a certain promotion. This way the developer might realize that they are not ready for a promotion yet. Most likely, you have a better acceptance of your decision. Plus, you can point to and agree on concrete areas of improvement and growth.

• Base your assessment on the same set of skills for all developers. This helps to be more objective and fair.

• Avoid biases like the recency bias or the halo/horn effect.

Rule of No Surprises in Performance Reviews

Known Feedback

Performance reviews should never be the first time that a employee receives (corrective) feedback. This way, we take the opportunity for them to improve and correct their behavior. Maybe they were not even aware that there is a problem. Hence, deliver your feedback always shortly after the situation, like in your next catch-up 1-1. Don’t hold it back until the next annual performance review.

Communicate Your Expectations Early

Also, don’t surprise your team with this skill matrix one week before the review. Publish the skill matrix months before the review, make it accessible for everyone and point everyone to it. This way, every developer knows what is expected from them and can try to live up to the expectations before the review takes place.

Downloads

I created a Google Sheet that you can use for getting started. Feel free to download it ('File > Download) or make a copy (File > Make a Copy). You can also comment on it - I’m looking forward to your improvement ideas.

Contribution

The proposed skill matrix and the overall approach are based on David Kofoed Wind’s great post “How to run effective performance reviews for developers”. I adapted and changed a couple of skills and adjusted them for my needs. But the credits belong to him. Thank you, David!