Why OKR is rubbish
Many of my readers have probably just finished their quarterly (and/or annual) planning cycle, so now would be a good time to remind you that the process we use as the standard in the tech industry is actually complete nonsense. Of course, I mean the methodology Objectives and Key Results. Let’s talk about OKRs, what they are, where they came from, and why they’re a terrible idea.
OKR: A Google Conspiracy?
The OKR methodology was originally developed by Google in…
Hang in there, I just read the Wikipedia article I linked to in the previous section, and it turns out I’ve started a disinformation article! How dare I! Okay, let’s start again.
OKRs were introduced by Andrew Grove of Intel back in the 1970s! He wrote about them in a management book in 1983, and they later appeared at Google, probably around the early 2000s. And although Google does not invented concept of OKR, she definitely helped popularize it. [Кстати, заголовок этого раздела связан с мыслью, которая встречалась мне несколько раз: что Google намеренно популяризировала методологию OKR как способ саботирования остальной части отрасли и снижения её эффективности. Думаю, к этой мысли можно применить множество принципов, в том числе закон Беттериджа, бритву Хэнлона, бритву Оккама и уверен, что другие тоже.] Now, everywhere you go, all companies use OKRs. The term has evolved into something of a “xerox” word, used to describe planning to the extent that the planning process was dissimilar to the original OKR methodology.
So, having dealt with history, let’s ask ourselves the question: what such OKR? In short, it’s a way of setting goals and measuring progress toward those goals. Objective (O) is your goal and Key Results (KR) are what you need to accomplish to know if you hit that goal. Of course, since we all want to be data-driven organizations, key results must be measurable and metric-based.
OKRs are generally assumed to be cascading. In other words, the CEO (or other leader) sets some OKRs for the organization as a whole, and then the various business units set OKRs that support the global OKRs, and then each team sets OKRs that support the business unit OKRs; sometimes even each team member may have their own OKRs. Each level should have one to three goals, that is, short statements about what you want to accomplish in the next quarter, or year, or any other time frame; each objective should have one to three key outcomes indicating success or failure in achieving the objective.
In addition to the basic methodology, when setting OKRs, organizations should use several more guiding principles. The most infamous of these is to set OKRs so that you can only achieve 70% of them. If you consistently meet 100% of your goals, it means that you are not ambitious enough. Second, you should avoid “binary” OKRs, i.e. OKRs whose only metric is “I did it” or “I didn’t do it.” Third, OKRs should not cover all activities of the organization: normal day-to-day support work, rotations, etc. are all “extra” things that should not be considered in OKRs. [Повседневная монотонная работа недостаточно «вдохновляет» и чтобы вдохновлять людей, нужно использовать OKR.] And finally, the only way to learn OKRs is to do OKRs.
Maybe some of you are already ready to angrily write in the comments that I’m saying everything wrong and that I don’t understand this methodology at all. That’s fine, but my main gripe with the OKR methodology is the last point: if “the only way to learn OKRs is to work with OKRs,” then that means everyone will implement OKRs in their own way; in practice, this will result in the methodology becoming whatever you want it to be. But when someone directs any criticism of the OKR process is always answered in the classic styleno real Scotsman“: “Well, you’re just implementing OKR wrong.” But then I have this question: If no one in the industry is implementing OKRs “correctly”, why are we even trying to?
New perspective: I’m not saying we shouldn’t have goals. I’m not saying we shouldn’t have plans and be accountable for them. Of course we have! Engineers love to rail against routine, bureaucracy, and procrastination, but I’ll be the first to say that in to some extent such processes are important, especially in large organizations. In this article, I simply want to convince you that OKR is an inappropriate process.
OKRs: the way to a pile of work-in-progress
Let’s talk about OKR issues. I want to start this section by saying that I have worked as an infrastructure engineer and that many of my arguments will be from that perspective. But I’ve heard similar complaints from people in product teams, so I think my objections are valid for this industry as well.
First, let’s start with the ridiculous statement that you should aim for 70% completion of your OKRs. Even setting aside the vagueness of this definition (should we complete 70% of our goals 100% of the time? Or complete 100% of our goals at 70% of our goals?), it’s worth considering that most of the work we do has no value unless it’s done fully. Maybe if your key result is to increase your CTR by 100% and you increase it by 70%, you can say that’s still pretty good. But if your key result is to “migrate 100% of users to the new system” and you’ve only migrated 70%, guess what that means? Now you have to maintain two systems at all times. Fortunately, recently this principle does not seem to be particularly followed; it seems to me that people understood that this motivates the wrong actions.
But this leads directly to the second problem with OKRs: measurements. Some might say that the migration example doesn’t work because it’s a binary OKR – we’ve either migrated or we haven’t. This leads to the indirect development of a metric that still means “I’ve done the migration”, but not in binary terms. Maybe you’re surveying customers and want 100% satisfaction with a new system, but consider success even if only 70% are satisfied. Or maybe you’re changing the number of failures caused by a new system and your goal is zero failures. [Я видел, как в разных случаях применялись оба этих подхода, а также множество других техник. Вы бы удивились тому, насколько изобретательными оказываются люди в попытках привязать двоичную переменную к непрерывному множеству.]
However, there are additional problems here: one is that you’ve just created a bunch of extra work for yourself, because chances are the metric you came up with to measure migration success didn’t exist before: so before you start of the main problem To work, you will have to create a toolkit to collect metrics, and those tools and metrics will probably be forgotten in a quarter or two when priorities change. Another problem is that the metrics you invent are not related to the work being done—user satisfaction is five to zero percent dependent on the quality of the migration performed, and 90% related to how well a new system was designed by someone else who may not even work for the company anymore. The third problem is that these metrics are very difficult to reason about. For example, in the case of the “number of failures” metric, your target value is zero, meaning if you have any amount failures, the indicator of this key result will be uncertain. To get a percentage, you need to divide the number of failures by zero. Congratulations! The metric value can be anything you choose!
I think the biggest problem with OKR’s obsession with measurements is that not everything needs to be measuredeven if it can be done! Data-driven decision-making is a very trendy term in our industry. We want to improve, we want to see how much better we’ve become and we want to tell the world how much we’ve improved so that our stock prices go up. But there is a huge amount of work that doesn’t need or can’t be measured, or is very easy to misinterpret if it is it is possible to measure I think Richard Marmorstein’s article says it very well: be good-argument driven, not data-driven. In order to be data-driven, you need: a) to have metrics; b) you knew enough statistics to correctly interpret the metrics; c) you did not care about all that cannot be measured.
The last complaint about OKR is related to its cascading nature. Our industry largely abandoned cascade-style development a long time ago, and then eagerly embraced a planning methodology that encourages cascade development. There is no room for research and experimentation in the OKR methodology (after all, how will you measure research?), so you need to know everything in detail when writing an OKR, otherwise something may come up that prevents you from completing the OKR (or at least reaching 70%). But raise your hand if you’ve ever written down all your OKRs, and then two months into the cycle, something comes up that makes all the goals irrelevant.
“But wait, you’re just doing it wrong. We must use Agile! OKRs are subject to change! It is necessary to respond to new information! Yeah, I’ve heard it all before. But I guarantee that when it comes time for performance reviews, the people who decide if you’ve been a successful developer will judge you on your original goals for the year, and if you had to change them, it’ll be seen as a failure. Yes, apparently, this does not happen everywhereBut to avoid such results, support from the company culture is needed. So maybe it’s worth using a planning process that initially has room for change, rather than trying to adapt to one that just isn’t working.
OKR: Does this mean we need another spreadsheet?
You know what I didn’t talk about in this post yet? About spreadsheets. Nowhere in the OKR methodology does it say that you need to write down a list of all your goals and key results in a spreadsheet and then check the metrics every month by changing the values in that spreadsheet. No one said you need a JIRA epic for your goals and tracking all tickets by the OKR they belong to. Nobody said anything about “internal OKRs” being different from “external OKRs”, roadmaps, planning meetings,… the list goes on.
However, I can assume that any manager who hears about OKRs will immediately think of a spreadsheet. [Уважаемые менеджеры, я вас люблю. Серьёзно, вы занимаетесь трудной работой, за которую я бы ни за что не взялся. Так что спасибо. Даже если иногда вы используете слишком много электронных таблиц.] And I think that’s also a problem. You see, in our industry we conflate OKRs with “planning”, but I don’t think they should be conflated. Even if you forget about all the OKR problems I talked about in the previous section and go back to the original (or rather “original” in the sense of “popularized by Google”) definition, the task of OKR is to inspire. That is why this aspiration of 70% appeared. We want to set hard-to-reach goals that inspire people to do better, and then admit that those firs were difficult to reach, and not punish employees for not 100% of them.
But you know what? That’s how I like OKR! We should strive to accomplish difficult tasks and not punish people for failing to do them. In addition, we have should be a plan and we need to understand the work we will be doing in the next few weeks or months; maybewe’ll need a spreadsheet to help us stick to this plan. But for heaven’s sake, let’s stop trying to cram metrics into this goal-setting methodology, let’s stop trying to cram a goal-setting methodology into a quarterly planning process and spend months planning only to have things change two days into the cycle.