OKRs & DevOps: From Micromanagement Misery to Finding Flow

OKRs & DevOps: From Micromanagement Misery to Finding Flow


Dr. Mik Kersten

Founder and CEO, Tasktop



Thank you, Admiral Richardson. Okay. The next speaker is someone who should be familiar to most of us in this community. Dr. Mccarsten wrote the amazing book project to product three years ago, and it summarizes his 20 year journey understanding how to truly unlock developer productivity. And so over the years, he's taught us how to properly diagnose flow problems in the technology value stream so that technology can help best achieve our business goals and how organizations can move from the world of project management to product management. Throughout this past year, we've had numerous conversations about how so many organizations are having trouble rolling out or objectives and key results. Especially when top leaders overreach into the planning process using OKR is to bludge in their favorite project or feature into the plan. Dr. Kristen will talk about his seven years of experience using OKR and what he's seen go right and wrong in large complex organizations. Here's Mick.


Hello everyone. I'm coming to you here from Vancouver and thrilled to be participating in the DevOps enterprise summit. My favorite conference of the year, both in London and in Las Vegas. And the topic for today is OKR on dev ops. How we can go from micromanagement misery to finding flow. So I've now had eight years of experience managing my own company with OKR is I've noticed that over the past, especially the past few months, but really the past couple of years as DevOps has become a CEO and 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. Uh, this is, this has become a really key topic where some organizations are using ocarus very effectively to better understand how to connect technology and business and deliver more for their customers, whereas others are failing.


And what to me were, were very surprising ways. So let me quickly talk to you about the, what I've learned within my company, supporting other organizations who are using this methodology and on how you can apply some of these lessons to your own initiatives. So, first of all, objectives and key results are just one way of tracking plans and goals. And some of these concepts will apply to any other ways that you're measuring value there, OGs, Sams, and other approaches, but we're going to dig in specifically to these OKR. So the objectives are the what and these inform actions and the really about finding a way of measuring value to how much we're delivering for customers, our market, our colleagues, and the KRS. The key results are the benchmarks for how we're doing that. So the point of OKR is that you have around three to five of those that the cell phone, they factor in how they cascade and how they get and how they spread across the organization.


And they're really, uh, uh, summarized very by John door's book measure. What matters came out in 2018, I'd actually been applying them for years. It was very helpful for me to see this book. I had my whole leadership team read it by found that w with this book that was a really significant gap. And I think this gap is where a lot of the deployments of OTRs fall into. And that's 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? We had start measuring the wrong things. If we measure the wrong things, we often get into these pitfalls of actually slowing down our teams of, of inspecting at the wrong levels of cascading, far too low mocking and micromanaging, where we shouldn't be. And so in project, the product, uh, introduced the full framework where the full frame was really meant to capture a way of measuring flow and connecting that to these business results, that, that top right part of the flow framework, where flow metrics we've been using for many years now for eight years now with passed up for measuring key results related to flow with how we're delivering value for our customers.


Uh, and then combining those with the business objectives of, uh, around the other financial metrics and all the other metrics in the organization. So 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 and your key results in order to connect business and technology. So, first of all, the question of why flow, I think we in, uh, in recent news, we've had really interesting examples of why flow is so important, how problematic bottlenecks can be. So we saw the entire shipping industry grind to a halt. Then our products all get delayed, uh, in terms of getting the, getting to getting to consumers because the Suez canal became a bottleneck. And if we look at this and we actually realized that when we have this kind of bottleneck, the entire system slows down, there've been these amazing visualizations that show how it's not, it wasn't just the ships around the canal, but the global shipping system 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? So I think if we take as leaders of teams, of organizations, of value streams, if we take our job as improving flow, adding really focusing in on that second ideal of focus, flow, enjoy for all our staff, all our colleagues, and for what we deliver to our customers. We need to know where our bottlenecks are. Uh, as, as gene Kim, uh, channeled gold draft in the Phoenix project, any improvement made anywhere besides the bottleneck is actually an illusion. So if we're investing elsewhere, other than the bottleneck, we're not helping flow, we're not helping that focus or that joy. And the thing that made me so excited about OKR is, is that there, that I found them as a really effective tool for speeding up flow for changing organizational conditions, investing in bottlenecks.


