Having to set objectives for developers, even though objectives don't work [closed]
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:
- This is a bug: you must fix this before you check in
- 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).
Personally I try to set two sorts of objectives:
Business-focussed objectives (this is why we are getting paid after all). For instance, "complete project X by 1 June 2009"). These objectives are often shared across several members of the team (and they are aware of this). The team can exceed the objective by bringing the project in early or by exceeding the functionality required. Individuals can exceed the objective by producing more functionality, having fewer bugs against them, or coaching and supporting other members of the team.
Personal growth objectives, for instance completing a project involving a technology that the developer wants to add to their skill set, understanding the user's domain better, gaining leadership experience etc.
I feel that it is important that:
- Objectives are SMART
- Objectives are aligned with the needs of the business
- You do include "normal work" in objectives, in fact these are the most important objectives!
- The employee has some opportunity to exceed the objectives you set
Finally, I would stay away from software metrics as objectives - they are too easy to game and probably won't give you what you need. I would only use a metric where I want to coach someone in or out of a particular behaviour.
This all boils down to the fact that "first level management", and most any management doesnt know their employees. Instead of being part of the actual day to day planning and development, things like SMART pops up. If managers were to spend more time with the guys who does the actual work, none of this would be needed.
Personally, I prefer working in an agile environment where it is obvious who of the developers performs in terms of productivity and quality awareness. A true agile approach requires that not only developers, but designers, testers, customers and product managers are included in the process. This naturally leads to better insights from the managers point of view.
Measurable objectives I have seen so far:
- Pass a certificate exam
- Research technology X and hold a presentation about it
- Number of build breaking changes committed
- Number of wiki articles written on the internal knowledge management
How about asking your developers directly if they have some ideas for personal development which then could be used for objectives?