OKRs as strategy debuggers

Small Talk with Allan Kelly

This blog post is the transcription of the chat we had with Allan Kelly about his Writing OKRs Class on 16 July 2024.

The conversation has been slightly edited to better fit the written format. Enjoy!

Avanscoperta: Hello Allan, we're glad you're joining us for this chat about your upcoming Writing OKRs Class. Would you please introduce yourself and then explain OKRs—what they are and what we're talking about?

Allan: There are different ways to answer that question; I never know how to answer it. These days, I help companies become more effective and productive, and I tend to call it modern management in more general terms. Yes, it includes a lot of agile stuff. It also includes OKRs and product thinking, as in thinking about your product more than about your project because products have longevity. I help companies do this, in one way or another.

Once upon a time, I was a former programmer. I got into doing this because I wanted to make life better for the younger me, the former me who'd struggle with meaningless projects and pointless deadlines. I want to make the world better and that's why I do this.

Avanscoperta: We often hear this, "I want to do what the younger me would have liked to know". That's wisdom. So Alan, what are we talking about? This chat is about OKR—Objectives and Key Results.

Allan: The way I like to think about OKRs is that they’re a test-first management tool. The same idea we've been applying in test-driven development, test-first development, on BDD and all that good stuff.

What we're basically saying is,

What is the objective? What is the outcome we're trying to create? What is the change in the world? How do we want things to be different? That's your objective.
It's an outcome you're trying to bring about… and your key results are effectively your tests.

The key results are where you're going to measure whether you've met that objective or not, whether you've got close enough to it, whether you've got fast enough, if you’ve had enough customers, or whatever the characteristics of that objective that you see as valuable and useful. You codify them as key results.
So, in a nutshell, tell me what we're going to do and how you're going to measure it, and you'll get objectives and key results, respectively.

The other thing to say is that we typically do this in 12-week cycles. It doesn't have to be 12 weeks, but it's a great big-time box. When you get to the end of your time box, you do not just roll things over to the next quarter because after that 12 weeks have passed the world is a different place.
You need to sit down and assess the situation, as in we are closer to the outcome we wanted. We may not be all the way there. We may not met all our key results tests, but right now it's the best thing we can do for the next 12 weeks to do more of the things we've been doing for the last 12 weeks. Or is there something else? And we should bank what we've got and focus on something else.

Avanscoperta: I really like the idea of OKRs being a cycle. They're not something that you set in stone once and forever, but rather something that you review—in your example, every 12 weeks. It fits very well with the messy times we’re living in. It’s not like you decided something one year ago and it stays there forever. We need to be adaptable and flexible.

Allan: It's one of life's great conundrums, isn't it? Do you stick with the thing you've decided to do and you bear with it, you keep working hard at it? Or do you dive off in a different direction to do something different?
Both extremes are wrong. It's wrong to keep flogging a dead horse, to keep doing something that won't return. It's also wrong to keep shooting in different directions and not being consistent.

We found that, at the micro level, every two weeks is about the right schedule. What we're saying here is that we've got to step back a bit, think a little bit more long-term, and think about 12 weeks at a time.
In this way, we'll get two perspectives.

Avanscoperta: Let’s talk a bit about the workshop we’re doing together. It’s a 3-hour online class called Writing OKRs. It’s an extremely practical learning experience where folks will experience how to write good measurable OKRs. Who is this for?

Allan: One answer is anybody who needs to set OKRs, anyone who's involved in the OKR-setting process. The most obvious people there are scrum masters, agile coaches, product owners, project managers, and people who consider themselves to have some element of leadership.
However, my approach to OKRs is that I see them as a team-level initiative. Teams should be doing this together, and everybody on the team should have a voice in the OKR setting.

I can quite believe that anybody on a team using OKRs would get value here. The people who are going to be most interested are people who are responsible for those OKRs—responsible for setting and pursuing them, so anyone with any kind of leadership or management title.
I also know this is landing on the plates of many scrum masters and agile coaches, which is certainly how I got into them in the first place. If you're a scrum master or an agile coach, it might be an opportunity to get ahead of the game.

Avanscoperta: I remember one of the profiles or roles we referred to when we first started talking about this with Allan was folks who are somehow victims, those who are forced to use OKRs. What do we mean?

Allan: A few years ago, I knew about OKRs. I'd heard about them. I'd probably even made some talks on them. I was coaching at a company, and we were on a call one morning, and we just got told by a senior person, "Oh, and we want you to add OKRs. We want the teams to do OKRs." On top of everything else they're doing, on top of Scrum, on top of the Spotify model, on top of whatever, "Oh, by the way, can you just do OKRs?"
This was one of my motivations for writing the book. I wanted the book that I wish I'd had that morning.

