Adaptive OKRs - AOKRs (OKRs Part 3)

Hello hello, Tom & Corissa here,

We used to be called ​Trigger Strategy​ but now we're Crown & Reach.

Today is part 3 of my OKRs don't work series.

• In Part 1, I introduced some social and neurological fundamentals of why OKRs don’t work the way they say they do on the tin.
• In Part 2, I dug into what we mean by objectives and how they relate to the adjacent possible.
• In Part 3, I introduce a little twist to OKRs that helps them work, which I’ve called Adaptive OKRs (AOKRs).
• Later: what to do when you’re struggling to choose an objective; context and how it matters more than you’d like; what to do as a leader to get more of the promised benefits of OKRs; and what to do if you’ve been gifted terrible OKRs.

Originally published via Substack, Mar 06 2024.

Executive summary (in case you’re too busy hustlin’)

Adaptive OKRs embrace the fact that you’re not made of magic, and so you probably can’t guess the right objectives when you’re making plans for the quarter or the year.

The brutal truth: You set an OKR. One month in, you realise it's wrong and you wish you'd set a different one. But changing course feels so hard it might as well be impossible.

The solution: Adaptive OKRs (AOKRs) – they work like regular OKRs but they have built-in escape hatches, just in case.

The magic ingredient: Adaptation triggers agreed upfront.

An AOKR contains:

• Objective – (as usual) qualitative description of what we’re trying to achieve
• Key Results – (as usual) the signals that will tell us when we’ve made it
• Adapt – (new!) what conditions do we all agree we’d need to see to make us wish we’d set a different OKR?

There are three advantages to installing Adaptation triggers openly from the outset.

1. Discuss what changes are acceptable upfront
2. Change course the instant you realise you need to
3. Reduce the effort of setting OKRs in the first place.

OK, if that’s all you need to go forth and A your OKRs, go for it. Let me know how you get on!

For the rest of us, let’s break it down …

What's a Multiverse Map?​
​
At a high level, it’s a hypothetical story map that shows what one customer will see and do in the best and worst possible universes for an idea.
​
I’ve included instructions for making Multiverse Maps at the end of this article. You can also watch me making a map live in this video.
​
If you’d like more help, we teach this style of mapping as a course and offer it as a service.

Capturing our thinking visually on a map like this helps expose and align our intuitions about the customer behaviours we hope to change and the risks we might face along the way.

When it turns out we’re not aligned — when debates break out or we risk heading down rabbit holes — I encourage everyone simply to add their competing stories and ideas to the map.

The map we’ve made becomes a shared model that we can hang our not-shared thinking on. We capture all our different beliefs, assumptions, hypotheses and anecdotes.

We layer on everyone’s different stories about why things might be happening in different ways. Add our predictions about what we think might happen later. And note down all the different experiments and ideas we might want to try – as options. We can also capture questions, concerns and risks right there on the map as they crop up.

We don’t need to fight about what we’ll actually do yet, we’re simply exploring the adjacent possible.

You can learn more about how this works by reading Signals > Stories > Options.

Importantly, we can also add Signals to the map. These are what we’ll be able to measure that indicate if our idea is working or not. Those help us define Key Results.

Overall, this process helps us clarify what Objective(s) an idea enables us to go after.

Surprisingly often, making this kind of map enables us to identify simpler ways to achieve our ideas, or to spot fatal flaws in ideas before we’ve invested too much.

It sounds like a lot, and you won’t believe me when I tell you that making this kind of map can take as little as 10 minutes once you get the hang of it. Realistically, depending on the scale of an idea, expect to spend between 20 minutes and an hour, possibly even longer the first time. But I promise you this is time very well spent.

Weeks of debates and misunderstandings will save you a whole hour making a map

The secret is to dive in and get started. Think your way through the conversation by actively making and rearranging the map, don’t have a long conversation about concepts in the hope that you’ll magically know the right map to make later.

Make a Shitty First Draft OKR

