Strong opinions, weakly held

Performance reviews for developers

It just occurred to me that I’ve never had (or given) a really well executed developer-centric performance review, and it had me thinking about what should be in such a review. There are a lot of things that should be discussed in any performance review, I’m not going to go over those. I want to talk about the kinds of questions a developer and their manager probably ought to discuss at their review.

To me, the most important part of a performance review is to help the person getting the review get better at their job. It’s a chance for people to get feedback that will help them figure out which skills they need to improve and determine where they may be lacking in terms of professionalism. The second most important part of a performance review is to help the manager get as much value out of the employee as possible. Does this person work better undisturbed most of the time or regularly collaborating with others? Is this person happiest grinding away at hard problems that discourage most people? Do they like or dislike refactoring old code that could use improvement?

With that in mind, here are some questions that managers might want to discuss with developers in their performance review:

  • What code that you wrote this year are you most proud of?
  • What code that you wrote this year would you rewrite if you had the time?
  • Did you work on anything this year that you felt was a waste of time?
  • How was the release schedule? Did we release too often or not often enough?
  • What skills got rusty this year that you want to get back to using?

The last thing I’d add is that I think annual performance reviews are really important. In many cases where programmers manage other programmers, they tend to be ignored or handled in a cursory fashion, but I think that’s a big mistake. So if you’re a manager, do your performance reviews and put some real work into them. Your employees will benefit, even if they don’t appreciate them.

1 Comment

  1. I like the intention of improving performance reviews. Here’s some thoughts:

    Those questions are nice, but it doesn’t seem that they will lead to any kind of evaluation of performance. Seems like the kind of questions that might be useful in a group retrospective meeting. Good general questions from the manager for a review could be: “what work have you done that I don’t know about?”, “what have you done that is critical for this company’s success?”. Ideally, the employee knows what is expected of him/her, and has done a self-review for the manager to review before the manager does the performance review.

    In a performance review focused on helping the developer improve, the manager needs to determine the skills that are essential to the job, and how the employee is doing. If they aren’t meeting expectations, then set some goals or work to find a position that has a better match for the employee’s skills.

    Preferably, the manager has specific examples of how the employee is doing well (as well as dropping the ball) and follows up with the employee immediately, without waiting for a formal review.

    In an Agile environment (or even in general), performance reviews can do well by getting input from the employee’s peers (http://goo.gl/tyXlv). The peers have much more interaction with their teammates than the manager does, and in aggregate will provide superior feedback for the manager to analyze.

Leave a Reply

Your email address will not be published.


© 2019 rc3.org

Theme by Anders NorenUp ↑