Having to set objectives for developers, even though objectives don't work

Paul Stephenson picture Paul Stephenson · Jan 15, 2009 · Viewed 81.3k times · Source

It is generally accepted that setting measurable objectives for software developers doesn't work , as too much focus on the objectives can lead to behaviour counter to the organisational goals (so-called "measurement dysfunction").

However, in my company, we are required to set objectives for all staff, and are encouraged by Human Resources to make them SMART. In the past, my fellow first-level managers (team leads) and I have tried a number of approaches:

  1. Set measurable objectives that are additional to the normal job, like "Do training on technology X", "Create documentation for piece of code Y that no-one understands" and so on. When it comes to the annual performance evaluation, rate developers not on the written objectives, but rather on my opinion of the unmeasurable value of their normal work, since that is actually what the company cares about.
  2. Set very specific objectives like "days' work done as recorded by the task management system", "number of bugs introduced", "number of production issued caused". This led to inflated estimates and incorrect classification of bugs, in order to achieve better "scores". Interestingly, even those developers scoring highly on this system didn't like it, as the intrinsic trust within the team was damaged and they didn't always feel they deserved their high position.
  3. Set vague objectives that are variants on "Do your normal job well". When it comes to the annual evaluation, their rating does reflect performance against the objectives, but the objectives themselves are not measurable or achievable, which is frowned upon.

None of these is ideal. If you have been in a similar situation of having to create meaningful, measurable objectives for software developers in spite of the evidence against their effectiveness, what approach has worked best for you?


Related questions I found that don't quite address the same point:


Update (18 November 2009): There are 10 upvotes for my question, and the highest-rated answers only have 4 upvotes (including one each from me). I think this tells us something: perhaps that Joel and the others are right, and that the combined wisdom of stackoverflow cannot come up with any compelling, measurable objectives for developers that could not be gamed without adversely affecting the true (unmeasurable) value of their work. Thanks for trying though!

Answer

ChrisW picture ChrisW · Jan 15, 2009

what approach has worked best for you?

Only one objective: pass a code inspection/peer review, with me as the reviewer, without me finding any bugs or having any other criticism, that has me asking you to redo something.

Notes:

  • I wasn't measuring new hires' ability to finish quickly, and didn't encourage them to: I wanted people to learn how to finish well (because if it's not finished well, then it's not finished)
  • People learned what I looked for in a code review: so it's a learning opportunity and a quality control measure, and not just a management objective
  • My comments would have two categories:
    1. This is a bug: you must fix this before you check in
    2. As a suggestion, I would have done such-and-such
  • After a while, my reviews of a person's code would stop finding any "must fix" items (at which point I wouldn't need to review their work any more).