How to run effective performance reviews for developers

What makes a software engineer good?

4 min readFeb 22, 2019

Every 3 months we have performance reviews at Peergrade for all employees. The focus of these performance reviews is (not surprisingly) to talk to people about what they are doing really well, and what they can improve. The most common role we have is software engineering, so we decided to make the process of running performance reviews for software engineers more structured. The main part of this structure is a set of guidelines for the skills that what we believe a good software engineer should have.

The list of skills is formed like a hierarchy. Some skills, like writing code that works in production, are foundational. Other skills, such as reviewing code for others, become relevant when the foundational skills are in place. Finally, things such as helping out with recruiting come into play. We tell our developers that when some levels are mastered, the next levels become relevant, but not before. So if you feel like you master levels 1 to k, then you should focus on step k+1 next.

The 10 specific skills we care about are listed below, with a short description of the skill and what good looks like.

#1 Correct in production

Delivers features and changes in production that fully live up to the expectations of the person defining the task. Wrong things and bugs don’t end up in production.

#2 Speed / Iteration

Tasks are solved fast. Produces code fast and gets things done.

#3 Code quality

Makes few bugs. Has good code style. Writes maintainable code. Writes efficient and performant code.

#4 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.

#5 Code reviews

Regularly does code reviews and do them well. Is good at helping others solve problems when needed.

#6 User understanding

Understands our users and is able to form features to support their needs. Is able to emphasize with the user to proactively discover better solutions to problems. Can help users through support chat. Is able to propose relevant tasks for the roadmap.

#7 Responsibility

Putting in the extra hours when needed for finishing a feature or handling a crashed server. Proactively solves relevant problems without getting told so. Takes responsibility for not just own problems, but also problems created by others. Shows a feeling of responsibility for the product, the company, the users and the team.

#8 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. Uses learning to improve our code and processes.

#9 Leadership and planning

Takes responsibility for developing full-fledged features where one or more other developers are involved in the development of the feature. Turns difficult problems and underspecified goals into achievable projects. Anticipates dependencies and needs of stakeholders (other teams, users, customers). Defines success and how it will be measured. Creates plans and roadmaps as needed. Coordinates meetings (if relevant) and discussions to clarify things that are unclear.

#10 Recruiting

Gets involved with the recruiting process, such as outreach, screening, and interviews. Gives referrals to potential hires. Takes an active interest in new hires and onboarding. Is part of screening calls, interviews and code tests.

Running the performance review

When we run our performance reviews, we ask our developers to go through this list of skills in advance. We ask them to score themselves on each skill with 0 (needs improvement), 1 (doing okay) or 2 (doing well). Likewise, we (the founder team) score each developer in the same way before the interview.

During the interview, we go through each point. We hear how the person scored themselves and why. Then we tell them what we wrote and then we have a discussion about the performance on the individual item. When a skill gets a score of 0 or 1, we come up with concrete steps to help them improve until next time.

We make sure to specify, the hierarchical nature of the list. It is not important to focus on recruiting people if the code produced is of low quality. We also make it clear, that some of these skills are inherent tradeoffs — improving on speed and iteration might come at the cost of code quality. For this reason, it is practically impossible to get 2 on all parameters, and we don’t use the scores as a way to benchmark, but to help developers focus on the most important things.

Final remarks

There are many ways to define a good software developer. There are clearly things we are missing above, and we probably included something that other companies find irrelevant or odd. For us, this list of skills is a work in progress and works primarily as a framework to guide a productive discussion between us and the engineer.

We would love any input and suggestions on how to improve this, so please reach out!