How to set objectives for Developers that actually work

If you line manage developers in an Agile environment, then you’ll undoubtedly have heard the complaint that conventional methods of setting objectives don’t really work with them. People might say that business priorities change too much, projects get delayed due to external factors, things can’t be measured, or the objectives are too different across the team. This article details a system I implemented a while ago which got to the heart of the problem and resolved it.

In the team in question, the previous managers had lost all faith in the objectives/appraisal system and had in one case even just written “turn up and don’t be late” as the objective! This was very serious as people’s bonuses were linked to the overall appraisal score, which itself was calculated from an average of each objective’s score. However even after correcting this and setting more sensible objectives, we still found that developers weren’t engaging with them. We dug down and found that the root causes were: a) they felt their way of working as closely-integrated teams wasn’t being encouraged, and b) the objectives didn’t allow measurable targets to be set with any accuracy.

So we brought in two large changes: firstly, we introduced the concept of team objectives whilst also retaining personal objectives. Secondly we only selected objectives that could be measured numerically and then scored directly against our numerical appraisal scale.

For each Scrum team we set 5-8 objectives that each team member could clearly feel they contributed to. It helped that our coders, testers and designers were tightly integrated already. We chose things like % unit test coverage, average build times in our CI system, and % of sprints where the goal was met. Scores were from 1 to 5 (which hooked into the overall appraisal score), where 1 would reflect a worsening, 2 was keeping it the same, and 3, 4 and 5 were increasing levels of improvement.

For the personal objectives we set them against personal improvement goals which nonetheless could be measured, although we weren’t as strict on finding a metric for all of 1 to 5 – this widened the pool of objectives we could choose, separated them from the team objectives, and allowed some discretion from manager and employee when scoring time came around.

We also cross-checked with the product owner (who was under different line management) to ensure the team objectives were broadly in line with their own, and did the same with the Support team (albeit a little more informally – we had to be cognisant of how much time we had for the whole exercise). Overall, it took a lot of time to get the teams to agree on the 1-5 scoring criteria and communicate with other departments, as did the need to set both team and personal objectives – so do watch out for those areas if you want to try this out. In fact, I needed to ask HR for more time, but we eventually got everything signed off to everyone’s satisfaction.

In conclusion the exercise was worth the extra effort. The teams became much more engaged with their objectives because they reflected both the push for continuous improvement and the team spirit embedded in our culture. They even carried on referring to them after the exercise finished, rather than just forgetting about them – and it’s not often you can say that!