But the other agile coaches were pretty much in the same position. We all kind of had some understanding, but none of us had done it.
I've joked about this story because it is humorous looking back on it. But it turns out this is an experience that is quite common. Companies have a habit of saying, "Oh, by the way, can you just add OKRs to the mix?" If you ask, "Can you just add barbecue sauce as well?" It's just added in there. It's a bit like that old Dilbert cartoon, where Dilbert says, "Where's my training?" And the manager says, "That was it."

People get dropped in it. And you can survive. It can be a baptism of fire. I myself ran out and bought the books and read the blogs…
But at the same time, it's going to be so much faster and so much more effective for you to spend three hours with us. I like to run the workshop as a practice setting. You can practice setting OKRs in a safe environment, ask questions, and discuss some of the dos and don'ts. I’m just trying to save you six months.

Avanscoperta: Would you recommend that folks come along with their senior colleagues—aka the ones setting OKRs and the ones who have to use them afterwards?

Allan: I would like senior people involved, but

for me, OKRs should be bottom-up. They need to be set by the teams who are going to deliver them. The senior people are going to paint the big picture, some overriding objectives, and goals, and describe where the whole organization is going. But then effectively, they say to the teams, “How can you help?” And the teams reply by saying, “In the next quarter, we will do this”. And they offer the OKRs.

I see that as a feedback loop. The senior people are saying, “Look, our great objective is this,” and the teams are saying, “OK, in the next quarter, we can move that forward.” They offer that up, and they have a consultation, then feedback, and so on.
Senior people might not be in the room, but I think it can help. Similarly, I think an appreciation from those senior people of how OKRs work and what to expect when they've been set.

For example, one mistake often made with OKRs is that they have an objective and then key results that come in afterwards, and they read like a to-do list.

• Objective = build a house.
• Key result 1 = build the foundations.
• Key result 2 = lay some bricks.
• Key result 3 = putting some plumbing.

And that's not how it should be. Too many people expect that.
If you'd like to know more about OKRs, either because you're setting them, or you're going to be reviewing other people's, then please come along.

Avanscoperta: Now that you mentioned this bullet point approach, it reminds me of another workshop we are doing with a person you also know, because he's translating your book "Succeding with OKRs in Agile" into Italian, and he is Francesco Fullone aka Fullo.
As we ask participants for some warm-up questions before the workshop, one of the most common issues is that people think OKRs are just a to-do list of things where the overall picture is not taken into account.
We know it’s not a matter of just completing some tasks, rather everything needs to be connected with the mission and vision of the company and of what we’re trying to achieve in general.

Allan: Indeed it is Key Results, and not Key Things-To-Do!

Avanscoperta: The next question is, why is it so difficult? Crafting and writing some good OKRs, which you can measure in a few months, can be challenging, otherwise, there wouldn’t be workshops and training about it. I'm sure you've seen loads of people getting it wrong.

Allan: There are three reasons.

One is the easiest one to deal with, and it refers to quantification. Key results should have numbers in them; you should be able to quantify them somehow. If you don’t have a number in a key result, it's immediately suspicious.
And it's difficult to quantify a whole bunch of things, and it's difficult to quantify less tangible things. And this is the first issue.

The second one is that it is actually difficult to think yourself into the future and imagine how the world could be different and how you're gonna be able to measure the world being different.
That also means you'll have to talk to people about how the world is going to be different and listen to their points of view.

The third reason why it's difficult is the whole problem of psychological safety.
Imagine setting something that you're going to use to judge yourself. Particularly in an environment where it's not safe to fail, this can be really scary.

So sometimes the issues you're having around this may present as an issue of measurement or as an issue of not really understanding something... but deep down inside, people are just nervous about offering something up which they could be seen to fail at.

Avanscoperta: This leads me to the next question which is about company culture. You just touched on psychological safety. How do OKRs play a role in that? What’s the best setting? How do you suggest people introduce OKRs in a good way if the company culture is somehow wrong?

Allan: You've got two broad approaches here.

You can either say, “Let's make everything right, and then we can infuse OKRs”. And I see the logic in that, I see why people wanna do it, and it's hard to argue with it that we must get A, B, and C already, and then we can infuse OKRs.
However, I suspect you'll be waiting a long time.

The way I prefer to see OKRs now is that

the OKR process is imperfect, and it is not something you do when you have the company culture you want, but it is a mechanism for bringing about a better company culture.

