OKRs aren't a goal-writing technique. They spare you three years of waiting to test your strategy

The definition itself is simple and fits in two sentences. The Objective is the business value we want to see at the end of a chosen period. Key Results are the things by which we will know unambiguously that this value has actually appeared, because a written goal means something different to everyone in the company. That is the theory, and that is roughly what is left after a typical training course.

The trouble starts with the first real objective. Rolling out a new CRM is not an objective. It is a project someone has already chosen. The objective is the change that project is meant to bring: closing deals faster, better customer service, checking faster whether a client is a good fit for us, more leads. Only that is the value the company is after, and the CRM is one of the ideas for getting there.

The difference looks like a matter of wording, and it is very practical. When we think in projects, we have one path, chosen before anyone checked whether it would work. When we think in outcomes, several paths appear and you can choose the cheapest or the fastest. In years of working with companies, only one client has told us outright that they were implementing OKRs precisely to switch the organisation from thinking in tasks to thinking in outcomes. For the others the change happens along the way, although for us it is the most important thing that remains after an implementation.

And this is where a sentence comes up that sounds like heresy at a goal-writing course: writing good goals without connecting them to the strategy and to the company's daily work is a technical exercise. From the more than twenty implementations behind us, we see that an implementation like that uses a fraction of what the method can do. The goals are correct, people know how to write them down, and the company carries on exactly as before.

The triangle in which OKRs have one job

The simplest way to show this is with a triangle. At the top is the vision: why the organisation exists and how it defines its long-term success. Below it, a strategy for two to three years: how we get closer to that vision, which markets we operate in, with which clients, how we compete. At the very bottom is the day-to-day, everything the company lives with every day: projects, tasks, sprints, production cycles. OKRs sit between the strategy and that bottom layer and have one job there.

The job is to cut the strategy into short iterations. Without that there are two options. The first: set a direction for three years, then keep your fingers crossed and check after three years whether the decision was right. That is an expensive bet, because it assumes the market stands still and that we ourselves made no mistake. The second is cheaper: the same direction cut into quarters in which we test the assumptions. If conditions change or a hypothesis turns out to be wrong, we know after a quarter, not after three years. You can also operate without a strategy, and many companies do it for years. The direction is then the sum of whatever the market happens to be doing and whatever clients want, and the bill comes with the first bigger change in conditions.

The second function is less spectacular and in practice often more important. In most companies it is hard to tell which of today's tasks keep the company alive regardless of any strategy and which actually push it forward. Just naming that split stops setting priorities from being guesswork. You need no tool for it other than a sheet of paper, and still hardly anyone does it. A marketing agency whose representative was once a guest in this series named exactly this as the biggest benefit after implementation: sorting out what in the company is strategy and what is the day-to-day.

There is one more reason why both of these things are so hard. The board sees the company from above: the market, the competition, trends, the wide landscape. The teams are in the forest and see individual trees, their own work, which they want to do as well as they can. Connecting these two perspectives is the real work of an implementation. Without it the strategy either never gets moving or gets piled on top of the day-to-day and overloads the company. The structure of an objective helps here: a well-set one touches more than one department, so it forces a team drawn from several departments. Silos crack along the way, and that is a side effect, not the reason for doing it.

What to do about it this quarter

Start with the goal of the implementation itself. Before anyone writes the first Objective, write down how you will know OKRs are helping you and how you will know they aren't. Come back to that list every so often and hold the decisions you make along the way up against it. It sounds like a formality, and it is the only thing that lets you tell an implementation apart from yet another recurring meeting in the calendar.

Then write the OnePager: the vision, the mission, what game we are playing, how and in which markets we compete, what we focus on this year and this quarter, which hypotheses we are testing, who exactly is working on the goals. Set aside eight to sixteen hours of work for it, not a single meeting. Afterwards it takes five minutes to tell, and that is exactly the disproportion nobody expects. While you are at it, lay out responsibilities in a RACI matrix, so it is clear who is accountable for an objective and who works on it. An area that a dozen or so people are formally responsible for has, in practice, no owner.

Next, make a list of all the initiatives under way and set it against the strategic goal. Say plainly what you are not doing, and come to terms with the fact that some of the things you cut work and are well liked. A company of several thousand people went through its projects this way and cut those that didn't fit the goal, including winding down a product that was popular and in use. That was the hardest part of that implementation and also the one that brought the most focus.

Finally, the rhythm, matched to how your company really works: in production cycles, publishing cycles or seasons. The textbook pair of an annual objective plus a quarterly one is a suggestion to begin with, not a rule, because OKRs are a set of good practices, not a framework with rigid rules. Three rituals are enough: planning with agreement on the direction, a regular review by the team working on the objective, and a retrospective at the end of the cycle. Look at progress at least once a week, and at the review ask whether last week's actions brought the outcome closer, and if not, what exactly is blocking it and what we are changing in the way we work. Don't count ticked-off tasks: eighty tasks done and no outcome is a situation we have seen many times. Alongside the goals, keep a separate set of company health metrics, such as profitability and sales within the planned budget, so that you don't look at the organisation only through its strategic goals.

Who it is for and what it won't fix

The most common question from the room is whether this will work in our industry and at our size. Our practice shows that neither size nor industry decides. We have worked with companies of fifteen people up to several thousand: a software house of a hundred and fifty, an aviation software maker with more than a thousand, banks, machine manufacturing, cosmetics, e-commerce, the games industry, HR, logistics. Techramps, a maker of pumptracks and skateparks, is an example of a manufacturing company with no link to IT, and a separate text has been published about it. The only regularity we see concerns dispersion: above fifty people, the number of parallel initiatives usually gets out of control.

There is, however, a question we can't answer, and we won't pretend we can. At workshops there is usually a series of questions about wording: can a key result have no number, is an ongoing form enough, can we do it like Spotify. The honest answer is that it depends on the context, and I know how unsatisfying that is. What works at Spotify, at Google or at Netflix won't necessarily work for you, because those formulations are the result of someone else's strategic assumptions. Instead of copying the wording, recreate the thought process that led to it. For the textbook key result about processor tests it went like this: was the processor built, does it work, did it pass the test at five companies. Good enough for the period in question, not perfect.

The second thing worth knowing: OKRs usually don't replace the management frameworks you already use. They close the gap in them at board level and in the link to strategy, and that is all. They also have a hole of their own, which we added to the method only later. They lack a layer that explains to teams where these particular goals came from, so the strategy stayed in the board's heads and further down nobody could connect the dots. That is why we made the OnePager.

And the last thing we tell clients at the end. The real goal of all these rituals is the habit of asking about the outcome instead of the work done. If the habit takes hold, at some point you can stop calling it OKRs and lose nothing. An implementation after which the company no longer needs the word is a successful one.