Business-as-Usual Has Its Own Approach
OKRs drive transformative change; business-as-usual needs its own, different approach, a metrics model, a KPI scorecard, team-health monitoring and root-cause fixes. Misunderstanding this one distinction causes many failed OKR implementations.
This is the principle whose absence quietly kills more OKR rollouts than any other. A team learns about OKRs, gets enthusiastic, and dutifully writes objectives for everything it does, keeping the servers up, answering support tickets, closing the books, running the campaigns. Within a quarter it has fifteen "objectives", most of them describing routine work, and the framework collapses under its own weight. The problem was never the OKRs. It was pointing them at the wrong kind of work.
Two kinds of work, two kinds of management
Every organisation does two fundamentally different kinds of work. There is change: the breakthrough goals that move the organisation somewhere new, which is what OKRs are for. And there is business-as-usual: the ongoing work that keeps the business healthy and must stay good, which needs a completely different toolkit, a metrics model, a KPI scorecard with thresholds, team-health monitoring, and root-cause fixes when something breaks. Managing the two the same way is like using a map when you need a thermostat: right instrument, wrong job.
Why conflating them fails both
Force routine work into OKRs and two things break at once. The OKR system loses focus, because the wildly important handful is now buried under operational noise, and nothing gets the concentrated attention that change requires. And the routine work is managed badly too, because a quarterly, ambition-shaped goal is the wrong tool for something that needs a steady threshold and a fast response when it dips. You end up doing both jobs poorly with one instrument, when two instruments would do both well.
The test, and the edge case
The quickest test is the Opposite Test: would a sane rival choose the reverse? "Keep uptime above 99.9%" fails, nobody chooses downtime, so it is business-as-usual and belongs on the scorecard. "Become the most reliable platform in our category" passes, it is a genuine choice with trade-offs, so it can be an OKR. The edge case is deliberate: sometimes a team decides to make a step-change in an operational area, and that is a real OKR, an operational excellence OKR at team level, until the new level is reached and it returns to the scorecard.
Let each do its job
Reserve OKRs for breakthrough change, and let scorecards run the day-to-day. This is not a demotion of routine work, it is the opposite: business-as-usual is what keeps the company alive, and it deserves an approach designed for it rather than a borrowed one. Get the split right and both halves improve: the scorecard keeps the engine healthy, and the OKRs, freed from operational clutter, can actually move the few things that matter.
A platform team writes six OKRs: four are uptime, latency, ticket volume and cost (all business-as-usual, moved to the scorecard). Two remain: "make the platform self-serve for enterprise admins" and a deliberate reliability step-change. Freed of the routine four, the team actually delivers the two that matter.
How do I tell an OKR from business-as-usual? +
Run the Opposite Test. If no sane rival would choose the reverse ("keep uptime high"), it is business-as-usual for the scorecard. If it is a genuine choice with trade-offs, it can be an OKR.
Where does routine work go if not in OKRs? +
On a KPI scorecard with thresholds, owners and root-cause fixes. That is the right instrument for work that must stay good, and it frees OKRs to focus on change.
Can operational work ever be an OKR? +
Yes, when you deliberately drive a step-change in it, an operational excellence OKR, until the new level is reached, after which it returns to the scorecard.
From the ZOKRI OKR Handbook, the methodology we install and maintain. Written by Matt Roberts.
A UK-based strategy and OKR consultant and two-time SaaS founder with a venture-backed exit, Matt turns strategy into execution for teams scaling from tens to thousands. He co-founded ZOKRI in 2018, having previously co-founded Linkdex, a venture-backed enterprise SaaS platform he led to a trade sale. He writes the methodology behind these notes.
Most failed rollouts drown OKRs in routine work. We draw the line between change and business-as-usual, build the scorecard for one and the OKR engine for the other, so both actually work.