Seven habits for effective OKR management

The magnificent seven!

(Like this article? Read more Wednesday Wisdom!)

Way back when, in my first job, there was not a plan in sight. Every morning we came in and did whatever we thought was right without much regard for what the business needed. There was a little bit of rhythm to our work because IBM dropped a major version of the operating system every year (through an insanely complex process called CBIPO) and we kept up with that, but that was about it.

Then when I joined Google in 2006, I learned that next to the “almighty dollar” there was also an “almighty quarter”: In 1999 Google had adopted a quarterly planning system called OKRs: Objectives and Key Results. Like many things Google did, their system of OKRs has been adopted widely in much of the tech world. Consequently I have come across one flavor of OKRs or another in many different companies.

At Google the OKR system was pervasive: Every quarter Larry and Sergei set OKRs for the entire company, VPs set OKRs for their organization, teams and projects set OKRs for their particular areas of responsibility, and individuals set OKRs for themselves. The OKR cycle was very strict: At the start of every quarter there were meetings to score the OKRs of the last quarter and to define OKRs for the new quarter. Either monthly or halfway through the quarter we looked at OKR progress and made (small, see habit 3) adjustments. Then, to top it off, the last two weeks of every quarter were an all-out race to finish as many OKR as possible. This caused, among other things, significant stress on the release train because everyone wanted to get their changes in before the quarter ended. As you can imagine this rush also put stress on the post-mortem schedule, because it was not unusable for these rushed releases to contain major bugs :-).

Unfortunately, over many years of doing OKRs, I have seen a lot of instances of OKRs done wrong, making them suboptimal as a planning tool. Therefore, without further ado, here are my seven habits for effective OKRs:

Q: Why seven?

A: Because seven is a magic number in our culture. It’s the number of completeness. Life is a linear journey from one to seven. The week has seven days. Snow White had seven dwarfs. The giant had seven-league boots. There are seven deadly sins. Nuff said.

---

1. Editing: Objectives are imperatives; Key Results are in the past tense.

The first effective habit for the use of OKRs is to formulate them correctly. An Objective is an imperative clause; something you are going to achieve in the future. For example: "Achieve world domination" or "become the world's most popular weekly tech blog". Objectives are typically multi-quarter and so provide some consistency to your team’s work over time. Some objectives are permanent because they come with the mission of the team like: "Keep the site up" or "become world champion" (for the Dutch national soccer team).

Key Results on the other hand are situational; something you want or need to have achieved by the end of the quarter in order to make progress towards an objective. To reflect that they are written in the past tense. For example: "Invaded Liechtenstein" is a key result for the "achieve world domination" objective. It’s not the entire objective, but a good first step. As we will see later it is not a great key result, but at least it's written in the past tense so when the time to score comes around we can read it and then figure out if we have achieved it.

---

2. Key results should be measurable.

Good key results are measurable and therefore written to be very specific.

"Invaded Liechtenstein", is not a great key result because we do not know exactly what it means. When we look back at the quarter, how do we determine if we have completed this KR? Have we achieved it if we have sent a lightly armed platoon of five people to take the town hall of Balzers? Or does a misguided group of Swiss soldiers straying into Liechtenstein by mistake constitute an invasion? Maybe technically so, but practically?

If you are technically correct, you are wrong.

Therefore a better key result would have been "Invaded Liechtenstein, deposed Prince Hans Adam II, took complete control of civil society, and installed a puppet government in Vaduz". That's a much better KR, because it is way easier to determine if you have actually achieved it. 

One thing that can be said about that particular key result is that it is trying to do too much. It should probably be broken up into multiple smaller items.

For reasons of specificity, key results like "Researched options for implementing feature flags" are bad. You can meet this OKR by thinking about the problem for five seconds and looking at Wikipedia. A better key result would be: "Wrote a document investigating three options for implementing feature flags and recommending one for implementation". This is much better because it actually specifies a result. It is measurable, and, once achieved, more useful. This KR could then be followed by KRs that specify that the document was sent to a review board and that a decision has been made.

For long-running objectives like “Keep the site up" it is common to have recurring key results like: "Ran an oncall rotation with two people oncall at any given moment”. 

---

3. Do not change your OKRs mid-quarter!