So when you're setting OKRs, and when you start to see that people aren't setting very stretching OKRs, and they're setting safe, achievable OKRs, that's the time to start saying, “Do we want them to be more ambitious, and what would we need to do to make people more ambitious?”

Is it because our reward system isn't aligned? Such as when people get bonuses for meeting some goals, so they all want goals they can meet. Is it because people don't see as though they can speak up?

Seeing OKRs as a mechanism for bringing about changes in the organization, so that the organization is open, is embracing a different point of view, is psychologically safe, is ambitious, does accept that there's always some element of business as usual…

Whatever those issues are, you need to consider OKRs as a mechanism for highlighting those problems, and then you can fix them.
I sometimes go as far as calling OKRs a strategy debugger because, using that feedback process we talked about before, they allow you to discuss the bigger questions.

Avanscoperta: Excellent, thanks Allan. I know a lot of your work has been in the agile field too. So how do the two worlds of OKR and Agile come together?

Allan: It's painful because so often I see OKRs used in a non-agile fashion. If you think about where OKRs came from originally, they grew out of an earlier technique called Management by Objective (MbO), in the 1970s, and some of the literature you see on OKRs is still rooted in the 1970s.

When you look at them, the OKRs people were writing in 1975 are decidedly un-agile. They are decidedly top-down and follow the bullet point approach we’ve discussed earlier (which should be avoided).
And that flies in the face, not just of agile, but of the fact that it's 2024. We have a workforce full of millennials, we are in a post-pandemic world, and people are looking for more control and more meaning in their work.
If you implement OKRs like it's 1975, you won't have that. You'll have a command-and-control MbO system.
I'm sorry to say an awful lot of places deal with OKRs like that.

However, if we accept it's 2024, and we've had the agile revolution, we've got the millennials, we've had the pandemic and we need to enroll people in the way we're working…

And if, instead of considering them as a thing that trickles down from the top, you look at OKRs as something that the teams (and teams are the fundamental unit of work) are using to communicate what they're doing, in an environment where teams are setting their own goals. And indeed the teams should be setting their own goals, their own objectives, such that those goals help their customers, their peers, their senior leaders in the company, such that they all dovetail together with those goals.

Think of it this way: If a manager says, "We're going to do something," the CEO agrees to do something, and then they start instructing everybody at every level on exactly what they have to do, it's a recipe for disaster because the senior people don't know enough detail.

On the other hand, if the senior leader sets out the overarching goals and objectives and asks the people who do the actual work, "How do we move forward? How do you help us move forward?" and the teams reply with their statement, which is their OKRs, then we can compare the two.

We can say, “Oh, the CEO thinks we should be entering the Italian market. Oh, but look, the teams want to translate their products into French. We've got a gap here”. What's going on here? And it could be that somebody is misunderstanding. It could be somebody has information somewhere. It could be the team who said, “We're going to translate to French”, knows that there's a really big French customer about to sign a deal if they do it. And if the CEO doesn't know that, they may well agree.

So, doing it in an agile fashion may be much more collaborative and a feedback process, embracing the feedback you can get here. And as I said right at the start, think of OKR as test-first management.

Avanscoperta: We know OKRs were not invented yesterday, but they’ve become somehow more fashionable lately—as in your example of managers wanting to do OKRs for the sake of it. Are they here to stay? What's the current situation?

Allan: They've been around for a while now. I think they will continue to be around in one form or another. I think they do fill a gap in the agile world. They’ve been very good at low-level, micro-planning, spring situations, even today. Some people have been coming up with ideas for roadmaps and strategies at the other extreme, so I think we've been missing something in the middle.

OKRs are a goal-setting framework. I think goal-setting is going to get bigger, and we need to connect our goals to a purpose.
I think OKRs is about the best goal-setting framework I know of. There may be something better out there. I see every reason that it's going to be around for a good few years yet.

Avanscoperta: Thanks, Allan. As we close this interview, would you please suggest some readings, books, blogs, or videos for our community to continue learning about OKRs?
As mentioned before, you’re the author of Succeeding with OKRs in Agile, soon available in Italian as well.

Allan: Yes, I just received Jeff Gothelf's new book, Who does what by how much? So I'm looking forward to reading it. It's next on my reading list.

Avanscoperta: Thanks Allan and see you at the workshop.

Check out Small Talk on YouTube or Spotify.

Pic by Afif Ramdhasuma on Unsplash.

Learn with Allan Kelly

Allan is the trainer of the Writing OKRs Class, taking place on 31 January 2025 online.

Check out the full list of our upcoming training courses: Avanscoperta Workshops.

Subscribe to our Newsletter 📩 (available in Italian and English) and be the first to know when we schedule a new workshop or we publish a new workshop.