← All posts
Frameworks   May 12, 2026 · 5 min read

OKRs aren't broken — the architecture around them is

Generated illustration for the post OKRs aren't broken — the architecture around them is

Spend ten minutes searching Reddit for OKRs and you'll find some of the most exhausted writing on the internet. Total bullshit. Moves the goalposts. Forgotten by week three. We wrote them in January and never opened the doc again. The sentiment is genuine. Operators are not making this up. But the diagnosis is almost always wrong — and the wrong diagnosis is why the next framework you try will fail in exactly the same way.

What the backlash is actually about

When operators say "OKRs don't work here," they almost never mean the verb-noun-number structure failed them. Nobody is fundamentally opposed to writing down a measurable outcome and tracking progress against it. What they mean, when you push past the first sentence, is something more specific:

We wrote them in January and looked at them in April. Half of them had no real owner — just a team name. The work that was supposed to move them was happening in a different tool, owned by different people, on a different cadence. By the time someone reconciled the goal tracker with reality, the quarter was already decided. The meeting where we discussed it was a post-mortem dressed up as a review.

That is not an indictment of OKRs. That's an indictment of an architecture where the goal lives in one system, the work lives in another, and a Chief of Staff bridges the two by hand at 9pm on Sundays. The framework worked fine in the doc. The operating model around it never closed the loop.

Why the next framework won't save you

Companies that abandon OKRs usually replace them with something — KPIs, Hoshin Kanri, NCTs, V2MOMs, the new acronym their VP of Strategy brought from her last job. The pattern is identical. Six months in, the new framework feels just as detached from the work as the old one did. Why? Because the framework was never the problem. The split was.

A goal-tracking layer that doesn't own the work layer is structurally incapable of telling you whether you're going to hit the goal. It can only tell you, after the fact, that you didn't. That's true whether the goal is called a KR, an MBO, a North Star metric, or a Hoshin breakthrough objective. The label changes. The architectural failure doesn't.

Why competitors keep losing this argument

The OKR vendor response to the backlash has been to add features to the tracking layer. AI summaries. Sentiment heatmaps. Executive briefings. Slack bots that nudge owners. None of it changes the underlying split: OKRs over here, work over there, an integration in the middle that nobody fully trusts and that breaks the third week of every quarter.

A heatmap that turns red is a thermometer. It tells you something is wrong. It doesn't tell you which work to start, stop, or reassign. The doctor lives one layer down — in the work itself, in the capacity model that says who can actually do that work this week, in the ownership graph that says whose performance review depends on the answer.

The architecture that actually fixes it

Three properties, none of them feature-level, all of them structural:

One graph. Goals and the work meant to move them are the same data structure — not two structures joined by a connector that runs every fifteen minutes and silently fails on Tuesdays. When the work item moves, the goal it's tagged to knows. When the goal is at risk, you can see the work that was supposed to move it without changing tools.

One named owner per KR. Non-negotiable. Contributors are listed explicitly and separately. "The growth team" is not an owner. A named human whose week is meaningfully different if this KR moves is an owner. Everyone else is helping.

One Monday-morning view. Every leader can see, in one place, the work currently moving each goal, the goals that have no work pointing at them at all, and the work that's happening with no goal attached. That third bucket is usually the most expensive thing on the screen, and most tools don't even render it.

Get those three architectural properties, and the framework you keep on top — OKRs, KPIs, Hoshin, whatever — starts behaving the way it was designed to. Skip them, and no framework will save you. The next acronym will fail for the same reason the last one did.

The Vindaris view

OKRs are a perfectly reasonable goal-setting framework. They are not, and were never meant to be, an operating system. The mistake the category made was selling them as one — and then building tools that track the framework while ignoring the operating reality underneath. If you're tired of OKRs, you're probably not tired of OKRs. You're tired of running a strategy on top of an architecture that was never designed to execute it.