Why OKRs Suck
Many of my readers are probably just finishing up their quarterly (and/or annual) planning cycle, so now would be a good time to remind us that the process we use as a standard in the tech industry is, in fact, complete bullshit. Of course, I mean the methodology Objectives and Key Results. Let’s talk about OKRs, what they are and where they came from, and why they are a terrible idea.
OKR: Google conspiracy?
The OKR methodology was originally developed by Google in…
Wait a minute, I just read the Wikipedia article I linked to in the previous section, and it turns out that I started the article by spreading misinformation! 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 1983 management book, and they later appeared on Google, probably around the early 2000s. And although Google doesn’t invented concept of OKR, she definitely helped popularize it. [Кстати, заголовок этого раздела связан с мыслью, которая встречалась мне несколько раз: что Google намеренно популяризировала методологию OKR как способ саботирования остальной части отрасли и снижения её эффективности. Думаю, к этой мысли можно применить множество принципов, в том числе закон Беттериджа, бритву Хэнлона, бритву Оккама и уверен, что другие тоже.] Now, wherever you go, all companies use OKRs. This term has become something like the word “copier” and is used to refer to planning, no matter how different the planning process is from the original OKR methodology.
So, having understood the history, let’s ask ourselves: what such OKR? In short, it is a way of setting goals and measuring progress towards 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 metrics-based.
OKRs are generally expected 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 OKRs of the business units; sometimes even each team member may have their own OKRs. At each level there should be from one to three goals, that is, short statements of “what” you want to accomplish in the next quarter, or year, or any other period; Each goal should have one to three key results indicating success or failure in achieving the goal.
In addition to the basic methodology, organizations should also use several guiding principles when setting OKRs. The most (in)famous one is that you need to set your OKRs so that you can only achieve 70% of them. If you consistently achieve 100% of your goals, it means you are not ambitious enough. Second, you should avoid “binary” OKRs, that is, OKRs whose only metric is “I did this” or “I didn’t do that.” Third, OKRs should not cover all activities of the organization: normal day-to-day support work, on-call work, and so on are all “extra” things that should not be included in OKRs. [Повседневная монотонная работа недостаточно «вдохновляет» и чтобы вдохновлять людей, нужно использовать OKR.] Finally, the only way to learn OKRs is by working with OKRs.
Perhaps some of you are already ready to angrily scribble 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 teach OKRs is to work with OKRs,” then by definition that means everyone will implement OKRs differently; 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, he is always answered in the style of the classic “no true Scotsman“: “Well, you’re just implementing OKRs incorrectly.” But then my question becomes: if no one in the industry is doing OKRs “right,” then why are we even bothering to do them?
New Perspective: I’m not saying we shouldn’t have goals. I’m not saying we shouldn’t have plans and take responsibility for them. Of course we must! Engineers love to criticize routine, bureaucracy and delays, but I will be the first to say that in to a certain extent Such processes are important, especially in large organizations. In this article, I just want to convince you that OKR is not the right process.
OKR: the path to a pile of unfinished work
Let’s talk about OKR problems. I want to start this section by saying that I worked as an infrastructure engineer and that many of my arguments will be from that perspective. But I’ve heard similar complaints from people on product teams, so I think my objections are valid in this area as well.
First, let’s start with the ridiculous claim that you should aim for 70% completion of your OKRs. Even if we put aside the vagueness of this definition (should we complete 70% of our goals at 100%? Or should we complete 100% of our goals at 70%?), it is worth considering that most of the work we do has no value unless we do it. fully. Perhaps if your key result is “increase CTR by 100%” and you increased it by 70%, then you could say that’s still pretty good. But if your key result is “migrate 100% of users to the new system,” and you only migrate 70%, can you guess what that means? Now you will constantly have to maintain two systems. Fortunately, this principle doesn’t seem to be much adhered to these days; I think people realized that this motivates the wrong actions.
But this leads us directly to the second problem with OKRs: measurement. Some might say that the migration example doesn’t apply because it’s a binary OKR – we either migrated or we didn’t. This leads to an indirect development of a metric that still means “I completed the migration” but not in a binary formulation. Perhaps you’re surveying customers and want 100% to be happy with a new system, but consider it a success even if only 70% are happy. Or perhaps you are changing the number of crashes caused by the new system, and your goal is “zero crashes.” [Я видел, как в разных случаях применялись оба этих подхода, а также множество других техник. Вы бы удивились тому, насколько изобретательными оказываются люди в попытках привязать двоичную переменную к непрерывному множеству.]
However, there are additional problems here: one of them is that you’ve just created a bunch of extra work for yourself, because chances are that the metric you came up with to measure migration success didn’t exist before: so before you get to the main work, you will have to create tools to collect metrics, and these tools and metrics will likely be forgotten in a quarter or two when priorities change. Another problem is that the metrics you invent are not related to the job being done—user satisfaction is anywhere from five to zero percent related to the quality of the migration, and 90 percent related to how well someone else designed the new system. , who may no longer even work for the company. The third problem is that these metrics are very difficult to talk about. For example, in the case of the “number of failures” metric, your target value is zero, that is, if you experience any quantity failures, this key result will be uncertain. To get the 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 measurement is that not everything needs to be measured, even if it can be done! Data-driven decision making is a very fashionable term in our industry. We want to improve, we want to see how much better we have become and we want to tell the world how much we have improved so that our stock prices go up. But there is a huge amount of work that does not need to be measured or cannot be measured or is very easy to misinterpret if it is Can 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) to know enough statistics to correctly interpret the metrics, c) to not care about everything that cannot be measured.
The last complaint about OKR is related to its cascading nature. Our industry, for the most part, moved away from waterfall-style development a long time ago and then eagerly embraced the planning methodology that pushes waterfall development. There is no room for research and experimentation in the OKR methodology (because how will you measure research?), so when writing an OKR you need to know everything in great detail, otherwise something may arise 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 all wrong. We must use Agile! OKRs are subject to change! We need to react to new information!” Yep, I’ve heard all this before. But I guarantee that when it comes time for performance reviews, the people deciding whether you were a successful developer will judge you by your original goals for the year, and if you had to change them, it will be seen as a failure. Yes, this probably doesn’t happen. everywhere, but avoiding such outcomes requires support from the company culture. So it may be worth using a planning process that has room for change in the first place, rather than trying to adapt to one that simply doesn’t work.
OKR: does this mean we need another spreadsheet?
Do you know what I haven’t talked 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 each month by changing the values in that spreadsheet. Nobody said that you need a JIRA epic for your purposes and track all tickets by the OKR they belong to. Nobody said anything about “internal OKRs” being different from “external OKRs”, about roadmaps, about planning meetings, about… the list goes on.
However, I can imagine that any manager who hears about OKRs will immediately think of a spreadsheet. [Уважаемые менеджеры, я вас люблю. Серьёзно, вы занимаетесь трудной работой, за которую я бы ни за что не взялся. Так что спасибо. Даже если иногда вы используете слишком много электронных таблиц.] And I think this is also a problem. You see, in our industry we conflate OKRs with “planning”, but I don’t think they should be combined. Even if we forget all the problems with OKRs that I talked about in the previous section and return to the original (or rather “original” in the sense of “Google popularized”) definition, the purpose of OKRs is to inspire. That is why this desire for 70% appeared. We want to set challenging goals that inspire people to do better, and then acknowledge when those goals were difficult to achieve without punishing people for not achieving them 100%.
But guess what? From that perspective, I like OKRs! We should strive to complete difficult tasks and should not punish people for failing to do them. In addition, we have must have a plan and we need to understand the work we will be doing over the next few weeks or months; Maybe, we’ll need a spreadsheet to help us stick to this plan. But for God’s sake, let’s stop trying to shoehorn metrics into this goal setting methodology, let’s stop trying to shoehorn goal setting methodology into the quarterly planning process and spend months planning only to have everything change two days into the cycle.
