How to run OKRs that don't rot by week three
Most OKRs die quietly: written in a kickoff doc, copied into a slide, never updated again. The fix isn't a better template — it's putting the objective on the same schema as the work, so progress rolls up by itself and a stale number is impossible.
By Dmitrii SelikhovFounder
Key takeaways
- OKRs rot because the objective lives in a different tool than the work — a doc or a slide that nobody updates — so by week three the number on the slide and the reality in the tracker have silently diverged.
- The structural fix is to make a key result a real metric with a start value, a target, and a current value, and compute percent-complete as (current − start) / (target − start) so a key result can never look further along than its numbers justify.
- Objective progress should be the live average of its key results, recomputed the instant any metric changes, not a status someone types in — that removes the single biggest source of OKR drift, the manual refresh nobody remembers to do.
- Check-ins beat status meetings: an append-only log that snapshots health, status, and roll-up progress at each update turns the quarter into an honest confidence history instead of a slide assembled the night before the review.
Every company that adopts OKRs has lived the same arc. There's an energetic kickoff where objectives get written, key results get debated, and everyone leaves aligned. Then the quarter happens. By week three the objectives live in a doc nobody opens, the key results are a row in a spreadsheet that goes stale, and the actual work — the issues, the cycles, the shipped features — lives somewhere else entirely. The OKRs didn't fail because they were badly written. They failed because they were disconnected from the work that was supposed to move them.
Why OKRs drift from reality
The root cause is almost always a tooling seam. The objective is a sentence in Notion or a slide in a deck; the work is a backlog in a tracker. Nothing connects the two, so keeping them in sync is a manual chore that competes with real work and loses. The first time someone has to hand-update a 'percent complete' field, the rot has already started — because the number is now a guess, and guesses drift toward optimism.
A key result that says 'improve activation' is unfalsifiable, and an unfalsifiable goal can't rot — but it also can't tell you anything. The opposite failure is just as common: a precisely-defined key result whose 'current value' is updated once, in week one, and never again.
Make the metric the source of truth
The fix is structural, not motivational. A key result should be a real metric: a kind (a number, a percent, a currency amount, or a simple done/not-done), a start value, a target value, and a current value the team updates as the quarter unfolds. Percent-complete is then computed, not typed — (current − start) / (target − start), clamped to 0–100 — so a key result physically cannot display more progress than its numbers support.
The objective's progress, in turn, should be the live average of its key results, recomputed the moment any value changes. No one updates the objective directly; it's always a function of the metrics beneath it. That single design choice eliminates the most common cause of OKR rot — the stale roll-up that nobody remembered to refresh.
Replace the status meeting with a check-in trail
The last piece is the narrative. Numbers tell you where you are; they don't tell you why. A check-in — a short note, optionally moving the goal's confidence to on-track, at-risk, or off-track — snapshots the health, status, and roll-up progress at that moment and appends it to a timeline. Read top to bottom, that timeline is an honest confidence history: 'on track through week three, slipped to at-risk Friday when the dependency moved, here's the plan.' That's a far better leadership artifact than a slide assembled the night before the review, and it costs thirty seconds instead of an hour.
In Planoda, Goals work exactly this way: objectives and key results live on the same schema as issues, cycles, and projects, progress rolls up automatically, and every check-in is governed by the same audit trail as the rest of the workspace. The OKR can't drift from the work because it's made of the work. That's how you run OKRs that are still true in week eleven.