Adaptive OKRs (AOKRs)

Part 3 in the series OKRs sound good but they don't work

Oh hi there! This is part 3 of my OKRs don’t work series, introducing what to do about it, which I’ve called Adaptive OKRs (AOKRs).

• In Part 1, I introduced some social and neurological fundamentals of why OKRs won’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.

• Still to come in future: 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.

---

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.

Often, there’s a moment a month or so into trying to tackle any OKR when you realise that you should’ve set a different OKR. And you would have, if only you’d known then what you know now!

That’s why, with AOKRs, I’ve added just one simple mechanism to OKRs that helps you plan to embrace that moment of realisation so you can change an OKR mid-flight.

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. You’re prompted to discuss what changes could be acceptable, you set yourself up to make a change as soon as you realise you need to, and you can even 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 …

You have to design for adaptation or it won’t happen

Some OKR experts say you should stick to your OKRs once you’ve set them. If you don’t hit them, that’s on you. Try better next quarter. The baked-in assumption is that you should be able to confidently nail down an objective or outcome you want to reach. You experiment, but only with different ways to meet your target.

Needless to say, I don’t agree. In part 2 of this series, we outlined how the nature of the adjacent possible means you mostly can’t choose the right objectives upfront – only with hindsight. It doesn’t matter how much data you review, how smart you are, how many frameworks or models you can bandy about, the truth is that you can’t know today everything that you’ll know 3 months from now.

And sure enough, there are other OKR experts who will tell you, “of course you should adapt your OKRs as you learn more. No need to wait till next quarter.” This sentiment coincides with Gary Klein’s rather lovely concept named Flexecution:

“Flexecution entails changing goals based on discoveries made during execution … we must expect to revise and even replace the goals we initially stated during the planning phase.”

– Flexecution as a Paradigm for Replanning, Part 1 by Gary Klein

This sounds reasonable. Self-evident even? But I think you already know it’s not going to be quite as easy as it sounds. In most companies, making a change to OKRs requires so much energy that it’s more of a last resort than a first port of call. An example:

Let’s imagine you’re half way through the quarter and you’ve got this one OKR you’re working on. I know, only one OKR? Sounds like a dangerous fantasy, but go with it.

(A caveat here: this example assumes that you’re doing OKRs in an Outcomes Over Outputs way. So each OKR is more about Outcomes: ‘a result that would be good to achieve however you can’ and less about Outputs: ‘a checklist of stuff to deliver come hell or high water’. Don’t worry if you mainly have Output OKRs. The example might not resonate, but the principle of making your OKRs adaptive will still apply.)

Next, let’s say you’ve tried your best bets to hit this OKR, but nothing’s made a dent. Through making those bets, you’ve successfully probed your domain and learned about a previously hidden underlying issue that will take longer than a quarter to shift. As discussed in part 2, you’ve realised the Objective isn’t achievable from where you are today, so you need to shift the evolutionary potential of the present first.

You’ve learned that it’s not possible to hit your OKR in the time allotted. And you also know some groundwork that you could start to lay that will resolve the underlying issue and make it possible to hit the original OKR later in the year. Also, through those bets you executed, you’ve unearthed a few alternative opportunities that you might be able to achieve in the time you have left.

This illustrates what Klein is talking about in the Flexecution quote: discoveries you’ve made during execution have shown you that your original Objective (goal) was ill-formed. You couldn’t have known that when you set it, only after working on execution.

So you now have a choice:

• stick with your original OKR. It’s doomed, but it’s what you committed to work towards …

• start laying the groundwork you saw. This is valuable and necessary if you’re ever going to achieve the original OKR, but this work won’t deliver any quick results. It might even look like a bit of a side-quest. And it won’t be ‘done’ by the end of this quarter.

• switch to a new OKR. You could pick one of the alternative opportunities you identified. Any of them might be valuable, but they won’t help with your original Objective. You’d have to set a whole new OKR, which will lead to some awkward conversations.

So, what do you do?

In the idealistic version, you immediately share the situation with your execs and colleagues, set a new OKR, turn on a dime, and set off in your new direction to the sound of fanfares and cheering crowds.

But in the real version, you know you won’t be able to book time in the execs’ calendars for at least 2 weeks. Also, it took more than 3 weeks to negotiate and finalise the original damn OKR in the first place. You’re not keen to go through that again. Anyway, the last time you tried to raise an underlying issue like the one you’ve found, everyone had a bad time. As is so often the case, those execs are on the hook to deliver ‘quick wins’, Nobody ever wants to patiently invest in groundwork until there’s literally no other option.

If you’re like most people, you quietly realise it’ll be less painful all round if you sit on your hands and wait for the next OKR-setting cycle.

In this hypothetical case, you “only” lose a few weeks before the next OKR cycle. That’s not so bad, right?

But the underlying issue that it illustrates is the in-built resistance to learning and adapting at all. In this example, you could try to change course and get the next quarter’s OKRs right. But chances are things will go the same way again. And again.

Once this cycle of guessing and then pretending has happened a few times, you end up with the kind of behaviour I’ve heard about from a lot of people. This is a resigned acceptance that OKRs are pointless bullshit game you just have to play. You pay lip service to them as a kind of ritualistic overhead, but everyone knows that everyone else knows they’re never going to actually deliver results.

Needless to say, this same pattern happens with annual OKRs, as well as on all kinds of longer term projects.