This is one of the most often breached good habits.

Many teams do a regular OKR review where they track progress on each OKR. But, as the quarter develops, things change: People leave, new work appears, and priorities shift. Many teams I have been in then changed their OKRs by removing the OKRs that they would not (or no longer) be working on, changing OKR descriptions to match what they thought they would be able to accomplish, adding OKRs for things that became hip and happening after the quarter started, and changing priorities.

❗❗❗DON'T DO THIS ❗❗❗

OKRs are a planning tool. They are not a "what did my team work on this quarter" tool. For that we use snippets or project trackers.

Changing OKRs during the quarter reminds me of the infamous software installation progress bars that were adaptive with respect to the expected remaining duration. By constantly recalculating how much time was left they ensured that they always ended at 0 seconds when the installation was done. Kinda cool, but also cheating. If you do that you are tracking, not planning.

One of the reasons many teams modify their OKRs mid-stream is because they think that team and individual performance is measured solely on meeting their OKRs. In a sane organization this is not true.

It is obvious (at least to me) that everyone should always be working on the most important things, regardless of what the plan says. As I wrote above, things change, priorities shift, new information becomes available, and you would be foolish not to take that into account to figure out what to work on.

If at the end of the quarter you have met none of your OKRs but your trackers indicate that you constantly worked on the most important things, there is only one conclusion that can be drawn from that: You (or your entire organization) sucks at planning! Surely that's something that needs to be fixed, but it really needs a bit more research to know why this is the case. If it turns out that the plan (as evidenced by the OKRs) was really the best plan that could be made ex tunc (a lawyerly term that means: With the information you had at the time), then there is something else going on. That something else needs to be addressed, but it’s not the fault of the people executing the plan. Also, in order to detect this situation, you need immutable OKRs that can be compared to the trackers. If you change your OKRs continuously, you make it harder to detect this problem!

In some teams I led I had a standing OKR to deal with whatever the company threw at us during the quarter. When questioned why I had 1-2 people assigned to that OKR I would tell people: “Look, the past few quarters the company managed to assign some big-ass mandate on us right after the planning cycle ended. We end up spending a lot of time on these late-breaking mandates, but at planning time we never know what they are going to be. One quarter it is deprecating Python 2, in another quarter it is moving to the new RPC tech, and last quarter we had to suddenly all implement rate ACLs.  There is always something and you have a habit of only telling us once we have already committed to our OKRs. This OKR is for dealing with the unknown; we don't know yet what it is, but we know that there'll be something." 

Is an OKR like that optimal? No, because it is a reflection that the organization as a whole does not function effectively when it comes to planning, but this is an effective signal and a good way for dealing with that reality.

Meeting OKRs is an important performance signal, but you cannot derive performance from that signal alone. If OKRs were not met you need to know why and that requires additional research. Was it more complex than you initially thought? Were you too ambitious by taking on this OKR? Were people too slow and ineffective? Was there any unexpected illness or leave of absence? Were dependencies not available in time? Meeting OKRs is only one signal of many. If you don’t meet your OKRs you do need an explanation, but it might not be your fault.

OKRs are a statement about what you will have achieved at the end of the quarter, do not constantly adapt that statement so that it will always be true come week 13.

---

4. Prioritize well.

Most OKR systems use priorities to indicate that something is more important than something else. Unfortunately, there are few topics as contentious as prioritization and most people do it completely wrong.

The biggest problem to deal with is “the race to P0”.

It is important to realize that the purpose of a priority is to help make decisions about what to work on. When I have some time on my hands, I should work on the highest priority thing that I could make progress on. However, priorities have also become value statements. If something is not P0, how important is it? Every OKR should have a sponsor and to that sponsor, that OKR is probably the most important thing in the world. In the face of existing P0 OKRs, if something is not P0, that something might not get done. Hence there will always be people clamoring for the priority of an OKR to be raised.

Without good rules on how to prioritize, everything will end up being P0, and that means that priorities have become useless.

There are roughly three ways to do prioritization correctly.

Method 1 is not to do prioritizations at all but to just make a stack ranking. Another way to put this is to say that you have as many priorities as you have OKRs and that each OKR has a unique priority :-). This is my favorite method. It can lead to lots of discussions about what is more important than what else, but these are good discussions to have.  