Armed with the map, defining an OKR becomes easy. Using what we learned from making the map, we’ll draft a rough version of the OKR we might set from it. We just want to get something down that we can poke and prod. So we work quickly, using rough wording for the Objective and putting in placeholders for changes in suggested Key Results. We don’t want to get lost in rabbit holes about what’s realistic – not yet.

An imaginary example might look something like this:

Run a speedy pre-mortem to spot what would make you adapt

To make this into an AOKR, we introduce one more exercise. I ask:

This always surfaces hidden risks, and we can list some of what might derail our OKR.

In this imaginary example, we might say that we couldn’t achieve the OKR because:

1. We realised the system was too hard to change technically. We saw this when we found there were too many dependencies. Or when [Service Foo] couldn’t handle the volume of requests we needed to make.
2. We tried 3 different solutions but they didn’t work in the end, which suggested that we’d misunderstood something about the underlying problem. We realised this after we tried the solutions as A/B tests and none of them moved the needle.
3. The real blocker was something we can’t access. It’s on another system the customer has to use. We realised this by watching customers use other systems and by talking with the customer support team.
4. It turned out there’s a deeper emotional reason behind the customers calling support. We started to realise this when our solution led to a higher task success rate, but the same volume of support calls. It really became clear when we listened in on some support calls.

Some of the risks listed above would have emerged naturally as we discussed the objective, but I always see more risks surface with this ‘pre-mortem’ style framing.

Turn the risks into Adaptation triggers

Each Adaptation trigger has the same format:

Working through the list of risks above, we can break each down to get one or more Adaptation triggers. I’ve added the triggers under each of the numbered risks above so you can see a few of the many ways that you could address each one.

1. System too hard to change technically. Too many dependencies. Or [Service Foo] couldn’t handle the volume of requests.
   • We’ll adapt if by the end of the week, Sara’s technical spike suggests dependencies will delay our release by more than 4 weeks
   • We’ll adapt if by the end of the week, Jatin’s technical spike on [service A] shows that it falls over when we make N requests.
   • We’ll adapt if by the end of our first sprint, we haven’t been able to stand up a walking skeleton due to dependencies or third-party services.
2. Tried 3 different solutions but we’d misunderstood something about the underlying problem. Tried the solutions as A/B tests and none of them moved the needle.
   • We’ll adapt if after 6 weeks, we’ve A/B/C/D tested our ideas and nothing changed any of the metrics.
3. Real blocker on another system. Watched customers, talked with customer support team.
   • We’ll adapt if after 3 weeks, we’ve recruited and observed 8 customers trying to complete the task, and more than 3 of them got stuck on another system.
4. Deeper emotional reason to call support. Higher task success rate, same volume of calls. Really clear when we listened in on some support calls.
   • We’ll adapt if by the end of the week, we listen to 20 support call recordings and more than 8 of them point at a deeper issue we hadn’t considered.
   • We’ll adapt if after 2 months, we see a higher task success rate but no change in the volume of support calls.

You may be thinking, “but you said earlier that we can’t predict the future. What if the team has listed the wrong risks or wrong problems there, and something else trips you up?”

That’s absolutely true, but the aim is not to predict the future, only to create space and mechanisms for us to adapt when we learn something more. By doing the spikes and probes we design when we’re writing out the triggers, we enable ourselves to learn things we couldn’t predict. More importantly, we set the expectation that we might learn something that makes us change our minds.

Three buckets of triggers

In the list of potential triggers above, we’ve already got seven, and we could easily come up with plenty more. We can always list too many potential triggers to use, and that’s OK. Next, we’ll choose only the most practical few for us to actually use.

Some of the triggers we listed can be done much more cheaply and quickly than others. Rearrange the list in order of speed and cheapness, and you find there are 3 rough buckets:

1. What we could do before setting the OKR​
   For example, if Sara and Jatin can get the A1 technical spikes done quickly, and we can find an hour to listen to 20 support call recordings (A4), then we’ll be able to use that information to help us decide whether to set this OKR at all.
