OKRs do not arrive as a reporting tool. They arrive as a way to set direction — to say, out loud and in shared language, here is what we are trying to achieve and how we will know if we did. In year one, they usually work. In year two, something starts to shift. By year three, the quarterly OKR cycle has the energy of filing a tax return.
The shift is so gradual that almost nobody notices when it happens. There's no meeting where someone proposes "let's turn our OKRs into a reporting exercise." It just happens, quarter by quarter, until the goals that were supposed to focus the company's attention have become a status ritual that consumes attention instead.
The signs
If you've worked at a company in year three of OKRs, you recognise these.
Updates happen on a schedule, not when something changes. Every Friday afternoon, the team lead asks for OKR updates. People type in progress percentages whether or not anything meaningful happened that week. The percentages drift up smoothly across the quarter, never anchored to specific events in the underlying work.
The language shifts from learning to accounting. In year one, OKR updates sound like we tried X, it didn't work the way we expected, we're pivoting to Y. In year three, they sound like progress is at 67%. The first is information. The second is paperwork.
Leadership starts asking for the deck rather than scheduling a decision. The OKR review becomes a document that gets circulated, scanned, and acknowledged with "looks good." There is no meeting attached to it because the meeting wouldn't change anything. Everyone already knows what the deck will say.
No OKR has been killed or substantially rewritten mid-quarter in anyone's memory. The OKR you set in January is the OKR you're reporting against in March, regardless of what you've learned. Real direction-setting tools change. Reporting templates don't.
If you can check three of these, your OKRs are no longer doing the job they were hired for.
Why it happens
The shift from direction to documentation is almost always driven by organisational pressure that nobody intended to apply.
Leadership wants visibility into how the company is doing. Visibility gets operationalised as regular reporting. Regular reporting gets standardised into a template. The template gets filled in every Friday because Friday is reporting day. The OKRs, now embedded in a reporting cycle, stop being questions ("are we making the right bets?") and become answers ("here is our progress on the bets we made in January").
The instant an OKR template becomes the easiest way to keep leadership happy, the OKR's job changes. It is no longer there to focus the team. It is there to feed the template. And once that flip has happened, it doesn't reverse on its own.
The deeper problem is that OKRs written for reporting drift toward being easier to report on. The stretch ambition gets quietly trimmed. The key result becomes a milestone, because a milestone is easier to mark complete than a metric is. The milestone becomes a task, because a task is easier still. By the end of year two, the OKR is functionally a project plan with the word "objective" pasted on top.
The fix is not a better template
The instinct, when you notice this happening, is to redesign the OKR structure. Tighter key results. Clearer success criteria. Better measurement. Maybe a new tool. That instinct isn't exactly wrong, but it addresses the symptom and not the cause.
The cause is that OKRs are being used as a reporting output when they should be used as a decision input. The fix is to treat OKRs as a trigger for a conversation, not a container for progress percentages.
In practice this means the OKR review is structured as a decision meeting, not an update session. The opening question is not "where are we?" — the system already shows that. The opening question is "what does this tell us about what we should change?" If nothing needs to change, the review takes fifteen minutes and people get on with their week. If something needs to change, the review produces a decision: a kill, a pivot, a re-scoping, a re-allocation. The decision is logged and acted on before the next cycle.
This is psychologically harder than running the reporting version, because the reporting version never asks anyone to make a real call. It just asks them to type in a number. The decision version forces actual judgement, which is uncomfortable, which is why most companies stop doing it after a couple of cycles unless the structure protects against the drift.
What makes the structure protect itself
When OKRs live next to the work — when the connection between a key result and the work meant to move it is structural rather than manual — progress is visible without an update ritual. The percentage isn't typed in by a human. It's a property of the underlying data. The Friday-afternoon ceremony goes away because there is nothing to do — the system already shows what's happening.
That frees the cadence to do what it should be doing in the first place: making decisions. The weekly review stops being "let me read out the numbers" and becomes "given what the numbers are showing us, what are we changing?" The quarterly review stops being "let's reconstruct the quarter from the deck" and becomes "given what we now know, what should the next quarter's bets be?"
That's what OKRs were supposed to do. Most companies have lost it, and the path back isn't a redesign. It's an architectural shift.
The Vindaris view
We don't build OKR software. We build the layer underneath — where goals live next to the work that's supposed to move them, where progress is computed from reality rather than typed in by humans, and where the review cadence is freed to do decisions instead of reporting.
The OKR that triggers a conversation is doing its job. The OKR that fills in a percentage is paperwork in disguise. The difference is rarely in the OKR itself. It's in the system underneath it.