Method 2 is to have descriptive statements for each priority band and apply them ruthlessly. In many SRE teams that I was in, I proposed priority band definitions like these:

P0: If we don't do this, the site will be down by the end of the quarter.

P1: If we don't do this, we will experience measurable degradation and we will fall out of one or more SLOs.

P2: If we don't do this, this KR will become a P1 or P0 in an upcoming quarter.

P3: We would like to do this because it makes our life better, easier, or more efficient, but it will probably not move the site's SLOs.

P4: Everything else. Nice to have. We will probably not do this :-)

The advantage of a definition like this is that if you still end up with a whole bunch of P0s, you can go to your management and ask for extra headcount or change the SLOs.

Finally, method 3 is to have a maximum number of OKRs in each priority band. For instance you can state that you can only have three P0s, four P1s, five P2s, and the rest is either P3 or P4. This is somewhat akin to stack ranking in that it creates lots of discussion, but again, these are good discussions to have.

Once you decide on a system for your team, don't break the rules!

---

5. Do not carry low-to-medium priority OKRs over more than once!

Each team has things that they would like to do but never get around to. In the world of OKRs this phenomenon manifests itself as a low-to-medium priority OKR that keeps coming back every quarter. It can be something like: "Enabled type checking on our Python code base", or "Refactored our Terraform configs". Yes, it would be great, but often these are OKRs at the level of "I should organize my sock drawer by color".

If one of these makes it to the OKR list and at the end of the quarter it is not yet done, there is always some pressure to declare it a "carryover" because the perceived need is still there. And then the next quarter, unless something miraculous happens,  it carries over again. Eventually it will become a zombie OKR, not alive but not quite dead either, and sucking the life out of every OKR meeting.

Here is the sad truth: If you say you are going to do something and you haven’t been doing it for six months, you are not going to do it. Period. Yes, it might be nice if you would get around to it, but apparently you have bigger fish to fry. If someone really cares about it they can still do it, but it should not be part of the team's official plan of attack for the quarter.

You have to realize there is an infinite amount of work and unless you are ridiculously overstaffed you can probably only work on the most important things. If you have time to reorganize your sock drawer, your team is too big. Recognize this and do not carry these OKRs over.

---

6. Cross-validate your OKRs with other teams.

Your team is part of a larger organization and in order to achieve whatever it is you need to achieve, you depend on other teams' work and other teams depend on your work. Therefore you need to do some dependency checking.

Here is the general rule: Your Pn OKR cannot depend on another team’s Pm OKR if n < m (assuming you use the same system for prioritization). To check this, make it a habit to cross-validate your OKRs with other teams to see if you are aligned on the work you are going to and the priorities of various OKRs. I promise you, it will prevent a lot of grief.

---

Bonus habit: Do not overindex on OKR tools.

Administering OKRs is a bit of bureaucracy and there is the mistaken belief that a tool could really help here. Nothing is further from the truth. Instead, OKR tools are the ultimate bikeshedding topic and I have witnessed many discussions on The Right OKR Tool. Really, to do OKRs well you only need Notepad and maybe a shared drive. The rest is just wasted time and effort.

---

7. Remember: OKRs are not everything!

One of my worst working experiences was in an organization that used a planning strategy where every task had to be in the plan and every task had a code that needed to come back in your timesheets. This led to a situation where people could not afford to do the right thing because there was no code for that work or there was no time left that could be booked on the code.

Total suckage.

Don't treat OKRs this way. OKRs are a tool to plan the special (or important) work you are doing this quarter, to ensure that you define that work accurately, and to communicate to everyone what that work is. You don't need an OKR for going to the bathroom or for the weekly meetings. OKRs work best if the set is manageable and if the OKRs cover the important and non-obvious things that you are going to do.

---

That’s it. Seven habits (and a free bonus habit) to ensure that you do OKRs correctly.

I like OKRs because they are a good tool to make sure that you keep focused on getting stuff done. Like most systems of planning and goal setting, OKRs come with artifacts such as the rush in the last two weeks of the quarter. That is fine though because without more or less arbitrary deadlines and the rush they cause, nothing would ever get done. And that is what OKRs are ultimately for: To ensure that stuff gets done.