OKR’s with Adrian Howard

Join Murray Robinson and Shane Gibson as they discuss objectives and key results with Adrian Howard.

Adrian explains how OKR’s can be used as a strategic instrument for aligning goals within your organisation.  We walk through common pitfalls and misconceptions emphasizing the importance of using OKR’s focused on outcomes rather than outputs. We discuss the potential for using OKR’s with vendors. The idea of paired metrics. And how OKR’s can serve as indicators of underlying problems within your organisations culture and structure.

I’m glad that we’ve finally got somebody on to talk through OKRs. So you talked about this idea of brief versus back brief. Leaders pass down the objectives, their teams will then look at it, they’ll have a conversation about whether they understand it. And then they will suggest key result areas that they think can be used to measure achieving that objective. So that relates to the behavior from mission command. But also it’s that idea that we get some real benefits out of shared understanding, because if the objective goes down and the team go, I don’t understand what you’re talking about, we’ve got a problem and this will help us fix it. allows the leadership team to get feedback because if the key results don’t align with the objective, they know there’s a mismatch and they can fix it.

But there’s some key things that have to be in place. The people have to have the autonomy to shift the indicator. And if they don’t then we’ve got a big problem. They’re just vanity metrics and nothing will happen. 

So this idea of OKR washing where we take our current metrics and our current behavior and we put them through the washing machine to come out nice and clean and shiny as OKRs is something that we need to watch for. We’re not actually changing anything we do. We’ll see an objective of build version two and we’ll see some key result areas of hit milestone one, hit milestone two, hit milestone three, and so that’s changing of the slippers, just lipstick on a pig.

And then the next thing we talked about was, actually, once the OKRs are defined, watch and see if anybody uses it. Because if nobody’s using them, nobody’s talking about them, then something else is at play. It’s like a canary in the mine. It’s provides signals that we’ve got other problems in the organization. 

And then you did a great job of giving us anti patterns. So lack of autonomy from the team to be able to execute lack of the ability to move it. They’re unachievable so they don’t even try and they’re not actually useful for the team. the team don’t get value out of it. Then they’re going to spend less time focusing on it. 

And again, it just reinforced that OKRs are not a cookie cutter formula to follow. Because the thing with it is it sounds simple, right? I have an objective. I have a bunch of key result areas. But that’s not what it’s about. it’s, a behavioral tool for the organization. it’s a tool to give us feedback, to allow us to direct change. 

We’re measuring these things, the dials are moving, but we’re not sure we’re achieving that objective. Wrong measures, Or wrong objective, one of the two. But we need to change something. 

I love the idea that, it’s aligning with the idea of sprint goals. It’s actually the same pattern. Northstar metrics are our long term goal as an organization. And OKRs are a way of setting quarterly goals that move us towards an improvement in that Northstar metric. 

And then we talked about how can KRs be gamified and then you talked about that idea of premortems. Let’s go and say bad things happened. Let’s do that before they happen and then let’s see how we can mitigate them or maybe change the KRs, maybe change the objective. So it’s a strategic tool. It’s not a formula for creating measures and metrics at an individual level. 

And the last one that surprised me was, because they are strategic, they are our objectives as an organization there’ll be teams that don’t have them . 

Read along you will

Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson. 

Murray: and I’m Murray Robinson. 

Adrian: And I’m Adrian Howard. 

Murray: Hi, Adrian. Thanks for coming on.

Adrian: You’re more than welcome. 

Murray: So we want to talk to you about OKRs today. But before we do that, can we get you to give us some background on your experience. Where have you come from and what are you doing these days? 

Adrian: I started off as a developer in the latter half of the last century now. Back in the eighties I got nudged into doing more of what we now call user research, UX and product work as the years went by. And I discovered XP in 99, and from there fell into the early agile world. So I’ve been playing in the messy spaces where strategy research and delivery overlap for about three decades. More recently I’ve done more coaching work and these days I’m focused on coaching senior practitioners and leaders about unblocking their problems and growing their capabilities so they can build effective organizations and great products. 

Murray: All right. 

So what are OKRs? 

Adrian: What are OKRs. They’re a objective that we’re trying to get to. And there’s some way of measuring progress towards that objective. And that’s really it. 

Murray: Well, isn’t that what everybody’s already doing? 

Adrian: Largely not, I guess what I see in many organisations when they start adopting OKRs is that something isn’t right. The organization’s not aligned, different teams are heading off in different directions. People aren’t sure why they’re building stuff, or stuff is getting built and it’s not really having any impact. Then somebody is looking to get A more explicit view of alignment, somebody talks about OKRs as being able to do that and then they try and adopt that and fail miserably. 

Murray: But organizations have missions, visions, and values; three year plans and five year plans. 

