We’ve covered a lot since part 1 introduced this series:
In the last post about OKRs, I argued that you don’t need them at all. They can be useful, but it’s good to think carefully about what you want to get out of them and whether you’re seeing a good return on the time and effort you’re putting in.
If you do decide OKRs aren’t worth the hassle, there’s another rarely-mentioned thing you should keep in mind:
There’s lots of processes we ask teams to take on, that need people to give care and attention if they’re going to work – OKRs are something that people need to stop and think about. What makes a good objective? What key results can we measure? How is this different from various other goals, targets, deadlines and project plans they’ve been asked to use before?
After putting time into training, presentations, workshops, orgs sometimes find this framework isn’t giving the benefits they’d hoped for. For some teams / companies / types of work, I think OKRs just aren’t a good fit — and in places where they could work well, they sometimes don’t get the attention and feedback they need, meaning teams or managers have to do their best with a framework someone else said was important. If you spend ages setting these, each quarter, and don’t feel they’re supporting your work’s direction… there can be a gradual drift away from using or talking about them.
It’s awkward to face into the “we asked everyone to put lots of time into understanding these, and it turns out they aren’t actually useful” conversation. But I think this kind of quiet fade out can be much more damaging. An article from NOBL on “Change Theatre” describes the risk of making a habit of launching big, compelling initiatives and quietly letting them drop unremarked:
It’s a painful read, asking you to think about “every failure to follow through”. How many times have we said something’s important, then found it hard or got busy and let things drop? They describe this as being like a ratchet, increasing the cynicism to any “this new idea really is important” changes that may come in future. After enough of these, you might lose the ability to change anything at all. When something new seems hard to grasp or isn’t clearly beneficial, people could listen to you and invest some of their busy time in it… or quietly nod along, not really engage, and think “knew it” when this to falls by the wayside.
Dropping OKRs, or anything else, doesn’t have to feel like this – if they’re introduced well at the start. “Here’s some things we hope this’ll help us with, and this is how we’ll know whether it’s working” is quite different than most launches – and pairs well with a “this didn’t work out, but we’re glad we tried” official ending if it comes to that.
You have other choices too. If you still think setting goals and measuring reflecting on progress every few months is useful, but your OKRs aren’t doing a good job, you don’t necessarily have to drop OKRs either loudly or quietly. Various other frameworks complement them nicely.
You might find it useful to keep the essence of OKRs – state a readable objective, and give it some measures in the form “from x, to y, by [date]” – but spend much more of your energy on a framework that fits you better. You can try different things over time while leaving that outward “interface” stable. You’ll probably have a few people who are very interested in what makes different frameworks tick, and keen to explore, and a larger group who are less interested in the details. Give people a choice – if they’re busy, there’s no need to explain a new framework’s acronym and subtleties to them every time you try something.
For example: “4 disciplines of execution” by Chris McChesney and others (book summary, short video) has some handy advice.
They stress that we’ve all got lots of day-to-day things that need doing, without setting goals around them – regular work and urgent new things come up all the time. The authors call this “the whirlwind”. It can be all-consuming – focusing on any improvements or goals can feel impossible, as the whirlwind sweeps up your time. You don’t get to ignore this “day job” by setting goals on what you’d really like to do.
They recommend choosing very few (one or two) wildly important goals. If everything else keeps going, at its current level, what achievement would make everything else seem secondary? Pick measures that you can track weekly, make progress visible, and carve out whatever chunks of time you can to make sure these get worked on. Don’t expect all (or even most) of the team’s work to be accounted for with these – the whirlwind goes on.
These can be framed as OKRs, with:
- A few briefly-described goals (Objectives) and measures (“from x, to y, by [date]”)
- An acknowledgement that there’s lots of other work going on, that doesn’t need shoehorned into this format (you can’t stretch everything)
- A clear explanation that we expect to actually hit these numbers, not expecting 70% to be success (committed rather than aspirational)
- A distinction between lag measures (often the measure you really want will appear late, so it’s hard to understand and adjust progress weekly) and lead measures (easier to measure and influence, with an explicit assumption that this is linked to what you care about (you can never pick the right measures – but this sounds helpful). More on lead and lag measures here.
Another acronym, framed as a better alternative to OKRs, is NCTs – see this Reforge article from Ravi Mehta and Natalie Rothfels. The advice there sounds sensible, but I’d worry if a team or org has been getting people to learn the ins and outs of OKRs and now turned up with “throw that out, here’s a new thing”. If you live in the UK and have kids, “NCT” is already a well-known acronym – it’s those helpful classes lots of people go to – overloading an entry in my already full-up list of TLAs.
If like the advice in the NCT articles, you don’t need to make an announcement about “OKRs out, NCTs in”. You could just adjust the focus of what you’re doing now:
- Some more narrative about why you’ve chosen this objective, that’s written with it and shared regularly (a good habit!)
- State that key results are committed rather than aspirational
- Use output key results when it makes sense, rather than insisting on outcome and user-facing ones (like the “boring” original OKRs)
- Have a backlog of specific tasks you expect to do, in addition to the less-specific key results. Lots of OKR authors recommend this and I’ve used it myself, especially as a “we expect these tasks to be the work that helps us meet the objectives, but will reorder or change them as we learn more – like any good backlog.
I think that moving away from the OKR label, or any other name, to just “here’s how we do goals” (Andy Grove did this in the OKR origin story) can be very helpful. Interested teams or individuals can try out ideas from other companies, experiment with their own ideas, without needing everyone involved to keep up with all the latest articles and trends.
Speaking of experimentation: depending on the type of work a team’s doing, hypothesis-driven development (from Barry O’Reilly) can be an excellent tool for understanding progress and choosing direction. If you want to (or are mandated to) use OKRs, you can put most of your effort into hypotheses, then just state the O and the KRs using parts of the hypothesis you’ve chosen.
Having the timebox OKRs gives might be a useful addition – a decision on when you’re going to check in and decide whether to adjust or throw away your current focus.
I’m a big fan of impact mapping (from Gojko Adzic), which gives a lovely way to keep focus on the outcomes you’re hoping to achieve and how you’ll know early whether anything you choose to do is moving you in that direction. All the lines on an impact map show where you’re making assumptions (we assume this deliverable will cause this change in user behaviour – did it? And we assume that behaviour change will affect progress toward this goal – did it?).
The explicit assumptions help discussion about any work that comes up – if we build this thing, which measure will it influence? And how sure are you that’ll actually happen? Acknowledging this uncertainty helps push for smaller steps. As Gojko said on a training course once: How sure are you that this big new thing’s a good idea? Would you bet… lunch? A car? Everyone on this team’s salary for a month? Facing into questions like these can motivate people to make smaller bets (with simple versions, or some user research), to see the numbers move a little before we wager more of the team’s limited time. Perfect.
With an impact map in place, you can pick the goals, actors and impacts you’d like to focus on for a few months, and describe them like OKRs. This sets you up for regularly scheduled reflections. Maybe you’ll find:
- We wanted to try several things and act on feedback, but only managed one thing in 3 months – how can we improve that?
- We tried lots of things and saw behaviours change, but that hasn’t affected the measures of our goal at all – are these linked the way we assumed? Is there something else going on?
- Now we know a bit more about these behaviours and their effects, do we want to spend more time in this area? Adjust the targets for next time? Or park these and try a different part of the map?
There’s lots more articles about using impact mapping well (including paring it with OKRs), and a Creative Commons licensed workshop you can try running yourself to introduce this to a team.
Next time
The grand finale is almost here! In part 7 I’ll share one more thing nobody tells you about OKRs, and wrap up this long-running series. Thanks for sticking with it.
Leave a Reply