Many organizations are having trouble rolling out OKRs or objectives and key results, especially when top leaders overreach into the planning process using OKRs to bludgeon their favorite project or feature into the plan. Dr. Mik Kersten, Founder and CEO of Tasktop, talked at the recent DevOps Enterprise Summit about his seven years of experience using OKRs and what he’s seen go right and wrong in large complex organizations. You can watch his full presentation here.

I’ve now had eight years of experience managing my own company with OKRs. I’ve noticed that over the past, especially the past few months, as DevOps has become a CEO, an executive suite, and a boardroom topic, and as the shift from project to product has really helped more organizations focus on technology and understand how to start innovating, how to start measuring and tracking for value, that OKRs has become a really key topic. Some organizations are using OKRs very effectively to better understand how to connect technology and business and deliver more for their customers. Whereas others are failing in what to me are very surprising ways.

The Basics of OKRs    

So let me quickly talk to you about what I’ve learned within my company, supporting other organizations who are using this methodology, and then how you can apply some of these lessons to your own initiatives. 

First of all, objectives and key results (OKRs) are just one way of tracking plans and goals. Some of these concepts will apply to other ways that you’re measuring value, but we’re going to dig in specifically to OKRs.  

The objectives are the what. These inform actions. They’re really about finding a way of measuring value, how much we’re delivering for our customers, our market, our colleagues. 

The KRs, the key results, are the benchmarks for how we’re doing that, how we’re delivering value. 

The point of OKRs is that you have around three to five. And they have a self-only factor in how they cascade spread across the organization. They’re really summarized very well by John Doerr’s book, Measure What Matters. I’ve actually been applying them for years so it was very helpful for me to see this book. I had my whole leadership team read it, but I found that with this book there was a really significant gap, which is where a lot of the deployments of OKRs fall into. 

That gap is the how, how do we measure value for software delivery? Because if we don’t have a consistent and clear way of measuring value, then what happens if we start measuring the wrong things? If we measure the wrong things, we often get into these pitfalls of actually slowing down our teams of inspecting at the wrong levels. Of cascading far too low. Of mucking and micromanaging where we shouldn’t be.

Use Flow to Direct OKRs

In Project to Product, I introduced the Flow Framework. The Flow Framework was really meant to capture a way of measuring flow, and connecting that to these business results. Flow metrics are a way of measuring key results related to flow, related to how we’re delivering value for our customers. Then we combine those with the business objectives around the other financial metrics and all the other metrics in the organization. 

I’ll show you how we can combine these things and have them work effectively. And how in the end it really is all about making sure that you include flow metrics in your key results in order to connect business and technology.

So, why flow? I think in recent news we’ve had really interesting examples of why flow is so important, how problematic bottlenecks can be. We saw the entire shipping industry grind to a halt because the Suez Canal became a bottleneck. When we have this kind of bottleneck, the entire system slows down. There’ve been amazing visualizations that show how it wasn’t just the ships around the canal, but the global shipping system that ground to a halt. And yet we’re seeing these kinds of things all over organizations. And the question is, are we actually seeing them and improving them or not?

I think if we take as leaders of teams, of organizations, of value streams, if we take our job as improving flow, adding and really focusing in on that Second Ideal of focus, flow, and joy for all our staff, all our colleagues, and for what we deliver to our customers, then we need to know where our bottlenecks are. As Gene Kim channeled in The Phoenix Project, “Any improvement made anywhere besides the bottleneck is actually an illusion.” If we’re investing anywhere other than the bottleneck, we’re not helping flow, we’re not helping that focus, or that joy. 

How OKRs Go Wrong 

OKRs can be a really effective tool for speeding up flow, for changing organizational conditions, and investing in bottlenecks. But I’ve also found a lot of colleagues and large organizations who have been deploying OKRs have been finding they are actually slowing them down. 

These are some of the key problematic things that I’ve seen.

First of all, OKRs are being used for micro-managing teams and value streams. Rather than sending teams directions, and paths, and really helping everyone navigate toward that common goal, they’re actually being used to track specific features, muck with roadmaps, and reprioritize things for people. If that’s what’s happening, we’re actually reintroducing waterfall planning into our DevOps transformations and our agile processes, which is antithetical to the goal of why we’re all here.

The second pitfall I’ve seen is organizations using business and financial metrics as the only key result. What will often happen is a financial metric, such as a cost metric or a revenue metric, will get quite divorced from what a team is doing. You might have a platform team creating a new cloud infrastructure, ramping up a whole lot of SREs who might not map directly into a revenue metric, but it’s still going to help the organization succeed and will eventually drive to faster revenues and more market leadership.

The third key pitfall is using only team or proxy metrics as the key results. Teams have a lot of detailed metrics, a lot of different KPIs that they need to use. They have a lot proxy metrics that are not metrics of value of flow but are very specific to the team’s work and can really derail OKR efforts. 