But what I've also found fascinating is a lot of my colleagues and larger organizations who been deploying, okay, ours have been finding is that the okay is actually slowing them down. And so this, this seems horribly ironic and something that we, we really need to fix. So let's look at how these things have gone wrong. And I've had a lot of conversations that a lot of organizations have them have they been deployed these okay, ours and having things go sideways. And so these are some of the key problematic things, themes that I've seen, first of all, okay, ours are being used for micromanaging teams and value streams. So rather than sending these organizations directions and paths, and really helping everyone navigate towards that common goal, they're actually being used to track specific features, muck with roadmaps and reprioritize things for people. Uh, and they really only, I didn't really think they were meant for that because in the end, when, if that's what's happening, we're actually re-introducing waterfall planning into our dev ops transformations and our agile processes, which is again, kind of antithetical to the goal of why we're all here.


Uh, another really fascinating thing is using the business and financial metrics as the only key results. So what'll often happen is a financial metrics such as a cost metric, uh, or a, or a revenue metric could be quite divorced from what a team is doing. You might have a platform team creating the new cloud infrastructure ramping up a whole lot of SRS who might not map directly into a revenue metric, but is still going to help the organization succeed and eventually drive to faster revenues and more of the UN and more market leadership. Another key pitfall that we'll go into is using only team proxy metrics as the, as the key results, that being all that we measure. So teams have a lot of detailed metrics, but a lot of different KPIs that they need to use, but have proxy metrics. They're not metrics of value of flow by very specific team's work that can really the rail OKR efforts, uh, one of the biggest one it moment.


And the key thing is that if these, these practices of using ocarus for something they weren't intended for, for measuring, for not measuring value result in conditions that make OTRs work against you, they make it really make you feel like things are slowing down, which means chances are they are slowing you and your teams down. So let's look at what bad OKR is really come from and what they do. So again, if we look at a specific value stream, you can see this value stream has a pretty significant bottleneck in it. A lot of features and other flow items are trying to get through, uh, but they're not getting through. And what will often happen is leadership will actually be using, okay, ours to micromanage. What gets through to mark with the roadmaps to prioritize features, to ask where's my feature as that's happening. And they all care to being used as deliverables.


Uh, the bottleneck is, is not visible because everyone's just wanting more features more quickly. Uh, and we're not seeing these dynamics of flow. And of course, if these OTRs are coming, top-down being pushed on the value streams what's happening to our value streams is that, uh, that their capacity is being overloaded. There's more and more can progress the flow load increases and even less makes it to the customer. Even less value is delivered. Contrast that with good, okay, ours, which should not touch any of what's being prioritized. We've got protestations frameworks, agile frameworks for that, but instead, those old is focused on, on reducing that bottleneck, removing the impediments and adding value to for more quickly providing more focused on flow. So these OTRs are actually about looking at how we get more value through and remove those waste states, those impediments and surface those bottlenecks, because sometimes the bottlenecks will be within the value stream.


There's a lack of some continuous integration, deployment automation, uh, some overly slow security reviews. Sometimes they'll actually span value streams. So, okay. That's 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 need to be, they can help balance with the features that we need to deliver. So, okay, you guys can have balanced roadmaps because they allow room for improvement, which, which the key results can drive while of course, roadmaps are both delivering more value to the customer more quickly. So the key thing to understand this is that we've got different planning dynamics that we need to keep separate, that we need to keep separated. So we've got roadmaps and we've got plans, and those really define what gets delivered and in what order and how those things are prioritized.


So that's analogous to the order of the container ships, trying to get through that Suez canal. We have value stream specific OKR, ours, and this is where the validations themselves, this team of teams construct can accelerate the flow and can surface these bottlenecks. For example, if there's a shortage of staff in one area, a lack of automation, some other process impediment, this is really the value streams themselves, trying to widen that canal and the autonomy to do so. No one understands better how much investments should be made in automation and tech that reduction and process improvement. Then the people working on that value stream themselves. As, you know, as, as you've heard in other regions and say, we need to delegate, we need radical delegation to the value streams to set their own okay, ours. And then we do have the organizations, the company-wide OKR is the ones specific to a, to a large line of business.


And really they're the, okay, there's an opportunity to create the conditions and organizational structures to enable flow. For example, if we're, we've got a lack of investment in, in a common cloud delivery platform where automation on that front, these are an opportunity to accelerate that. And this is really, uh, 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. So to understand how we do that, we really need to understand the different types of metrics that we're going to measure it because each of these OTRs and need to use different metrics. So the business metrics are generally well understood. Those are costs. Those are pipeline conversions. Those are retention rates. Those are profitability numbers, uh, 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 the improvement. They track our ability to deliver more value, to delight our users with even more of the features that they're looking for. And so they're a leading indicator of value delivery that then turns into a business metric and very importantly, team metrics. The telemetry for four teams need to actually be specific to the teams and not conflated with the OTRs teams need a lot of telemetry to do their own decision-making that this isn't making does not need to percolate up the 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, be a completely separate set of telemetry rather than the ones that support organizational improvement such as the, the business level. Okay, ours. So let's just quickly go through an example.