Shane: I have posters on the wall. We’re all about the customer Yeah, there’s a great objective. We’re all about the customer. 

Murray: Yeah. So why do they need OKRs as well?

Adrian: I’m always surprised how many companies have, something generic about being customer centric or, the best in our field, which doesn’t actually provide any direction or focus because every company on the planet will have a goal or objective like, that. Nobody wants to be the worst company. Nobody wants fewer customers or very rarely anyway. So you get these generic objectives, which are not useful to help drive an organization in a direction because they don’t let you filter anything out. They don’t let you focus on a particular area.

They don’t provide direction to the team or the organization. OKRs are no different from any other objective setting thing. They’re not magic. What they can do is provide a space for us to have that conversation about what the, company should be doing and how we should be measuring progress towards that 

Shane: So are you often seeing OKRs being the new silver bullet to solve some of those organization problems and that’s why people want to adopt it? 

Adrian: Yeah, I think that happens. We should be doing this thing because it makes things better, without really looking at what problem they’re actually trying to solve with it.

It’s like when people write user stories and think that makes them user centric. They’re copying a pattern that is useful in some contexts, but not understanding the why of it and not using it in a useful way. They see this very simple template, we have A description of what objective we’re trying to do. And we have some measures for making progress on that. And then they take what they were doing before like we want to, deliver version two and it becomes their objective. And then their KRs become milestone one, milestone two, milestone three. And all they’re doing is moving what they were doing before into a new format without changing anything that the organization is trying to achieve. 

Murray: Where do OKRs come from?

Adrian: John Doerr wrote the measure that matters book about OKRs, which I’m not a huge fan of. But it was used at Google. It’s also very similar to management by objectives. It’s not that complicated a concept, we need to write down what we’re trying to do and how we know we’re going to make progress on getting closer to it. The problem with OKRs is when there isn’t a good articulation of what people want to do and, why and the measures of progress they pick are terrible ones. 

Murray: Okay. 

So how should you develop OKRs? Does it start with the executive team? 

Adrian: That kind of question is also what kind of organization are you the kind of process that you have if you’re a one or two team company who’s got a small product or is just starting up? It’s going to be different from if you’re a 10 000 person organization. If you are a large org, little bit of both is what I see. Both top down and bottom up. The exec are going to have, hopefully, a strategy. And that’s often first pain point with people adopting OKRs is that there really isn’t a strongly articulated strategy at the top level. 

Once we have that, then more of a brief and back brief type structure. These are the objectives that we’re trying to achieve and coming back up is these make sense or don’t make sense and also here are options to achieve that. Here are some ways of measuring that. That’s the kind of structure that works well, where coming down from the top is the goals and objectives that we’re trying to achieve. Which is then validated and filtered by the layer underneath and coming back up are, yes, that makes sense, or no, it doesn’t, and this is why. Or here are some other ideas, and also, here are ways to measure progress on those things.

Shane: So that’s got to be one of the key parts of the value is Person goes, here’s our goals, here’s some objectives we think we want to achieve. Goes down to the people doing the work, they go, I don’t understand what the hell you’re talking about. That back and forth conversation until we get clarity. That’s got to be the first part of the value actually agreeing what the objectives are and getting a shared language. Is that right? 

Adrian: Yes. And I think there’s also a level there of do the objectives make sense? Do people have the autonomy to achieve those things? That is something that can come up in those very early conversations, especially in organizations that haven’t had a strongly articulated strategy before. It becomes a forcing function for both saying, this is what the strategy is. And can we actually do these things? Is there a way to give elements of this goal to other bits of the organization? Do we have a structure there and teams that can deliver on these things? 

Shane: So have you ever seen it where the conversation around the objectives helps create the strategy? Or does the strategy actually have to be in place, otherwise you’re just wasting your time?

Adrian: Yes and no. Yes, I have seen it. The no is it’s very easy to just take the template and fill it in with stuff that’s already there. One of my common red flags with coming into an org that’s just adopted OKRs is to discover that they’ve taken everything that they were measuring or trying to do before and call it an OKR. Every goal and objective from delivery stuff. Someone’s turned the, God help me velocity goals or something like that Into an OKR at the same time someone at the top has put we will make these much sales into an OKR and we will have this many new conversions into an OKR. So you’ve got dozens and dozens of goals. It’s not a strategy. It’s just a list of things we’re measuring. It doesn’t automatically make that conversation happen but if we’re having a more facilitated and focused conversation or we’re trying to set a clear strategy and deploy it to the rest of the organization so they can understand what we’re trying to do. Then you know that you’re trying to do like one maybe two or three big things, at the highest level. So what are we actually trying to do? And then facilitate a conversation about strategy and ways to measure that and ways it can go wrong. And then that slot can be a huge focusing tool.

