OKRs are hard

But I still love them

I see a lot of bad OKRs (Objectives and Key Results). Usually they are just KPIs (Key Performance Indicators) given the OKR name. You know these because they tend to be something like

Objective: deliver product x

Key Result: product x is in production

Objective: drive adoption of product y

Key Result: 5 teams onboarded to product y

In this post, I decided to write down my definition of what a good OKR looks like. My thinking has evolved from what I first learned long ago in half-remembered talks, blog posts, and books, and is now based on my experience using them to set team goals over the past ten or so years.

Objectives

The objective is narrative in nature, and express the strategic focus and opinion about achieving that outcome, not just the general outcome you are seeking.

For example, I have often found myself in the role of running teams that are part of a public cloud migration effort. For a company of any size/complexity, a public cloud migration is a multi-year initiative. So while I could have an evergreen objective: “move the company to the cloud” or “accelerate adoption of the cloud” or what have you, I don’t usually set an objective that is this broad.

Instead, I look at these potential work that we think we need to do, that problems we’re seeing with getting to the cloud, and I try to identify the next key piece of the strategy that we need to focus on. For example, one year the objective was something like:

Make (company name) Cloud Ready

This objective was broad, and encompassed work that was directly about enabling and using the public cloud, but it also covered work that pushed our applications to be more cloud native via containerization and other underlying improvements, whether they were migrating to the cloud at that time or not. This objective expressed the opinion that, whether we were going to move everything to the public cloud or not, the underlying practices that are needed if you want to have “cloud native” architecture and operations are important to drive forward.

I have one exception to writing objectives that express an opinion, and that is when I have an objective that expresses an evergreen value and focus area. For me, that is always “operational excellence.” Every year I set an operational excellence OKR that tags critical projects that are needed to address issues like, say, Python 3 migration, reducing toil in critical systems, or other major operability and reliability-focused areas. I do this because I want to highlight that this work is as important to me as other key initiatives, and furthermore that I expect that all of my teams have some focus on this no matter what else they are doing.

Key Results

Objectives express a high-level strategy with some sort of opinion or statement of values. Key results provide aggregated signals and measures of how you expect to see impact or progress towards achieving that objective.

The temptation with key results is to make them more about work performed than impact. If your key results are all about shipping systems, finishing projects, or hitting delivery milestones, you’re really just measuring whether or not you are getting done what you estimated you could get done. And that’s not bad, exactly, but it has two downsides.

The first downside is that it doesn’t allow for much flexibility in how you achieve your objective, and this is quite limiting! One of the frustrations engineers have with planning is that it can be very rigid. When you’re talking about a yearly process of crafting broad OKRs, you are trying to not only predict what you will get done in the year but which projects are the important ones to get done. If the circumstances change and it turns out that you don’t need to move everyone to EKS but instead you need to move a bunch of people to ECS, for example, your KR of “migrate 100 apps to EKS” becomes immediately red, and you have to rewrite it in favor of equally-rigid “move 50 apps to EKS and 50 apps to ECS.” Where possible, I believe that it is better to write KRs that allow for flexibility in how they are achieved throughout the year.

This brings us to the second downside of work output KRs: they don’t account for impact. This is a particular blind spot of platform-type engineering teams, that they get focused on building and delivering a thing they think they should build and deliver without stopping to ask if it is the most useful thing to help their users achieve their goals. When you write KRs that are about impact (reduce the time to onboard a new cloud application from 2 weeks to 2 days (or, by 50%, or…)), you force people to contend with the question: how will my work deliver impact?

There’s actually a third downside to work output KRs, one that comes out more when you run larger organizations. My personal rule of OKRs is: no more than 5 objectives, each with no more than 4–5 KRs. For whatever the most coherent unit of oversight you have, try to stick to this, whether your team is 50 or 500. When you’re trying to represent a large portfolio of work across many diverse teams, you don’t have room to waste a KR on anything less than a major initiative, and work output KRs can be a waste of a valuable KR spot.

You are going to have some work output KRs, it is inevitable. There are things that just have to be done, and the work of doing them is hard enough that you want to measure that as progress to be reported on. But don’t be lazy! Scrutinize every single work output KR and really ask yourself if there is a better way to measure this that is based more on impact than pure delivery.

All of this is hard

This comes back to my initial point: OKRs are hard. You have to have a strategic opinion to write good objectives, and you have to have some good ideas of what your customers want, what your team could deliver, and what you might be able to measure to create good KRs. You have to understand potentially a very large collection of teams and projects to craft OKRs that are both inspirational and aggressive but not impossible.

And then, of course, there are all of the exception cases that tempt you. I have a carve out for operational excellence, and once you start there, it’s tempting to add more and more carve-outs. We should always have an OKR for team culture/hiring/talent development stuff. We can’t leave out recognizing function X, so we need to create something special for that group. I cannot say that my model of 4–5 Os each with 4–5 KRs really, truly scales past a few hundred, or with every type of business. And there are probably teams that really just don’t need OKRs, due to the nature of their work, the control over how they are measured, their size, or whatever.

This is the downfall of OKRs. They’re hard, but sold as something that everyone should do, so everyone does them poorly, and most people don’t see any value as a result. You don’t have to do OKRs (unless you work for me, in which case, you might). If you’re not going to at least try to put in the work to write good ones, you shouldn’t do them! But if you do the work, they will force you to think more strategically about your goals, and ask hard questions about what the impact is that you are hoping to achieve with them and how you will measure that. Good OKRs tell a story about what is important, they help you inspire people to think about why they are working on what they’re working on, and I think they carry a bit of energy that comes from seeing how it all fits together in a succinct form.

Enjoy this post? You might like my book, The Manager’s Path, available on Amazon and Safari Online!