Interventions as Constraint Changes
The temptation, having read the system, is to fix it. Add a training programme. Change the template. Pick a different framework. Run a workshop.
These rarely work. The system is producing the pattern not because it has the wrong tools but because it is operating under constraints that make the pattern the path of least resistance. The pattern is not a bug. It is the system at equilibrium.
What does work is changing the constraints. Not the tools, not the templates, not the framework. The shape of what is and is not possible inside the system.
Three constraints decide whether OKRs do their two functions. When all three are present, the healthier patterns become more likely. When any one is missing, one of the four signals from the previous section will appear, reliably, regardless of how good the OKR teaching has been.
The three are: visibility, rhythm, and safety.
Visibility
Visibility is the constraint that makes the implicit explicit.
Most OKR failures are failures of visibility before they are failures of anything else. The pattern persists because something important is being hidden - by accident or by design - and the hiding lets the pattern continue.
Three things specifically need to be visible:
The distinction between commitment and aspiration. Doerr's original framework distinguished commit Key Results (must hit, scored against 100%) from aspire Key Results (stretch, expected to fail roughly thirty per cent of the time, scored against 70%). Most organisations drop this distinction in implementation. The result: every KR gets treated as a commit KR, every miss reads as failure, and teams write conservative KRs to protect themselves. The distinction has to be visible in the artefact and the reporting both. Hidden, it is worse than absent - it suggests one thing while operating as another.
The link between decisions and Key Results. When work is cut from a backlog, the reason on the card should reference the KR: does not move KR3. When new work is accepted, the same: moves KR2. When neither applies, that is a question worth raising. The KR becomes an anchoring instrument by being used as one, visibly, until trust accrues. Without this, KRs decay into ceremony within two cycles.
The proxy when the real measure is not available. Most teams do not have the measurement infrastructure they would ideally want. The honest move is to name the proxy you will use until the real measure exists, and to track the gap as a deliverable in its own right. The proxy is defensible. The dishonest alternative is to write the KR as if the proxy is the goal, which is how outputs dressed as outcomes get manufactured.
Visibility is the easiest of the three constraints to build at the team level. It does not require permission. It does require sustained discipline - the visibility move loses force the moment it becomes optional.
Rhythm
Rhythm is the constraint that brings OKRs inside the operating cadence of the work.
Set and forgotten is a failure of rhythm. It happens because OKRs live in a quarterly cycle while the team's operating rhythm runs on weeks. If the OKRs are not surfaced inside the weekly rhythm, they disappear from working memory within a fortnight. After two weeks of not being mentioned, they are functionally gone until the next quarterly ritual recovers them.
This is not a discipline failure. It is a structural fact about how attention works in groups. Things outside the rhythm do not get attention. Things inside it do. The question is where the OKRs sit relative to the rhythm, not whether the team cares about them.
Building rhythm means putting OKR review inside recurring operational events. Weekly tactical check-ins. Backlog refinement that names the KR each story contributes to. Mid-quarter retrospectives on the OKRs themselves, not only on the work. Quarterly retrospectives that update the strategy rather than only reporting on it.
This is the constraint most amenable to unilateral team-level action. A team lead does not need permission to bring OKRs into the team's standup. A product owner does not need a programme to tie backlog refinement to KRs. The structural moves are simple. They die only when somebody stops insisting on them.
The system-level version is harder. It requires that OKRs become the default object of leadership reporting rather than projects, programmes, or initiatives. Inverting that is a substantial change. It will not happen unless the senior layer commits to it. But the team-level rhythm can be built without it, and the rhythm at the team level is most of the prize.
Safety
Safety is the constraint that makes missing a Key Result cost-free.
Safety is the hardest of the three to build, because it requires letting go of the very thing OKRs are often adopted for. OKRs frequently get rolled out as a tool to drive accountability, with accountability quietly meaning consequences for individuals when targets are missed. Safety, in this sense, is the precise thing many OKR rollouts are designed to remove.
Until safety exists, every other constraint is partially defeated. A team with weekly check-ins but no safety will check in conservatively, hiding bad news. A team with strong visibility but no safety will write KRs that hide their real ambitions. The two functions of OKRs both require that the people writing the OKRs can be honest about what they intend and what they would decide. Without safety, honesty is unaffordable.
Building safety means formally decoupling OKRs from performance review - not as policy on paper but as practice that holds when it is tested. It means refusal protocols: teams need a structured way to decline a corporate Objective that does not fit, or a parent KR they cannot move. It means leadership demonstrating publicly that stretch failure is acceptable, by missing their own stretch KRs visibly and explaining what they learned.
The team-level moves are smaller but real. Holding the commitment-aspiration distinction in defence of stretch failure. Framing KRs with the user, not the team, as the subject - a system property rather than a performance measure. Refusing to bring missed KRs into one-to-ones, calibration discussions, or feedback. None of these solve the system-level problem, but they shift the team's local experience of safety, which is most of what teams actually experience.
The honest version of safety advice: this is hard, and the alternative is harder. Decoupling OKRs from performance review creates a different problem - leaders lose a clear mechanical performance signal. The replacement (one-to-one conversations, behavioural observation, peer feedback) is harder, less mechanical, and culture-dependent. It is also the only way OKRs become honest. There is no costless version.
Why "constraints" rather than "fixes"
The vocabulary matters. The three forces are not interventions in the usual sense. They are not actions you take and then complete. They are conditions you maintain.
A constraint is a shape that the system operates inside. It does not determine what the system does; it shapes what is and is not possible. Visibility does not force teams to make decisions visibly - it makes invisible decisions harder to sustain. Rhythm does not force OKRs into the operating cadence - it makes their absence from the cadence more visible. Safety does not force honest OKR drafting - it removes the incentive for dishonest drafting.
The shift from "fixes" to "constraints" is the shift from mechanical thinking to systemic thinking. A fix is a one-time action; a constraint is an ongoing condition. A fix targets a symptom; a constraint shifts what the system tends toward. A fix can be completed; a constraint has to be maintained.
This is also why "rollout" is the wrong word for OKR adoption. You do not roll out a constraint. You commit to it, you maintain it, you defend it when it is challenged, you notice when it has eroded and you rebuild it. The work does not end. It changes shape.
When the constraints conflict
The three constraints sometimes pull against each other. Three tensions worth holding.
Visibility and safety. Making decisions and scoring visible can feel like surveillance. The more visible the work, the more exposed the people doing it. Mitigation: visibility should be of the work, not the worker. A scoring system that shows the KR scored 60% is visibility. A scoring system that shows who missed the 60% is surveillance.
Rhythm and drift. Frequent OKR review can degenerate into constant OKR rewriting. KRs become moving targets that cannot be planned against. Mitigation: review rhythm is for surfacing progress and blockers, not for changing the OKRs. Changes happen at retro cycles. The check-in confirms what the OKR is; the retro changes what it should be.
Safety and accountability. Decoupling from performance review can feel like decoupling from accountability altogether. Mitigation: accountability for how the team works - showing up, peer collaboration, learning behaviour - is separable from accountability for what the team hit. Performance management belongs to the first. OKRs belong to the second. Conflating them is what produces the stick problem in the first place.
If all three constraints look easy to maintain in your organisation, at least one of them is not really there.
Last updated 15 May 2026
Licensed under CC BY-SA 4.0.