These practices of using OKRs for something they weren’t intended for, for not measuring value, result in conditions that make OKRs work against you. They make you feel like things are slowing down, which means chances are they are slowing you and your teams down. 

Where Do Bad OKRs Come From

So let’s look at where bad OKRs really come from and what they do. In this specific value stream there’s a pretty significant bottleneck in it. A lot of features and other flow items are trying to get through, but they’re not getting through. What will often happen is leadership will actually be using OKRs to micromanage what gets through, to muck with the roadmaps, to prioritize features, to ask where’s my feature?

As that’s happening and the OKRs are being used to manage deliverables, the bottleneck is not visible because everyone’s just wanting more features, more quickly. And we’re not seeing these dynamics of flow. 

Of course, if these OKRs are coming top down, being pushed on the value streams, what’s happening to our value streams is that their capacity is being overloaded, there’s more work in progress, the flow load increases, and even less value makes it to the customer. 

Contrast that with good OKRs, which should not touch any of what’s being prioritized. We’ve got protestations frameworks, agile frameworks, for that. Instead, good OKRs focus on reducing the bottleneck, removing the impediments, and adding value to flow more quickly, providing more focus on flow. 

OKRs are actually about looking at how we get more value through and remove wait states, those impediments, and surface those bottlenecks, because sometimes the bottlenecks will be within a value stream.

There’s a lack of some continuous integration, deployment automation, some overly slow security reviews. Sometimes they’ll actually span value streams. So OKRs can surface those bottlenecks. If multiple value streams have dependencies on say one platform, our lack of APIs. And of course the key thing is that they can help balance with the features that we need to deliver. So OKRs can have balanced roadmaps because they allow room for improvement, which the key results can drive while of course, roadmaps are both delivering more value to the customer more quickly.

Keeping Different Planning Dynamics Separate

We’ve got different planning dynamics that we need to keep separated. We’ve got roadmaps and we’ve got plans. And those really define what gets delivered, in what order, and how those things are prioritized. That’s analogous to the order of the container ships trying to get through that Suez Canal. 

We have value streams specific to OKRs, and this is where the validations themselves, this team of teams construct, can accelerate flow and can surface these bottlenecks. For example, if there’s a shortage of staff in one area, a lack of automation, or some other process impediment, then this is really the value streams themselves trying to widen that canal and they need autonomy to do so. No one understands better how much investments should be made in automation and tech debt reduction and process improvement, then the people working on that value stream themselves. 

As you’ve heard Admiral Richardson say, we need to delegate, we need radical delegation to the value streams to set their own OKRs. 

And then we do have the company-wide OKRs, the ones specific to a large line of business. There OKRs are an opportunity to create the conditions and organizational structures to enable flow. For example, if we’ve got a lack of investment in a common cloud delivery platform or automation on that front, these are an opportunity to accelerate that. This is really analogous to building a new canal, to making sure that we’re not reliant on a single canal and totally changing the conditions to enable faster flow across the entire organization.

Different Types of OKRs

To understand how we do that, we really need to understand the different types of metrics that we’re going to measure, because each of these OKRs needs to use different metrics. 

The business metrics are generally well understood. Those are costs, those are pipeline conversions, those are retention rates, those are profitability numbers. But usually they’re a lagging indicator for technology work. If we deliver these features, those tend not to turn into revenue overnight.

The flow metrics help tremendously here because they track improvement, they track our ability to deliver more value, to delight our users with even more of the features that they’re looking for. They’re a leading indicator of value delivery that then turns into a business metric. 

And then, very importantly, team metrics. The telemetry for teams needs to actually be specific to the teams and not conflated with the OKRs. Teams need a lot of telemetry to do their own decision-making. That decision-making does not need to percolate up to organization levels. It needs to allow the teams to move very quickly, respond very quickly to incidents, to outages, and to other needs. And again, they need to be a completely separate set of telemetry rather than the ones that support organizational improvement such as the business level OKRs.

You can learn about a real-life example from the insurance industry in the full video of the presentation.

Conclusion

As you plan your OKRs, as you’re looking at rolling them out, make sure you’re measuring the flow of value, the flow of value based on the Fifth Ideal of customer centricity. It really is all around what you’re delivering to the customer. 

To do that, use flow metrics as the key results to remove those impediments to the teams. The teams know how to deliver that value. Do some radical empowerment of the value streams to set their OKRs and allow them to deliver on those business objectives, remove their bottlenecks, and signal to the organization as a whole if there are systemic bottlenecks slowing them down, such as missing platform, API capabilities, or other infrastructure. Let the teams use their own metrics, let the value streams use their own roadmaps and decouple these things completely.

In the end, the organizations live and die, by the agility, the quality, and the speed at which we deliver software. OKRs are a great tool for accelerating that. 

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•