A guide to avoiding OKR pitfalls (with worksheet)
By: Michael Upton
Tags: Outcome Over Output, Worksheet, Agile, Product Development, Okr

Redgate, like many other companies, use OKRs (Objectives and Key Results) to help teams understand and describe their goals. And also like (most?) other companies have discovered while trying to use them, it’s been harder than we expected. As you might have guessed from the title of this post, I’ve put together a worksheet that guides our teams to build more effective OKRs that help them focus on the outcomes they’re trying to achieve, and to know whether they’re heading in the right direction. Spoiler: if you just want to download the worksheet, skip to the end of this blog post.

The worksheet captures how we think about OKRs now, but we’ve been on an interesting journey with OKRs since we introduced them to the product development teams in 2016, and you can read about some of our experiences here on Ingeniously Simple, or even listen to our podcast episode featuring the fabulous John Cutler. It’s worth knowing that in our journey we’ve ended up with a slightly different flavour of OKR to that originally described by Andy Grove of Intel in High Output Management, and popularised by John Doerr in Measure What Matters. We’ve come to something closer to the model described by Christina Wodtke in Radical Focus, with an outcome-focused twist inspired by Joshua Seiden’s Outcomes Over Output.

It’s certainly not been smooth sailing — and pretty much everything written about OKRs warns you that this will be the case when you start using them! While the basic concept of OKRs is simple — the Objective is what you’re trying to do, and the Key Results are how you’ll measure and know if you’re succeeding — actually using them is far from easy.

Pitfalls

So what traps did we fall into on the way?

Endless hours in meetings with the extended team

In the beginning, we went all out. We gathered the whole extended product team — the tech lead, the product manager, the designer, all the engineers, the sales champion, the product marketing manager, the support champion — for day-long workshops to concoct perfect OKRs. We were thorough! Our intentions were good, but the load was heavy for facilitators and team members alike, and the return-on-investment for most involved wasn’t great. As you can imagine, those OKR workshops (and, by extension, the whole idea of OKRs) became pretty unpopular.

Over time, we learned to make the OKR sessions shorter and smaller, preferring to satisfice rather than spending hours coming up with the perfect wording. We’ve also made use of optional meetings (if you don’t come, you don’t get to complain about what’s decided!) and provided structures and templates (like this worksheet) to make the process easier.

Starting from scratch every quarter

Measure What Matters talks about a quarterly cycle for OKRs — and we took that very literally. Every quarter we’d re-do the whole process, revisiting the strategic and business context, re-questioning what we might want to achieve, and re-creating all the KRs. Combine that with the painfully long process I’ve already described, and teams could easily be forgiven for never wanting to talk about the OKRs again until they were forced to at the next quarter’s workshops, which led to…

Set and forget

So we’d set our OKRs for the quarter with great ceremony, get everyone in the team to sign them (yes, really), put them on the whiteboard, and then… ignore them for the rest of the quarter. As we drew near to the end of the quarter it was time to report on them in the quarterly reviews and, unsurprisingly, nothing much had happened to the KRs.

Other times, the problem was that something had changed and the objectives or key results were no longer valid, but the idea of going back through the process of resetting our OKRs was just too painful.

We’ve changed our approach here too, to try to avoid set-and-forget. From Radical Focus we found a useful tool to help remind teams to look at KRs more regularly, and change course when they weren’t moving in the right direction: the 4-square, or weekly check-in (http://eleganthack.com/monday-commitments-and-friday-wins/). There’s a brief description on page 3 of the worksheet. We also shifted away from a rigid quarterly cadence, encouraging teams to change OKRs at ‘the right time’ — maybe when all the KR targets have been met, or maybe when something else has changed that means they’re no longer correct. Page 4 of the worksheet has an FAQ that covers some of the scenarios when you might want to revisit your OKR definitions.

Focusing on output instead of outcome

A more subtle trap it’s easy to fall into is setting key results that measure outputs rather than the desired outcomes (see this classic article by Jeff Patton for more on the difference). We were clear when we started working with OKRs that we wanted them to be outcome-focused — but our focus was on making outcome-focused objectives, and then on making sure that our key results were measurable.

The trouble is, our outcome-focused objectives were often hard to measure directly, or fast enough to get good feedback. That sometimes led to using more easily measurable things like progress through a backlog, or shipping features, as key results — measuring the work we were doing, not whether that work was actually achieving the objective. The connection between the work and the desired outcome was assumed, rather than being tested and verified by the key results.

This has been the hardest area to get right, and one of the most helpful resources we found was Joshua Seiden’s excellent (and concise) book Outcomes Over Output. He uses a very specific definition of an outcome:

“An outcome is a change in human behaviour that drives business results”

which gives a good starting point for defining key results. Changes in behaviour are easy to observe, and therefore relatively easy to measure. If you can reason about the changes in behaviour you’d expect to see if you achieve your objective, then you can use measurements of those behaviours as your key results. This shift, pushing the outcome focus down to the key results and talking in terms of behaviour change, has probably been the biggest improvement in our use of OKRs.

Why have we stuck with OKRs?

If the OKR process has been difficult, why have we stuck with it? Because it’s a great fit with our values and beliefs around software development. We believe that the best way to make software is by engaging teams that are empowered with clear purpose, freedom to act and a drive to learn. OKRs are a good way to think about and communicate the team’s purpose, and focusing on outcomes instead of output puts the decisions about what to build in the right place — with the team — while keeping alignment with the rest of the organisation about what they’re trying to achieve.

OKRs aren’t magic — but magic happens when product teams are truly thinking about the outcomes they’re trying to achieve, whether the work they’re doing is actually helping them achieve those outcomes, and whether achieving those outcomes will help the whole organisation with its goals.