When OKRs don't work, it is almost never about OKRs. It is about what is missing beneath them

In the textbook the mechanics of OKRs look simple, and that is their trap. It is like a recipe: chop, put in the pan, fry, done. Until you start cooking, you don't see that the result depends on the temperature of the pan, the sharpness of the knife and how finely you chop. A head chef sees these things at once, because they have done them a thousand times. Someone cooking for the first time has no way of seeing them, and that is completely natural. Implementing objectives is the same: the recipe is short, and the details that decide the outcome run into the hundreds.

That is why, when someone asks why objectives don't work for them, the answer almost never lies in the objectives themselves. It lies in the strategy, in people's skills or in the board itself. OKRs don't create these gaps, they only make them visible, and that is probably the most uncomfortable property of the method. You take a tool for working with objectives and you get a diagnosis of the whole organisation.

I write this without a trace of superiority, because for years we ourselves talked mainly about the mechanics. Mechanics can be described, so they get described. There was one thing we couldn't really solve for a very long time: how to connect quarterly objectives with the company's day-to-day, with what people actually do on Monday morning. That period left a mark we still haven't cleaned up. What we do at the end of the quarter we call a retrospective, although it is not a retrospective in the sense most people know. I come back to this below, because that confusion over the name genuinely damages companies' implementations.

This text is meant to give you a tool for running such an audit yourself. It doesn't describe how an implementation unfolds when it goes well. It describes where to look for the cause when it has stalled and nobody in the company can say why.

Five pillars, and OKRs sit in only one of them

When we work with a company on an implementation, we don't work on objectives. We work on how the whole organisation functions, and we break that down into five pillars: the foundation, strategy iteration, operations, skills development and culture, and a learning system. OKRs live in the second of them. If any of the others is missing, the implementation is sabotaged from within, and you only see it after a quarter or two, when everyone is already tired and blaming the method.

The foundation is mission, vision and values, but above all one thing: assessing whether the owners and the board agree on the direction. At this stage it regularly turns out that board members have different ideas about where the company should get to and by which route. Not radically different, simply different, and nobody has ever set them side by side out loud. That disagreement doesn't stay at the top. It moves down and turns into objectives nobody can justify.

The foundation also holds something that sounds like an academic exercise but is very practical: linking the horizons. A vision is a twenty-year perspective, a strategy two to three years, and OKRs live only at the level of the year and the quarter. Between where the company is and where it wants to be stand specific problems and blockers, and only mapping them lets you choose objectives. Many companies know the destination itself: we want thirty per cent higher revenue and so many employees. Nobody has asked what specifically is stopping them from being there today.

The remaining three pillars are the part that gets talked about least in connection with OKRs. Operations, the company's daily life: key performance indicators, finances, mapped processes, tools and project portfolio management, because alongside strategic projects a company always has non-strategic ones, and resources have to be found for both. Skills development and culture, meaning work with leaders and building the independence without which team autonomy is just a word. And the learning system: written-down assumptions, conclusions from retrospectives gathered in one place, and a separate question of whether the system of working with objectives still helps the company make the change it was introduced for.

What to do about it this quarter

Start with something that looks like a formality and decides everything else: state plainly the goal of the implementation. Why we are introducing OKRs and how we will know the organisation works better. Without that sentence you can't assess any quarter, because there is nothing to compare it with. Then go through the list of elements of the system and mark the ones you clearly don't have or that are worth a closer look. That is the whole audit, and it really fits into one evening.

Write objectives together with the people close to execution. Neither the model in which the board arrives with ready-made objectives and says get on with it, nor the one in which ideas flow only from the bottom, gives you shared understanding, and that is what this is about. The board works out what it thinks is the best thing the company could do this year, but it brings this as a draft, not as revealed truth, and tests it against the people closest to delivery, because they know the blockers best. Next to every agreed objective, write one sentence of hypothesis, one that can be answered yes or no after the quarter. In a manufacturing company it might read: if we build a proof of concept of the product with the new functionality, we will leave the competition far behind. The quarterly objective is then building the product, but it is the hypothesis underneath that says what you are actually testing, and it tells you when to stop if the supplier starts running late or the first tests with a customer show something other than you expected.

At the end of the cycle ask about assumptions, not moods. What the hypothesis was, what objective came out of it, which actions confirmed or disproved it and what follows for the next quarter. That is a different conversation from the one about who was late and which supplier missed a deadline, and it needs a different facilitator: someone from outside the team, and if there is no such person, let the objective owners run retrospectives for each other. Collect the conclusions in one place, so that you can go back to what the company has already established once. And separate three things that in many companies sit in one spreadsheet: indicators of the company's current performance, strategic goals and OKRs. They are not the same thing, and lumped together they turn a meeting into a conversation in which everyone is talking about something different.

That leaves the hardest thing to organise: attend team meetings in a supporting role, not a controlling one. In one team, a person spent two weeks sorting cells in Excel by hand to pick out data. Their manager did it the same way and didn't know it could be done differently, so the only idea they had was to add a second person to the sorting. From outside it looked like a lack of commitment and yet another delay. This is not a story about incompetent people, but about the fact that nobody had any way of knowing. You can see the same mechanism in marketing and sales, where a team changes the look of the website or sets up campaigns although it has no value proposition, no personas and no knowledge of where clients really come from, so a change at that level won't achieve anything anyway. Skills gaps only come out while an objective is being delivered, they are visible from the side and never from a report, and the response should be a pointer, not a judgement. While we are at it, be careful with the word micromanagement itself, because it has become a catch-all: asking how the objective is going gets called that in companies that simply have no monitoring routine in place.

When it really isn't the implementation's fault

There is one case in which the answer to the question in the title is different, and it is worth naming plainly. If a company is run by someone who wants single-handed control over everything, OKRs will be a terrible tool and not worth implementing. Not because that way of running a company is worse. Because this tool works where the leader wants to share responsibility and decision-making, and for someone who doesn't want that, it will only get in the way. The exception is a leader who wants to change in this respect, and then it is a completely different conversation.

The second point concerns industry, because there is a persistent belief here that costs companies a good deal of time. OKRs are not a tool for IT and innovative companies. Lately we have been working a lot with manufacturing, in companies with revenues of thirty to one hundred and fifty million, and there they are more pleasant to implement and work better than in IT. We don't have a ready theory for this, and I won't pretend to know whether it is a matter of the people, the mindset or the motivation to work itself.

Outside these two cases, the readiness question leads nowhere, and it is better to ask what problem you want to solve. If the answer is: we do too many things at once and finish nothing, or: we grew fast, and now growth has stalled, communication has become cramped and the bottlenecks are visible, that is exactly the situation in which working with objectives helps. And the answer to the question of how hard it will be is never we'll manage it or we won't. It is: how many things you will have to deal with along the way. That is a less impressive answer than a list of good practices, but it is the only one you can check for yourself.