Most OKRs quietly become a task list by week three. Four rules stop that.
Most OKR implementations fail the same way, and it is not dramatic.
The objectives get written in an offsite. They are reviewed enthusiastically in week two, glanced at in week six, and by week ten nobody can find the document. The next quarter, everyone agrees the problem was the tooling.
The problem is rarely the tooling. It is usually one of four things in how they were written.
This is the big one.
The test: could you achieve the key result without doing the obvious project, and could you complete the obvious project without achieving the key result? If both are yes, you have written an outcome. If either is no, you have written a task with a percentage next to it.
This matters because a task-shaped key result removes the thinking. The team stops asking whether the work is achieving anything and starts asking whether the work is finished, which is a much easier question and the wrong one.
"Improve customer satisfaction" is not measurable. "Improve customer satisfaction to 8.5" is only measurable if everyone knows what it is now.
Every key result needs from X to Y by when. Without the X, two things happen: nobody can tell in week six whether they are on track, and at the end of the quarter the score becomes a negotiation about what the starting point had been.
If you do not have a baseline, the first key result of the quarter is establishing one. That is a legitimate and common outcome, and it is far better than a quarter of numbers nobody can interpret.
A team with eleven objectives has a to-do list. The entire mechanism of OKRs is forcing a choice about what matters most, and a long list is precisely the refusal to choose.
Three objectives, three key results each, is enough for almost any team. The argument against — "but we are also doing all this other work" — is true and irrelevant. OKRs are not a description of everything that happens. Business as usual carries on without being an objective, and trying to capture it is how the list gets to eleven.
The standard failure: the executive team writes five objectives, each function takes one, each team under that function takes a slice, and by the third level people have key results they cannot influence.
A cascade works the other way. The level above shares what it is trying to achieve and why; the level below proposes how it contributes and what it will measure. It takes longer and it produces objectives that the people holding them actually believe.
The practical test is traceability in both directions. Every team objective should point at a company objective. Every company objective should have visible contributors. An orphan at either end is a real finding: a team working on something nobody has connected to the strategy, or a strategic priority nobody is resourcing.
The convention that 0.7 is a good score for a stretch objective is widely quoted and widely misapplied.
It works only if the culture genuinely treats 0.7 as success. If missing targets carries any consequence at all, people will set targets they can hit, and the scoring convention becomes a way of hitting 1.0 on a soft goal while calling it a stretch.
Either commit to it properly — make it visible that nobody is penalised for 0.6 on something ambitious — or drop the stretch framing and set targets you intend to hit. The failure is the middle: stretch language with accountability consequences, which reliably produces sandbagging.
The review that keeps OKRs alive is short and frequent: confidence level, what changed, what is blocked. Five minutes per objective.
Review quarterly and you find out in week twelve that something was never going to land, which is precisely too late to do anything about it.
The [OKR & Goal Cascade](/products/okr-and-goal-cascade.html) enforces baselines and targets, traces every team objective to a company one and flags the orphans in both directions, and tracks confidence weekly — with a worked example including an objective that is going to miss. £26.