2. What can be done early enough after setting the OKR that we could still adapt​
   For example, our team intended to recruit and observe customers at some point in the quarter. We often use that kind of testing to improve our execution anyway, so it’s not a big leap to extend it to adapting our OKR. And if we can get it done in the first 3 weeks instead of waiting till later, then we’ll get the information while we still have plenty of time left to use it.
3. What’s too slow or expensive to be practical​
   For example, when we rely on the final metrics we can only get signals when we’ve done all the work and we have no time left to adapt. Good news: we can ignore these.

Your AOKR template

Now we choose 3 or 4 of the most pragmatic and compelling Adaptation triggers. As hinted above, we’re looking to do things that are fast and cheap, or things that we would have to do anyway.

We add these to the OKR we drafted, then tidy up the draft so it’s in a form we can share with colleagues. Now’s when we translate it into suitable language for the narratives in our organisation.

In the example below, I’m channeling orgs where execs love talking about that mythical ‘seamless UX’. You’ll know which buzzwords work where you are.

This draft is now ready to share with execs and colleagues, if we decide to propose this OKR.

Repeat the exercise for your other ideas

Quickly make a map, the pre-mortem, Adaptation triggers, and the AOKR drafting for each of the ideas you’re excited to explore next quarter.

You might find that some ideas overlap and can be combined under one AOKR, or you might end up with a dozen wildly different AOKRs.

You’ll develop a clearer understanding of what could be behind each AOKR and what kind of work it might take.

Share and discuss your chosen AOKRs

Choose which AOKRs you’d like to share. It’s a good idea to narrow down to a small set so you don’t overwhelm the people you’re sharing them with.

Simply by adding Adaptation triggers to your OKRs, you’ll open up different kinds of conversation.

I’ve found that many execs appreciate seeing that you’ve considered what could go wrong. It saves them from feeling like they have to worry about those risks on your behalf. The discussion can move away from who’s doing what by when and into the details of the triggers you’ve set around the conditions and results you’re working on.

Here are some of the discussions that can follow:

Occasionally, you’ll have nailed your AOKR as it stands and your exec will give you the green light. That’s great – you can move ahead, confident that you have a bold, compelling AOKR, and that you’ll be able to change it in the event it proves to be a bad choice.

Sometimes, you’ll find that you’re taking too much of a risk, and the executive would prefer you to tighten up the conditions under which you’d change your AOKR. Maybe they know it’s a very risky bet and they don’t want you to spend a whole quarter if it’s not going to work out.

Other times, you may be asked to change the whole AOKR. It might be that this isn’t what they want you to go after. Fortunately, you’ve already drafted some alternatives, and you can share your maps to show how you’re thinking about what’s possible.

Occasionally, you’ll learn that certain work needs to be done regardless. Perhaps something’s been promised to a partner or as part of something bigger you weren’t aware of. In this case, you can remove the triggers. You might choose to share your map so you can make sure you’ve discussed the risks you perceive before you move forward.

That’s a wrap

If you're frustrated with OKRs, try AOKRs. They're a small addition that lets you set bold objectives while holding them lightly. Try them with your next OKR cycle – I'd love to hear how it goes.

And if you still have questions, or you want to see worked examples of this process packed with tips and tricks, Master Multiverse Mapping is what you need.

If you still have questions, grab a coffee with me and let’s chat.

Tom x

Thank you to

​Corissa Nunn for inimitable editing help, and everyone who’s joined in the discussions around AOKRs, especially David Holl and Thomas Essl.

​

Next in the sequence, we’re going to look at what to do when you’re not really able to choose a clear next objective, as is common when you’re doing very early discovery work – on an innovation team or in a startup.

Here are the promised Multiverse Map instructions

​

​1​

If you’re thinking, “wait a minute, this looks a lot like Pivot Triggers!” then you’re not wrong. This whole exercise is about applying Pivot Triggers to OKRs, as they’re a tried and tested way to open the door to learning and adaptation.

​

£5.00 Buy us a coffee We publish loads of articles, podcasts and videos for free. If you've found what we've shared helpful and you'd like to... Read more Send a tip

​

​