Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

Tags:

evaluation

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:

  • What are some good performance goals for a software engineer?
  • Setting Performance goals for Developers
  • What are suitable performance indicators for programmers?
  • What is a fair productivity measurement technique for programmers?
  • I need some career “Goals” for the next year

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!

like image 417
Paul Stephenson Avatar asked Jan 15 '09 13:01

Paul Stephenson


People also ask

Why is setting goals useless?

In other words, goal-setting is a fragile way of trying to achieve results. Not only are goal unnecessary to achieve desired results (because they don't do anything systems don't already do), but they also create incentives that make it easy to achieve undesired results.

Do objectives need to be measurable?

Measurement is hugely important because it will enable you to know whether an objective has been achieved. To be measurable an objective should describe an achievement or outcome which is or can be related to a percentage, a frequency, rate or number.


1 Answers

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).
like image 158
ChrisW Avatar answered Sep 20 '22 22:09

ChrisW