Murray: So, are OKRs something you do in addition to your standard revenue targets and cost targets. 

Adrian: Yes. Revenue and cost targets are a way of measuring progress. They’re not goals in of themselves. Every organization wants more money and more customers generally. The key question is how do we do that? So the goal isn’t the money. The goal isn’t the number of customers. The goal is we’re doing a thing. To get those things. So , that’s the conversation we need to have. What is our strategy? Are we building a new product line? Are we expanding into a new market? Are we trying to grow our existing customers? Are we trying to take this customer segment that grows into really valuable customers and get them early before our competitors do? What’s our actual strategy rather than what is the amount of money we want to get out of it in the end?

Murray: So I’ve been in a executive team that did quarterly planning and it started by getting everybody to brainstorm ideas for goals for next quarter. But there would be like 50 things come up. And then there was a debate, which took the first day, around what are the most important. How would you recommend that people work out, out of their 50 or 100 possible OKRs, which are the ones that they should do? 

Adrian: When people have 50 or a hundred things, it’s a sign that they’re not thinking about this stuff the rest of the time. We have all these wonderful incremental approaches to work at the delivery level, But we’re often not doing that work at the strategy and the planning level in the organization. If you do that work regularly, you don’t have 50 or 100 things, you have 5 or 6, and you’ve already had a conversation throughout the rest of the, previous quarter about, the most likely thing to come up. Everyone’s already in a place where you’ve got half a dozen things, and you can have a deeper conversation about that stuff. When you’ve got 50 or 60 things you’re often coming from a, place where you’ve not had that conversation before, which means it’s harder to both , bring up evidence for that because you’ve not been thinking about it much. And also it’s hard to judge the value of those things because you’ve not been thinking about the things much in the previous, few months. So the thing to accept there is that your first run through you’re almost certainly going to make mistakes. And this is one of the things that causes people pain when they’re adopting an OKR strategy or having that first run of monthly planning, that they’ll pick up three of those things to do and two out of those three will fail miserably, and that makes it harder to make progress. But once you’ve gone through that two or three times evidence will build up and then you can start making a decision from a smaller subset of more valuable things.

Shane: So the other behavior I often see is, everybody goes yeah, those are our most important things and then they walk back to their desk and they tell the team to carry on the 35 other things that weren’t on the wall that they think are important. So how do you stop them, going and doing every other thing and not focusing on the things everybody supposedly decided was important.

Adrian: If we have the OKRs I like to encourage people towatch and see whether people take any notice of them. Do people actually use these things? Because if people don’t use these things, if they’re not valuable and useful there’s some other incentive or habit in play. There is some operations officer who is fanatical about velocity numbers. And so the entire dev team is focused on making sure a certain number of tickets get done every day, rather than achieving something valuable for the company. And if you look at that and if you see people aren’t using the OKR’s you can start asking yourselves why. Sometimes that why is there’s something that’s getting in the way. Sometimes the team doesn’t have autonomy to achieve that thing. Sometimes, the objective doesn’t make any sense. the team has knowledge or the department or the group has knowledge that says, that, they’re asking us to do something really stupid and we’re just going to do our own thing instead. Sometimes there’s a lack of understanding on how to achieve that thing, and those are the things you can start using to improve the organization. The dev team want to deliver new mobile apps, but nobody actually wants one. Is that an issue? Do we have the wrong people here doing this work? Or are we making a goal that’s completely unachievable? And so no one wants to try because they know they’re going to fail. And those are problems we can start solving. 

Murray: So what about this idea that OKRs should be audacious goals? 

Adrian: That’s fantastic. If you have an organization that doesn’t punish people for not achieving audacious goals. This is a really common anti pattern that I see is when an OKR, fails, where we don’t meet the level of progress that we set as goals for our OKRs, then somebody goes you’ve been a very bad team who hasn’t worked hard enough. Try better next time and we’re not going to give you a bonus. We’re going to fire your product manager. Maybe the objective was a dumb objective and so we couldn’t achieve it. Sometimes, the key results, the metrics we decided to use to set progress were dumb metrics and we couldn’t achieve them. And maybe we did something better somewhere else that met the objective but it didn’t actually deliver on the OKR’s. Maybe the strategy above all these objectives was wrong. Nobody listens to the feedback the OKR is supposed to be giving you. 

Murray: Should an OKR be something like, we’re going to release this software on this date? 

