What is an OKR?
An OKR, short for Objectives and Key Results, is a goal-setting method that pairs one Objective with a small number of Key Results. The Objective is a short qualitative statement of what you are trying to achieve, written so that anyone in the organisation can understand it. The Key Results are the measurable outcomes that would prove you achieved it, usually two to five of them, each with a number attached.
The structure is deliberately simple. The Objective answers "what are we trying to do", and the Key Results answer "how will we know we did it". A goal without the second half is an intention. A number without the first half is a metric with no purpose behind it.
A worked example
An Objective might be "Make onboarding something new customers finish without help". That is qualitative, it is memorable, and it says nothing about how it will be measured.
The Key Results attached to it might be: reduce median time to first value from 11 days to 3; raise the proportion of accounts completing setup without contacting support from 40 per cent to 75 per cent; and cut onboarding-related support tickets per new account from 2.4 to 0.8.
Each of those is a number that moves, each has a baseline and a target, and none of them is a task. "Rewrite the onboarding emails" is work you might do to move a Key Result. It is not a Key Result itself, and mistaking one for the other is the most common error in the method.
Where OKRs came from
OKRs grew out of the management system Andy Grove developed at Intel in the 1970s, built on Peter Drucker’s earlier Management by Objectives. John Doerr, who learned the method at Intel, introduced it to Google in 1999, and Google’s use of it is the reason most organisations have heard of OKRs at all.
That lineage matters for one practical reason. The method was designed inside companies that were changing quickly and needed a way to point a lot of people at a few things. It was not designed to track business as usual, and most of the trouble organisations have with it comes from using it for exactly that.
Why most OKR programmes fail
The most common failure is using OKRs for work that should be tracked as KPIs. Uptime, gross margin, customer satisfaction and monthly revenue are ongoing health measures that should be monitored continuously. Dressing them up as quarterly Objectives produces a list that never really changes, quarterly reviews that nobody learns anything from, and a growing sense that the whole exercise is paperwork.
The second failure is volume. An organisation with thirty Objectives has no priorities, it has a list. The method only does its job when the number is small enough that dropping one feels like a real decision.
The third is treating Key Results as a task list. If a Key Result can be completed by someone ticking it off, it is an action, not an outcome. Key Results are numbers that move, and the work that moves them sits underneath.
The fourth is scoring theatre. Some organisations aim for ambitious OKRs where scoring 0.7 is a good result, others expect 1.0 and treat anything less as failure. Both work. What does not work is leaving it unsaid, so that people quietly set targets they know they will hit, and the ambition the method was supposed to create disappears.
OKRs and KPIs are not the same thing
A KPI is an ongoing measure of health: something you watch continuously and want to stay in a good range. An OKR is a time-boxed commitment to change something. Revenue per customer is a KPI. "Raise revenue per customer from $4,200 to $5,500 by the end of the quarter" is a Key Result.
Most organisations need both, and the mistake is not having both, it is making everything one or the other. Forcing steady-state measures into OKRs produces the stale list described above. Leaving genuine change initiatives as KPIs means nobody is accountable for moving them.
Should your organisation use OKRs?
OKRs work well when something genuinely needs to change, when the change crosses more than one team, and when leadership is prepared to say what is not a priority. They work badly as a universal reporting format applied to every team regardless of what that team does.
It is entirely reasonable for part of an organisation to run OKRs while another part runs KPIs and quarterly priorities. A sales team with a stable process and a number to hit does not need Objectives. A team rebuilding how the product is delivered probably does.
OKRs in Empiraa GPS
Empiraa GPS supports OKRs with owners, check-ins and progress that updates from the systems the work actually happens in, rather than from a monthly chase.
GPS is deliberately framework agnostic, which matters more here than it sounds. Because it also supports KPIs, quarterly priorities and custom models, the parts of the organisation that should not be running OKRs do not have to pretend they are. That removes the single most common cause of OKR programmes quietly dying in their third quarter.