HOW TO RUN A PERFORMANCE REVIEW FOR DEVELOPERS
Table of contents:
- Why should tech companies hold developer performance reviews?
- Who should write a performance review?
- What do you evaluate in a performance review? (Skill matrix templates)
- How often should you hold a developer performance review?
- After the review
- Key ideas
The most important asset for any tech company, whether a startup or a development agency, is their knowledge workers. This is especially true in the context of any digital transformation your company might be going through. As the firm reimagines the way it operates and delivers value to its customers, the quality of your human resources becomes paramount.
In such an environment, the best tool to gain insight into your team’s current state and identify the possible skill gap is an efficient, robust, and scalable software engineering performance review. Software engineers and even engineering managers - and, in fact, all of your employees - require frequent performance evaluation.
Below is a detailed step-by-step guide for setting up a performance review structure for your company.
Why should tech companies hold developer performance reviews?
We talked at length about the importance of performance reviews here, but to put it briefly, regular software developer performance reviews can help solve a number of serious issues your team might be facing, such as:
- Poor performance of the development team (missed deadlines and low-value products)
- Signs of developer burnout, and low levels of job satisfaction
- High turnover rates, lack of growth opportunities, and skill training
- Lack of feedback culture and poor communication between teams and departments
By conducting regular performance reviews, you gain priceless insights, both into your team's performance as a whole, and each member's progress, strengths, and weaknesses. These reviews should go both ways -- a regular feedback session is also an opportunity for a team lead to provide guidance and direction for their devs. And of course, managers and team leads should also be reviewed by their reports and colleagues, as well as by upper management.
It takes some time and effort to implement a cohesive and holistic performance review routine, especially when it comes to reviewing software engineers and developers. Those working with code require a skill matrix analysis, which can be hard for a manager to navigate. But as soon as such a system is implemented, your team’s growth will become exponential.
Who should write a performance review?
Now that you’re convinced your team needs a brand new performance review routine, it’s time for the important question: who does the reviewing? Well, it’s a team effort. The best approach is conducting 360-degree reviews. Yes, this can take a while, and yes it requires company-wide involvement and collaboration, but it’s all worth the effort.
If you’ve noticed that your team’s performance is slipping, the only way to get to the root cause of the problem is by inspecting the whole chain of command, diving deep into each employee’s performance, and listening to both managers’ and developers’ versions of events.
While reviewing a developer, the main goal is to assess their hard skills, with a focus on possible skill gaps. This will be the best indicator of their day-to-day performance and the quality of the product they're able to deliver. If a certain developer is lacking, a performance review will help you build a roadmap to bring them up to speed and improve their skills.
At the same time, you need to evaluate how well each employee fits in with the rest of the team, what their professional goals are, and how they see their future with the company.
To get all these important insights, you need as much data as possible. This is why each developer and software engineer needs to be reviewed:
- By the manager
- By the product team
- By the rest of the department
- By themselves (self-review)
Engineering manager (team lead) review
The same idea applies to managers and team leads. And while hard skills and proficiency with tools aren’t that relevant for engineering managers, knowing how they perform in relation to their team, and the company in general, is incredibly important.
This is why managers and team leads need to be reviewed:
- By their direct reports
- By the CTO
- By the product manager (product team)
- By themselves (self-review)
What do you evaluate in a performance review? (Skill matrix templates)
How to review a developer
Here is what a 360-degree performance review of a Python software developer may look like. Remember, you need as much data and as many different perspectives as you can get. This means you'll need some input from the rest of the team, in order to determine where each dev stands on their:
- Web frameworks
- Database search
- Design patterns
- Task scheduling
- Real-time communication
- Collaboration & communication
- Individual performance
This skill matrix will help you be strategic about the roles of reviewers and the questions you ask them.
How to review an engineering manager
When it comes to evaluating the performance of engineering managers, the same principle applies. You need to gather insights from as many sources as you can, which means going both to the upper management and the lead's direct reports. Here is what a skill matrix for an engineering manager looks like:
- Personal skills
And this chart will help you to find out what to write in a review of an engineering manager, depending on the role of a reviewer.
How often should you hold a developer performance review?
After you have your ‘Whats’ figured out, it’s time for the ‘Whens’ -- how you schedule your performance reviews is quite important, especially considering the software developer life cycle.
This life cycle should be your main reference point, as it provides a great baseline and a handy reminder about keeping your reviews regular. This, perhaps, is the most important thing about scheduling your evaluations -- they need to stay regular and conform to a schedule that your employees are familiar with.
However, you must also take into account each employee’s needs, goals, and progress. Meaning, you sometimes need to be proactive and initiate a review when you feel like a developer is in need of feedback. Likewise, you need to be open to your employees’ requests for evaluation.
To ensure a correct balance, consider the following evaluation frequency. How often you should hold software developer review:
- Onboarding skills evaluation review
- 3-month performance review
- 6-month performance review
- Annual performance review
- Review after completion of a major product
- Review on developer request
After the review
Each performance evaluation you initiate needs to have a specific goal. Keep that in mind when setting things in motion and try to approach these reviews mindfully.
Once the evaluation is complete, you need to organize your findings and make them actionable.
This is the stage where you turn data into insight, opinions into actions, desires into goals. On top of that, you must keep tabs to track and compare each employee’s performance over time, as well as the general state of your team as a whole.
Each case is going to be different, but try to keep the following universal goals in mind when analyzing the results of your performance reviews:
- Identify your team’s strengths and weaknesses
- Create development plans for every team member
- Make decisions on promotions and rewards
- Integrate individual growth plans with your team’s skillsets
- Regular high-quality performance reviews are your main tool to get insight into your team’s current state.
- Such performance evaluations can help solve a number of issues your team might be facing, before they grow to become a serious problem.
- The best way to conduct these evaluations is by doing 360-degree reviews. Performance reviews should be a team effort.
- Software developers and managers require different approaches, but the methods and the logic should remain the same.
- Base your evaluation schedule on the software developer life cycle, but consider each employee’s unique circumstances first.
- Approach these reviews mindfully, with a clear goal in mind, and organize your findings.
- Track your team’s historic performance and emphasize the progress.