Adrian: Most of the time, something like that is a red flag. Why are we releasing the software is a much more interesting question to be asking There was a team I worked with who, were trying to get rid of a data center. They had a bunch of computing that was happening , in a physical room with lots of servers that was very expensive and they were not being utilized very well. And so they needed to shift this stuff into a cloud. What the organization cared about was we spend a lot of money on this big room full of servers and all the people we need to keep them running and we don’t want to do that anymore. And so they had the objective of please shut this down. But the way they were measuring progress on that wasn’t on we have delivered all the features for our data migration. They were measuring number of customers on the new cloud service who’d started using it. Number of customers who had stopped using the old service. The number of data streams that were on the new service and the amount of data running through the system that was on the new service. So nothing about features, nothing about services migrated. Two of those things were just around the customers and they were really valuable because they let let the teams that were doing the migration steer. So they could ask questions like, in month one, we’ve got this chunk of customers have started using the service, but haven’t stopped using the old service. Why is that? Oh, look. There’s this bunch of little services that are key to these customers migrating. We should prioritize those. Oh look, there are customers who haven’t started migrating yet. Why is this? Oh yes, there’s this chunk of services. We can build a DSL to handle the migration of that across to the new system. And because they had, rather than a date, they had a relatively audacious objective of migrating all these people across the service and a way of measuring progress to that and an understanding of how that was serving the higher level company goal they could be asking lots of intelligent questions about what’s the next thing we should be doing? Should we be focusing on this valuable customer or on this bulk of lower value customers? And they could go talk to product managers about that and ask intelligent questions because they understood what the objective was. So they met that and it was fairly audacious, but it wasn’t because there was a date on there. It was because the objective gave them a good goal. And the KRs help them every time they ran a retro and a planning session to talk about, okay, this is the thing we’re trying to do. How does the work we’re doing now help us get there?

Murray: This sounds a lot like mission Command.

Adrian: Yes, it’s exactly that. 

Murray: Particularly with the briefing down and then briefing back up. We talked to, Stephen Bungay on one of our podcasts who wrote a book about this. He always did it at the executive level, maybe two levels down, but I think we’re talking with OKRs at going further down in the organization aren’t we?

Adrian: It can depend a lot on the organization and the kind of things it’s trying to achieve. Not everything needs an OKR. If you’re running your HR department, is there something in there that’s directly related to the organizational strategy? Sometimes there is, and sometimes there isn’t maybe an OKR isn’t needed there. 

Shane: So there must be a natural tendency for everybody to treat OKRs as the old KPIs and so we just, switch the three letter acronym for KPI to become OKR. And retrofit the way we’ve always worked with this new term. But that idea that not everybody needs an OKR is the key. If everybody has one, it’s an indication that we’ve just taken the KPIs of old and retrofitted them with a new three letter acronym.

Adrian: The Biggest value I’ve seen from OQRs is when they’re used as a form of strategy deployment, This is what the organization is trying to do. Let’s make sure everybody understands how we’re measuring progress on that strategy so we can all be heading in the right direction. And you can’t have 30 different strategies. You have a strategy and that might be broken down hierarchically in some way, and there are lots of different battles, but the idea is to win the war, that’s the thing we’re trying to do. OKR’s should be giving focus. They should be serving a larger goal. 

Murray: Should they be giving autonomy and delegation as well? 

Adrian: A useful pattern that I’ve seen is higher ups set objectives, but they don’t set the KRs. The people doing the work set the key results, the metrics we’re going to use to track success. So with that team, the organization had the goal of, we want to shift everything from on site servers to being in the cloud.

And the team were the ones, okay, we’re going to measure it like this. Is that okay? We’re going to have these goals for the next six months, We’re going to track it like this. And then there was some back and forth until they decided on those four metrics. So that provides a nice, layer of conversation about the the briefing and back briefing. We’re telling you, okay, we can’t do that, or this is how we’re going to measure progress on that. And then the organization can go Ooh, That doesn’t measure what we thought it measured, or what about this other thing? And it allows, a nice natural set of things to talk about. 

Shane: I get the impression that the team Time horizons for an objective are typically a quarter. Is that right? 

Adrian: I’ve seen stuff both be shorter and longer most people talk about quarterly objectives. I’ve seen people had stuff that’s been a little bit shorter, six weeks, that sort of range. Sometimes if you’re an org, which has a fairly stable strategy, then that might be, longer, might be six months or a year, even.

Murray: So should they be cross functional or should each department and project have OKR’s 

Adrian: It depends. The group that has the OKR needs to have autonomy to deliver on that thing. And what I look for is alignment rather than this concept of a hierarchical cascade. Is the OKR for our group aligned with the goals we’re trying to achieve for the organization? 

