Performance Review 101

The intention of Performance Review 101 is to give engineering managers an understanding of why we have this process, and what’s involved. I’m sure you’ve all been in one of these meetings, and no doubt loathed having to prepare. But you only get out as much as you put in, and they’re a great way to develop your employees. Not convinced? Then read on…

Why do we need a Performance Review?

So first up, what is the point of this meeting and the hours of prep that go in prior? The key reason we have a performance review is to understand and improve your employees performance. This is with respect to both their personal needs and goals, but also the business needs. It’s not to say their performance has to be poor, but rather how can we help take it to the next level? To be clear, this is not an exercise in criticism and demoralisation. If there are performance expectation gaps, the review should aim to bridge them in a constructive manner.

From a business perspective, this process also helps paint a wider picture of the workforce. This is important when planning out talent and growth strategies. Do we have a pipeline of capable people and are we developing them in the correct manner?

In more specific terms, both the manager and employee should leave the meeting clear on the following:

  1. Progress against goals and accomplishments;
  2. Strengths demonstrated;
  3. Areas for improvement;
  4. Alignment on role expectations;

Finally, it’s important to stress that the content of a performance review should not a be a surprise to either participant. Everything discussed should have been talked about during 1:1’s, coaching and ad-hoc feedback between reviews. If you find you are giving employees a hosepipe of information, then not checking in for 6 months, you’re doing it wrong.

How to prepare

You hopefully see the benefits of having a performance review, but as a manager how do you prepare? Again, its firstly important to stress that preparation should have been happening since the last review. Anything pertinent to the review should be kept together and used as a whole, rather than relying on recency bias.

This preparation should be in the form of evidence where possible. By evidence, I mean tangible data which can be used to demonstrate points. The reason for this is that, particularly with hard conversations, you can demonstrate the process is fair and unbiased.

One caveat here with software development, is that gathering metric based evidence can be tricky. How do you accurately measure “good” code? Does low throughput represent poor story granularity? Are more reviews a sign they are not doing enough coding? As such, it’s important to be open and honest along with taking other forms of evidence.

Aside from metrics, the following are important places to start gathering evidence.

Personal observation

It’s important you are close enough to the employee that you can form opinions based on your own evidence. This could include working on projects or pairing together, 1:1’s or just general chats.


Have you employee send a self-review ahead of time. What do they feel went well, not so well and should be improved on? This is particularly useful for understanding if there are likely to be any disparity in certain areas.

Peer feedback

Speak to other developers and people around the business. The aim here is to ensure we are taking bias out of the equation along with gathering feedback from subject matter experts. The more people you speak to, the more reliable patterns emerge rather than individual points.

Prior goals and reviews

These may shed light on particular success stories and recurring themes over the past period.

Growth frameworks

Hopefully the team are using a growth framework to help guide development of employees. Look at this objectively and try to place the employee accordingly.

The meeting

The last thing to consider is anticipating how the performance review will play out. Map the self-review and gathered evidence and look for disparity. Often these will be the places where tough conversations will happen. Try and empathise with your employee and think about how they will feel, and topics they’ll likely want to discuss. And finally, remember to stress the positives too.

With all this in mind, what are the outcomes we’re after from the meeting?

  1. An agreement on performance rating;
  2. A clear understanding on what the employee should start, stop and keep doing;
  3. Actions as a manager you have taken;

The meeting itself should be a two way conversation discussing all of the above. Ensure that you are actively listening to each other and understand everything being said. It’s important that any decisions reached, such as a performance rating, are reached mutually.

Finally, remember that this meeting is a review. Ensure you have set aside plenty of time to discuss and review everything and that it doesn’t feel rushed. You shouldn’t be trying to set goals in this meeting as it firstly takes a lot of time, and secondly requires the information presented has sunk in.

Wrapping up

Following the performance review, you’ll likely have a calibration session with other managers in the business. The aim of this will be to ensure each memeber of the engineering team has had a fair review and there is no bias or skew.

Pending this, you will inform your employee of any changes and then arrange a meeting for goal setting. If all has gone well, you’ll have set them up for success and growth. Pat yourself on the back and read some more top management tips.