I’ve often talked about a particular longer term project that inspired me to coin the term “zombie initiative”. In this case, two weeks after starting work on the project, the team already had all the evidence they needed to know it was doomed. But this initiative marched on anyway for the full 6 months. It was finally put out of its misery after another 3 months of failure. Nearly 9 months of effort that could have been spent elsewhere. One time I shared this, a former colleague exclaimed, “only 6 months? I thought you were talking about the one I was on – that lasted 2 years!”

This is the default in so many companies I’ve seen, even those that talk a good game about being agile or a culture of experimentation. There’s a lot of nice talk about learning and adapting. But in practice, the teams only have leeway to tinker with the details of how they achieve a fixed objective, never to tinker with the objective itself.

In these companies, the energy cost of changing course is so high that it’s only done once or twice a year, is only the remit of a select few individuals, and is more about political narratives than it is about learning and progress.

Sunk cost bias is a tricksy lil’ beast

Can you add up all the sunk costs in the example I shared?

• 6 weeks of your team literally working on executing bets to tackle the OKR

• before that, 3+ weeks of meetings and documents negotiating the OKR with execs and colleagues

• and before that, an unspecified (large) amount of time before that, when the objective gained ground as something that could earn a place on the roadmap. Several people will have spent lots of time and organisational capital to bring this objective to the forefront and fit it into the current dominant narratives.

Adding all that up, by the time you’ve learned that the objective was ill-formed and you need to adapt it, months of time and energy has already been invested in it. That’s sunk cost for you and your team. It’s also sunk cost for all the execs and colleagues who politicked the objective into narrative dominance.

All this sunk cost can be seen as investment … until failure reframes it as waste. That’s an extremely unpleasant pill to swallow, and not many people want to be the one to deliver the pill. Sunk cost bias is tricky enough when we’re deciding to skip an event that cost us $50. In organisations, with millions of dollars and people’s careers potentially at stake, it’s significantly thornier.

Your situation can be worse yet. If the underlying issue you found challenges the dominant narrative about ‘how we’re going to be successful’, it can trigger a renegotiation of that narrative that many people in your organisation won’t enjoy in the slightest. Through your discovery, you may have thrown shade on the entire strategy. Is that considered part of your remit?

Let’s cut to the chase. You can’t overcome sunk cost bias in the moment.

And that’s where Adaptive OKRs come in …

To mitigate sunk cost bias, build Adaptation triggers into your OKRs from the outset

In most companies I’ve seen, OKRs are typically agreed through abstract conversations. There are meetings within a team, meetings between teams, and meetings with execs.

In these conversations, the framing of objectives is based on each person’s intuitions about what teams can do, how technical systems work, and how customers might respond. All of this is filtered through each person’s perceived risks.

Much confusion and debate ensues because people think they’re talking about the same things when they’re talking at cross purposes, and vice versa. In most conversations, most of us simply don’t realise how big the differences are in our intuitions about the world.

If in your company, you have conversations and nobody ever misunderstands, then you might be able to set AOKRs conversationally.

But I’ve found it valuable to use a more structured approach that un-hides hidden intuitions.

Get real with a Multiverse Map

When I work with teams on setting OKRs, I encourage them to start with a list of ideas they believe make sense to work on next, rather than with possible objectives. This is the ‘start where people are’ approach, as discussed in Part 1.

For each idea, we make a quick Multiverse Map to flesh out the implications.

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, I teach this style of mapping as a workshop and offer it as a service. Get in touch!

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:

Objective
O: Sort out that damn product issue that causes loads of customer support queries, so that we get fewer support queries

Key Results
KR: Weekly support call volume reduced by X%
KR: Y% more customers get through the process?
KR: ? Customer satisfaction increased? (very lagging, can we measure?)

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:

“OK now imagine it’s the end of the quarter and we’ve realised that the objective we set was not possible to achieve. We really wish we’d set a different one. What happened? What made it not possible? And what signals can we see in the world around us that made this clear?”

This provokes fruitful discussion 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:

We’ll adapt if [by date in the future], we’ve gone out and got [a signal that points at the problem we’re concerned about].¹

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.

   1. 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

   2. 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.

   3. 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.

   1. 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.

   1. 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.

   1. 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.

   2. 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.

Sequence the Adaptation 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.

Combine our OKR with Adaptation triggers to make a shareable AOKR

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.

Objective
O: Make the UX seamless, so customers put less strain on our support lines.

Key Results
KR: Weekly support call volume reduced by 10%.
KR: Task success rate for the process increased by 50%.
KR: Average time to complete the process doesn’t change.

Adapt (we agree to change this OKR under any of the following conditions)
A: If by [date], a technical spike suggests that dependencies will add more than 4 weeks of delay.
A: If by [date], we find that [service A] falls over when we make N requests.
A: If by [date], more than 8 out of 20 support call recordings reveal an additional problem that significantly changes our understanding of the issue.
A: If by [date], more than 3 out of 8 usability test participants get derailed by a problem on a system that’s outside our remit.

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 working with OKRs and have been feeling dissatisfied, I hope you’ll give AOKRs a go. They’re a small addition that lets you set bold objectives but hold them more lightly.

If you give AOKRs a go, drop me a line and tell me how you get on.

If you still have questions, or you want to see a worked example of this process packed with tips and tricks, Set Your First Pivot Trigger is what you need.

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

---

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

A card from my deck, Innovation Tactics

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.