Let me give an example. An org had a customer retention and customer satisfaction problem. the product worked but it was buggy. The big organization goal was we want our customer satisfaction numbers and our retention numbers to go up. And our big objective was, we want our customers happy and using our product, and this is how we’re going to measure it. And there was stuff happening, on the dev side around QA, because that was a big issue with buggy stuff being shipped. You had a dev team that had an OKR around making QA better. They had various ways of measuring that. You had the UX group with a couple of OKRs around better usability testing with the dev team and delivering a design system to help them. All of those things were aligned on the organizational goal of better customer satisfaction, more money because we can retain our customers better and they’re going to be happier with our product.

Murray: Can I ask you about a few things that people on Reddit are saying about OKRs? 

Adrian: Sure. 

Murray: So, first thing people saying it doesn’t matter. It’s all so vague and high level. There’s no measures, it doesn’t mean anything to me.

Adrian: Yes,don’t get me wrong. I’m always going to say these things absolutely happen. Like the adoption of any practice, 90 percent of people do it poorly. So yes, that absolutely happens. That’s a sign of a terrible OKR. if the KRs aren’t measurable and useful, that kind of misses that fundamental definition of what they’re about. They should be a measure we can use to track our success or failure and progress on our objective. If they’re woolly, then they’re not meeting those goals. If they’re too high level, then the team can’t act on it, so it’s not a useful objective for them. 

This comes back to the thing I said before, If an organization has OKRs but they’re not being used, that’s a fantastic signal. Start looking at that to discover why aren’t they being used. Are they not being used because the OKR is bad? Are they not being used because the team can’t act on them. Are they not used because the things that the OKR tells them aren’t useful to the team? 

Go look at that and find out. It’s hard to do from the team level often because if they’re not the one setting the OKR, then that’s, another thing to look at is was there that conversation between the team and whoever set the OKR about this is how we’re going to track progress.

Murray: So here’s, another one. We’ve got 400 features in our project backlog Our objective is to do these 100 in the first quarter, these 200 in the second quarter, these 300 in the third quarter. Those are OKRs 

Adrian: Yeah. 

That’s a sucky OKR. It doesn’t give you any reason to do those things. It doesn’t give you any information on which of those 400 things are the most important. And why we’re doing them That doesn’t let them ask smart questions. And doesn’t give them good feedback on what should their next action be. 

Murray: The other thing I see people complaining about is that they get asked to achieve this OKR, but they haven’t been given any time or money or resources to do it. So it’s just a way of trying to get them to do extra work.

Adrian: Again, this absolutely happens. And it’s a very strange way of running an organization because that is fundamentally saying is that there, there’s a chunk of work that we’re telling you to do that is important by setting an OKR on it. And there’s also another chunk of work that is valuable to the organization, which is the work that you’re already doing. And we’re not going to give you any useful guidance on which of those two things is more important. This absolutely happens. And sometimes it’s management trying to get money for nothing.

Sometimes it’s the dev team, has a terrible idea about what’s providing value to the organization. 

Like one org I worked with, this mobile app existed basically because the CTO liked mobile apps and thought delivering them would be cool. But it wasn’t providing value to the organization. It wasn’t getting them more sales from their main product line. What it was doing was sucking up three dev teams worth of resources for no real value or money.

And the problem there wasn’t that the objectives weren’t aligned with what the team was doing. The problem was the team was doing stuff that wasn’t of any value to the organization. That was a C level problem Between the CTO and other bits of the organization But the objective helped highlight that. 

Murray: Yeah, we’ve talked about outcomes over outputs a lot on our podcast. And delegating goals down and then empowering people to make decisions to achieve them. But what actually happens everywhere is that everybody, particularly in IT is very focused on deliverables all the time, not outcomes.

Shane: They run off keeping busy, but not achieving anything.

Adrian: Some of that is habit Some of that is what have I been praised for in the past, sometimes it’s what’s easy to measure. And outputs can be really easy to measure. 

Two of my favorite tricks with people are measuring weird things. Is there an expiration date on this metric? When will we reassess it? Why we measuring this thing? What value is it delivering? Why are we measuring code coverage? Because we’re shipping buggy code so we want our bug count to go down, or we want our custom satisfaction to go up. But we can have that conversation about what outcome they’re trying to achieve by digging into why they want to measure that thing. 

Murray: This feels like it links up very nicely with sprint goals. 

Adrian: Yes, it absolutely does. If folk are scrum shop where they’re doing sprint goals, they’re looking to the OKRs. Our sprint goal is, all the time, we’re going to deliver to try and move the OKR numbers. 

Murray: Also, a lot of the product people like Marty Kagan are all talking about outcome focused product goals. there’s a really big movement across the whole industry to do outcome focused goals, although companies still not doing them. 