And this is an example as a, as an insurance organization, uh, where that's deployed OKR is would actually using some little data sets here. And some exemplary OKR is where what they want to do is become the most innovative instrument industry. This is great because the objective is actually linked to their core values and innovation for their customers. They want to see that turn into 30% market growth at 50% reduction in the time that it takes the provision insurance policy. So that's really important because that OKR cascades down to how prioritization is done. If a roadmap item is going to make it easier to move customers faster, remove calls or places where things are being dropped, we'll know that we're on track on this of this OKR. And then the key thing is these two, okay, ours are balanced with a flow efficiency improvement. So flow efficiency is the ratio of wait states to work states.


This actually helps fuel that, that third ideal from the unicorn project around around the improvement of daily work, because it allows everyone to take time in support of this OKR to actually improve how quickly they can get value for customers and drive that efficiency. So let's take a look at how the platform value stream, which really supports all of these new applications. All of this new innovation actually interpreted those okay, ours and turn them into some very significant change for the organization. So what had happened is in terms of moving fast and want to grab more market share, there was a whole lot of technical debt incurred and the shift to cloud and the shift of all of the different customer views, the policies and all of that infrastructure as a result, the costs had ballooned. So there was some lifting and shifting more than anyone wants to admit that was going on.


And the, it was clear that it was no longer scalable to keep building these applications. In this way, the team themselves realized what had happened because they were not making efficient use of storage services. They realized that there were much better ways of they could just focus in on technical debt. So they actually used and set their own OKR saying, if we focus in on technical debt, we can dramatically change this hosting profile and have finance stop worrying about this. And everyone realized we really can't scale the 30% market leadership. As, as our goal, they did that over the course of three months of investment technical debt. They dramatically reduced this hosting cost bubble. They reduce hosting costs by 75% and they had proven that this can be done and that the entire portfolio can actually be hosted in this modern way. Now let's take a look at the actual customer facing application.


So this is the policy value stream where really the focus was making products that these customers love. There's a lot of competition from insurtech organizations. And so a 20% improvement in NPS was really a key part of hitting that objective. The objective that was set by this value stream itself, the ones producing all of the mobile and the web experiences. And to do that, it was really what's about delivering those features, that delighted customers, more better authentication experiences, making sure that they can make it through the whole, the entire provision process quickly and with some joy. So thankfully their organization already had a flow efficiency from switching to the expensive experiments on their way. So they knew where to target the process improvements. It turned out that the bottleneck and there's has to be only one at a time, uh, was in verification, that business was needed.


Verify all those features, making it, the customers. They already had good automation of feature delivery in place, but all these weights states came from waiting on the business and all the meetings that were happening. So the team targeted and was very public in their own. OKR is around this zero days, wait, state on business input for shipping. Those features once that happened, flow time was cut dramatically. We can see it go down from almost 30 days to averaging. Under 10 days, new features were being delivered to customers, mobile and web. And under 10 days for this organization, from that full-time reduction, we actually did see the net promoter score, how happy the customers were with the applications rise, of course, as a lagging indicator, because it took time for them to start adopting using those features. And this really helped that company on that objective of cutting the time to provision policies in half, because they have happy engaged customers who are getting to successful policies.


So the whole point here is as your plan Yoko is OKR is as you're looking at rolling them out, make sure that you're measuring the flow of value and the flow, the flow of value by that, that fifth and most important ideal of customer centricity. It really is all around what you're delivering to the customer to do that useful metrics as the key results to remove those impediments to the team, because funnily the teams know how to deliver that value, do some radical empowerment of the value streams to set their own KRS and allow them to deliver on those business objectives, remove their bottlenecks and signal to their organizations as a whole. If there are these systemic bottlenecks, slowing them down, such as missing platform, API capabilities, rather infrastructure, let the teams use their own metrics, but the value streams use their own roadmaps and decouple.


These things completely OTRs are really for that organization, learning and improvement, uh, and should be kept separate from the silica guards, which are really this north star in the end, the organizations live and die, but the agility, the quality and the speed at which we deliver software and okay, there's a great tool for accelerating that. So in terms of help that I'm looking for, uh, I would love to hear more about your experiences in terms of what's gone wrong with the OKR. I gave some examples of the things that I've learned. Again, I think they're an extremely effective tool if you're using them successfully. Uh, please share this out on the DevOps enterprise summit, slack, and I look forward to learning more on the reporting on the next set of, of experiences on how to accelerate flow through. Okay, ours.