I have never worked with a software developer who enjoyed writing their quarterly or annual objectives.

Most had been previously burned out by laborious processes which either meant two objectives take hours to write, or they’re easy to write but vague enough that they take hours to evidence every 3 months. In some cases they’ve even had objectives in which they had no say because they were either handed to them directly by a line manager, or had “trickled down” from group or org OKRs.

My thoughts on this were triggered by Matt Jukes’ post about his feelings on OKRs, which I share.

I have helped set objectives for dozens of developers in multiple organisations in the last 10 years. My own goals when doing this are:

1. Try to make the process as painless as possible
2. Try to align the objectives with what a developer wants to be doing – if possible work with them before the session so they can create some draft objectives of their own
3. Don’t set more than three objectives for a quarter
4. Make each objective SMART – you want to be able to look at it and say “yes this is done” or “no, this is not done” in clear terms. If you want to provide “levels of done” then that’s fine, but see point 1.
5. Set objectives which help someone grow! Whether it’s giving them confidence by building on existing skills, or learning new ones, or even just really getting to a tricky problem they have been wanting to take on, lean into these! Make the objectives desirable! Can they always _all_ be like this? Probably not, but keep your eyes open for opportunities.

None of these sound like revolutionary approaches, but in my experience, they’re still exceedingly rare and this list has taken me pretty far in building both good relationships and good people.