Adrian: Yeah, and it’s one of those things that keeps coming up and has come up , repeatedly over many decades. As you were talking about, Bungae stuff earlier, we’ve had management by objective many years ago. All these things have been around for a long time. 

And that tells us however useful they are, there are obviously pressures in organizations that push it back to not measuring outcomes and looking to goals, but, measuring outputs and looking for things that are easy to measure. So you need to look at the blockers and understand why that is happening. 

Shane: So we talked about measurement a bit and you’ve used the word evidence quite a lot so far. So what do you mean by evidence when you use that term. 

Adrian: When it comes to the KRs what I’m looking for is, what can we use to, measure progress on the objective that we’re trying to achieve. And what I’ll often see is those output based things that we talked about earlier, like the set of milestones for a delivery release. Now, that is not letting us measure progress on something the company cares about. If the new software is released on time and nobody uses it, that’s not a success. So what thing can we look for that’s gonna let us know that yes, we are making progress on that objective. And yes, we are succeeding, but we are failing on that thing. Like for example, one that I often see is to get a whole bunch of new customers. That’s our big goal for the next year. And there’s usually a dumb way of doing that. You can get a lot new customers by giving accounts away for free or dropping our prices by 20 percent. And yes, that does get you more customers, but it doesn’t get you more money and they’re just going to stop using you once, you start charging the proper price. 

So what you’re looking for is a better goal and a better way of measuring progress on that goal.

Shane: Yeah, I remember in a many previous lives ago, I used to work for a enterprise sales software company. And they rebuilt their product. And all the account reps had KPIs for a number of new licenses sold. So what they did was every time they sold an old license, they bundled in all the new licenses for free. So the KPI of more , new widgets sold in theory was met, but the objective of getting everybody, off the old software wasn’t. So I can see that behavior happening a lot.

Murray: Yeah, I worked for a digital agency where the CEO and COO decided they wanted to grow the organization by 30 percent and the way they would measure that was by how, many staff they had. Because then the staff would bill and then the money would come, But the big problem was that their recruitment process was too slow. So I helped them streamline their recruitment process and they recruited all these extra staff. They had nothing to do because they hadn’t sold their services. So they were screwed and they had to fire a lot of them again. 

Adrian: Yeah. I love using a practice called pre mortems where you’re ask yourself we’ve delivered on this thing, but it’s all gone horribly wrong. How could it have gone horribly wrong? Which can help surface lots of risks, but you can prompt with metrics and outcomes so if our objective is we want to grow into this market and our measure is we’ve acquired more customers. How can we have acquired more customers and it still be a miserable failure? So prompt it with the metric. If our churn rate has gone up really high we should probably look at that at the same time as we’re looking at those other numbers. And that can help you find paired metrics that will give you clues that while you’re delivering on one thing, you’re failing on another. 

Shane: So that’s called pair key result areas, is it? 

Adrian: I don’t know if it has a name, but Christina Woodkey, in her excellent book on OKRs, her Radical Focus book, she talks about healthcare metrics. These are the numbers you don’t want to change while you’re messing with other stuff. So they’re things you want to keep an eye on. What other metric will change if the thing that we’re trying to do succeeds, but our objective is failing, and those can be useful things to look for. 

Murray: I like that approach of having multiple key results for an OKR, including some that will show you if you’re going horribly wrong. So if your objective is to increase revenue by 30%, then you should have a OKR in there that says profit will also increase by 30% not reduce by 100 percent. 

Shane: Yeah, I love metrics. I did some work for one of the forces around training. So they had to, do a certain number of training exercises in a certain period of time, and one of the measures was nobody was allowed to die. But, I don’t think they ever wrote down what was the objective of what those measures were measuring.

Adrian: Yeah. That’s another thing that I see happening a lot with organizations. Everyone assumes that everybody knows the goal and the strategy . So nobody says it out loud. So that people start delivering on a metric that’s around that, but without understanding the objective, they wander off course. And sometimes there isn’t alignment, there’s just the assumption of alignment. I worked with an organization where everyone was talking about this new thing that they were going to ship. And I never quite understood exactly what it was trying to do . And when we got everyone in the same room and we did a pre mortem thing about what we expect to see in six months time, if we did it this thing, and we got about 40 different things off that list, cause there was massive misalignment and miscommunication in this fairly senior group of people about what this new thing was supposed to be. Some people were seeing it as a driver for organizational change. Some people were seeing it as a technical test around some complicated stuff. Some were expecting so many million dollars worth of revenue in Q4, and these things were contradictory, and it wasn’t until everyone was in the same room and wasn’t talking about the delivery timeline and the features and things, and talking about what do we expect to get out of this, that there was a sudden, oh shit, we’re trying to do different things.

Murray: It’s very common that people don’t measure outcomes. Why do you think that is? 

