Objectives ... and Key Results

 A colleague of mine ran an open-space session today, wherein we discussed OKRs, a topic that had been presented in a recent conference they'd taken part in.

If you've never heard the term OKR before, it's short for Objectives and Key Result and is a useful thinking process for strategic improvement.

This is what I learned.

When discussing OKRs, it's important to get back to the reason - the why - of an Objective. What are we trying to achieve? Why are we trying to achieve this thing? The Key Results needs to be on the right level, so that teams can act on them. Therefore, OKRs needs to be paired with the power/authority/autonomy to act. For a fictitious bedding store, the manager might say: "I'd like us this improve the sales of beds; you have free reign to come up with ideas to that effect!". His employees might here start to observe which types of customers tend to purchase beds and eventually find out that people trying beds are more likely to purchase beds than people who are "just looking". The hypothesis the might form becomes: "Let's increase the number of customers trying beds, as a way to increase the sales", purchasing and maintaining shoe covers, purchasing bedside table lamps and other paraphernalia to make trying the bed more inviting.

If someone comes at you and starts talking about Quantities as Objectives (increase X by Y% by Z), you are likely to been given their Key Results. In this situation, start asking Why so that you can form a reasonable Objective - a story - that you can gather your team around. Objectives should help you make strategic decisions.

If you have no way of figuring out if a Key Result has increased/decreased, you need to take a step back and provision metrics before you continue your OKR journey. You'll need a baseline to start from.

Don't cascade OKRs down the organization tree. The Objective of a company will be different from an Objective of a development team, though the development team's objective should reasonable be tied to the company one.

You can use OKRs for personal development. If you'd like to learn to be a better public speaker, for example, Key Results could be improving feedback scores. This also highlights that the Key Results are a metric for Continuous Improvement - that you will not be Great on day 1, but that you will get continually better (Growth Mindset).

Don't use OKRs to track achievements or as a basis for salary discussions; it's the wrong tool for the job. "When a measure becomes a target, it ceases to be a good measure." - Goodhart's law

If you are struggling with setting Objectives, you could benefit from a Pre-mortem in which you surface all the things you can think of that can go wrong with a plan/project in the future, then asking yourself Why these things happened. Similarly, all the things that can go right with the project, again asking why. The insights you and your team will get could be the basis of your Objectives.

Review your Objectives every so often (months). Is this still a good Objective? Why, why not? If we want to change, why? The Objective should be concrete enough to be used/referenced daily, be reviewed and ideally changed seldom.

Remember that Key Results are indication of a Direction, they are not a Target. To get better Key Results, ask what it would mean if you reached them sooner than expected, or slower than expected - what would those two scenarios indicate? You are free to change Key Results if you, after evaluating them, believe that other metrics would predict your Objective better.

Objective: What is the next iterative step we want to reach?

What is the behavioral change that we be believe would lead to a better business outcome?

Key Results: What can we use measure the behavioral change?

Finally, OKRs are not something Tools or Templates can solve. They are not magic. They are a useful thinking process. The artifacts you produce, are oftentimes throwaway. 

Comments

Popular posts from this blog

Auto Mapper and Record Types - will they blend?

Unit testing your Azure functions - part 2: Queues and Blobs

Testing WCF services with user credentials and binary endpoints