A Poor Performance Review

I suppose you get three types of developers

  • those that are good
  • those that aren’t so good but are working to get better
  • those that are poor but think they are brilliant

I like the first two. Working with good people brings out the best in me, keeps me challenged and on my toes. Working with people to develop their skills is thoroughly enjoyable; teaching them architecture, planning and having a good excuse to reminisce about my days as junior programmer…

The final category is somewhat harder to deal with. I’ve recently had the pleasure of delivering an annual performance review for a developer who overrates himself. There’s no point approaching the review with total honesty – communicating exactly what I think of his skills; there are only two outcomes of this approach: the developer either does not believe you and so makes no effort to get better or the developer believes you and you have removed every last drop of confidence leaving the developer paralysed. I can hear my some of my US colleagues saying ‘fire him’: for good reasons or bad, this is not always an option.

The approach I took was one of small steps. Part of the annual review is a self appraisal exercise over certain competencies (score yourself 1-10). Naturally the developer had given himself all 9s and 10s. Rather than run through the list and change them all to 1s and 2s, I targetted about  a third of the competencies and asked questions about them: can you tell me what this competence means (for example time management); you’ve rated yourself a ten – tell me what excellent time management means to you; can you give me an example of when you have exhibited excellent time management. The developer was not able to offer any examples of exhibiting excellent time management which gave me a reason to move his score down. During the discussion I used examples of behaviour he had seen from the rest of the team that were good exemplars of excellent competencies. I moved his scores down from 9s and 10s to 6s and 7s. A more honest move would have been to 3s and 4s. But the purpose of the review is to help the developer improve his performance; leaving him a demotivated shell would not help meet this objective.

By the end of the review we had spent a good hour talking about how excellent developers behave and what he could do to improve his performance. It was undoubtedly a hard review, nor could it be thought of as motivating; by the end of the review I felt we had made some good progress towards giving the developer ideas and ways to improve his performance.  This will be followed up with monthly informal mini-performance reviews targeting the same areas so we can work together and the developer can become a valued member of the team.

  1. No comments yet.

  1. No trackbacks yet.