Adrian: Because outputs are often easier to measure and they’re more unambiguous. I have, delivered the mobile app is a yes or no thing. So I’ve done my job, I’ve delivered the mobile app. And you don’t have to have a complicated argument about was it actually any good? And did anyone use it? And did people find it valuable? And has it delivered longer term value to the company? Both the people delivering the app and the exec team can avoid asking the difficult question about was that a good idea and did we do it well?

Murray: Then you can avoid responsibility, can’t you? Because you can say I did my bit. Big success. Let’s just move on. 

Adrian: Exactly. And it applies the other way around as well. We did deliver a mobile app, but it’s the team’s fault for not delivering a good mobile app. And that’s why the strategy failed rather than mobile app was a dumb idea in this context. 

Murray: Have you ever seen anybody use OKRs with vendors successfully? 

Adrian: What, for giving them to a vendor? 

Murray: Yeah so for example, we’re going to engage a vendor, we’ve got so much money, so much time, our goal is to develop this change to the system to increase conversion rate. Your job is to work with us to increase the conversion rate as much as possible within that time and budget. That seems like something you could do.

Adrian: I’ve not seen that situation. I can certainly imagine it happening. This is the objective. How would you measure success on that to the vendor and get the vendor to propose some KRs and have that conversation

Shane: So one of the projects that we did when we pitched when I was at a software and analytics company was, fraud detection with insurance policies and claims. And so they’d go to a large insurance company and go, we’re very good at doing fraud detection. We will, reduce your cases of fraud and increased recovery of that money. And we will take a percentage of everything that we recover. And 9 times out of ten, the company would go, no. Eight times out of 10, they’d actually pay the organization to do the work on an hour’s basis. This was a vendor saying, here’s an objective, and we’re going to achieve that objective, and we’ll both make money out of it. That’s fair. And yet the organization went back to effort. No, just bill me hours. I don’t know whether it was they didn’t want to revenue share it or they didn’t want to disclose the numbers. But it seemed weird because it was a clear objective and it was measurable. But that behavior does happen.

Adrian: I find those situations interesting because what you have there is the search for objectives and measures. Ages ago, I worked with an organization that was selling a usage based service. We went out and talked to a bunch of their customers and some feedback we got from several of their most valuable customers was can we just give you a large amount of money every month, rather than being charged for usage, because with the way our organization works, if we charge for usage, we’ve got to validate that the usage is correct, which involves a load of work, which we’d rather not do. We’re getting lots of value from this. Can we just pay you a bit more, but it’d be the same amount every month. That’s going to be great. To me, some of your most valuable customers want to give you more money. Say yes. And the organization didn’t because the people who’d founded the company thought that we are fair And we charge people for what they use and this was a just a core value for them but because they had this value system, they were going to say no to it. Once you understand that you can work with it and figure out what to do, but the fact that it’s being blocked, that’s a great thing to ask questions about. 

Murray: I think we better go to summaries, do you want to kick us off?

Shane: I’m glad that we’ve finally got somebody on to talk through OKRs. So you talked about this idea of brief versus back brief. Leaders pass down the objectives, their teams will then look at it, they’ll have a conversation about whether they understand it. And then they will suggest key result areas that they think can be used to measure achieving that objective. So that relates to the behavior from mission command. But also it’s that idea that we get some real benefits out of shared understanding, because if the objective goes down and the team go, I don’t understand what you’re talking about, we’ve got a problem and this will help us fix it. allows the leadership team to get feedback because if the key results don’t align with the objective, they know there’s a mismatch and they can fix it.

But there’s some key things that have to be in place. The people have to have the autonomy to shift the indicator. And if they don’t then we’ve got a big problem. They’re just vanity metrics and nothing will happen. 

So this idea of OKR washing where we take our current metrics and our current behavior and we put them through the washing machine to come out nice and clean and shiny as OKRs is something that we need to watch for. We’re not actually changing anything we do. We’ll see an objective of build version two and we’ll see some key result areas of hit milestone one, hit milestone two, hit milestone three, and so that’s changing of the slippers, just lipstick on a pig.

And then the next thing we talked about was, actually, once the OKRs are defined, watch and see if anybody uses it. Because if nobody’s using them, nobody’s talking about them, then something else is at play. It’s like a canary in the mine. It’s provides signals that we’ve got other problems in the organization. 

And then you did a great job of giving us anti patterns. So lack of autonomy from the team to be able to execute lack of the ability to move it. They’re unachievable so they don’t even try and they’re not actually useful for the team. the team don’t get value out of it. Then they’re going to spend less time focusing on it. 

And again, it just reinforced that OKRs are not a cookie cutter formula to follow. Because the thing with it is it sounds simple, right? I have an objective. I have a bunch of key result areas. But that’s not what it’s about. it’s, a behavioral tool for the organization. it’s a tool to give us feedback, to allow us to direct change. 

We’re measuring these things, the dials are moving, but we’re not sure we’re achieving that objective. Wrong measures, Or wrong objective, one of the two. But we need to change something. 

I love the idea that, it’s aligning with the idea of sprint goals. It’s actually the same pattern. Northstar metrics are our long term goal as an organization. And OKRs are a way of setting quarterly goals that move us towards an improvement in that Northstar metric. 

And then we talked about how can KRs be gamified and then you talked about that idea of premortems. Let’s go and say bad things happened. Let’s do that before they happen and then let’s see how we can mitigate them or maybe change the KRs, maybe change the objective. So it’s a strategic tool. It’s not a formula for creating measures and metrics at an individual level. 

And the last one that surprised me was, because they are strategic, they are our objectives as an organization there’ll be teams that don’t have them . 

Murray, what do you got? 

Murray: Yeah, I thinkOKR’Rs are a version of mission command They’ve come from, Peter Drucker with Management by Objectives. And they’re a way of focusing the organization on achieving some goal. So, take that hill. Why? Because of all these reasons, and then you can discuss it.

It’s not necessarily a problem if you don’t achieve an OKR or an objective, because these are things that you’re, not sure that you’re going to achieve. These are changes you want to make. You’re going to come up with some measures and if you don’t achieve them all, that’s fine. As long as you get partway there, that’s good. Or if they’re not achievable, then you can think about it again. 

It all seems terribly obvious. I think the, problem with it is that there’s so many ways it can go wrong, mainly because of the way, organizations bureaucratize everything. There’s no resources to work on the OKR, the measures are never done, they get turned into individual KPIs or they just take the existing KPIs and rename them.

So there’s many ways that , they can go wrong. I think when they done right, they make a lot of sense. It aligns with everything we’ve been talking about for, the last couple of years, which is all about outcomes for customers and users in the business, not about outputs, not about deliverables. So OKR’s should not be about deliverables. 

I think it’s good. It ties a lot of things together. It ties very nicely with product goals and sprint goals and roadmap based, product goals. Instead of a product roadmap that has a long list of features you. Have a series of goals each quarter. 

Adrian: Yeah, all these things are doing very similar things and whichever brand you pick, I don’t particularly care. But having it be there and the organization being aligned on it is the most important thing. 

Murray: yeah, and it’s nice to hear stories from you of it actually working because I think it goes wrong quite easily But then you know management always taking these sort of things and making them wrong. So it’s a more fundamental problem Anything else you want to add Adrian we haven’t touched on? 

Adrian: Just in the brief back brief thing. 

Another anti pattern that I see, is objectives always coming from the top down. The people closest to the work see the most and those people and those teams will be seeing things in the world that the customers need or want, or there’s this big problem.

So as well as there being large organization goals coming down, there should be things flowing up from the teams going, Hey, we’ve seen these problems and should we be doing this? And that cycle should be going on all the time. Successful organizations are rarely the clever exec saying, this is the direction we’ll go in. It’s an organization that listens to the problems that the people on the ground are telling them about and helps filter and prioritize those into a direction. 

Murray: Yeah, I think that’s very important. 

So now where can people read about this. I see you’ve got a mind the product article called how to write OKRs that don’t suck 

Adrian: Yeah, that’s a good place to start. There’s a more up to date version of that on my website at quietstars. com slash lax2020. Which I think covers a lot of what we talked about. For being in contact with me we’ve got a free newsletter on QuietStars. com. I also blog occasionally on AdrianHoward. com. And all the usual places, LinkedIn I’m Adrian H. 

Murray: And what are the books you recommend on OKRs? 

Adrian: Top of the list by quite some way would be Christina Woodkey’s Radical Focus. She does an excellent job showing some of the challenges , people have adopting OKRs, both in the why we need to do it and where it goes wrong. It’s one of those books like the Goal, which has a bit of a business story at the top and then the back half of the book is talking about techniques and practices. And that’s by far the most useful one because it talks about the problems and pain points. 

The one people always recommend is the the Measure What Matters book. I have some issues with that. it’s talks more about output stuff and performance measuring stuff which doesn’t quite align with my experiences. If you’re going to read one book, Woodkey’s Radical Focus book.

Murray: Great Thanks for coming on

Adrian: You’re more than welcome. Thank you for having me.

Murray: That was the No Nonsense Agile Podcast from Murray Robinson and Shane Gibson. If you’d like help to create high value digital products and services, contact murray at evolve. co. That’s evolve with a zero. Thanks for listening.