OKRs and goal management: the practice of making goals visible

OKR is a method for writing goals down and making progress visible. It looks simple and is hard to apply — because the difficulty isn't in the software but in how the goal is written.

Objectives versus key results

An Objective is qualitative, gives direction and should be motivating: "Make customer support the fastest in our sector."

A Key Result is quantitative, measurable and not open to argument: "Reduce average first response time from 6 hours to 2."

The most common mistake is writing a task instead of a key result. "Install the new support software" is not a key result — you can measure whether it was done, but not what it achieved. The software can be installed and response times may not change at all.

A practical test: if what you wrote doesn't end in a number, it probably isn't a key result.

The quarterly cycle

OKRs run quarterly, not annually. Three months is close enough to plan for and long enough to produce meaningful change.

The cycle has three moments: setting (first week of the quarter), mid-point check (once in the middle) and closing (last week). Skipping the mid-point check is the most common failure; if goals are remembered in the final week, OKR becomes a reporting ritual.

How many goals?

Few. More than three objectives per team guarantees loss of focus. Three to five key results under each objective is enough.

A team with fifteen objectives really has none; they're all equally important, which means none is a priority. The main benefit of OKRs is telling you what you won't do.

Transparency: how far?

The power of OKRs is visibility — when one team can see what another is working on, dependencies surface early. Making company and team objectives open to everyone is usually the right default.

But there is a limit. Individual goals shouldn't be public; the person, their manager and HR is enough. And objectives containing sensitive business information — an acquisition discussion, a restructuring — should stay restricted.

That distinction must be enforced in the data layer rather than by hiding in the interface — our security approach rests on that principle.

Scoring and the honesty trap

The common practice is to score each key result between 0 and 1 at quarter end, with around 0.7 treated as good. The logic: goals should be ambitious and not always fully met.

The trap here is clear: if the OKR score is tied to performance reviews and bonuses, everyone writes goals they're certain to hit. In a system where ambition is punished, ambition disappears.

That's why OKRs and performance reviews should be kept apart. They can look at the same data, but they shouldn't be the same formula.

Updating progress

Key-result progress is updated by hand, and that slips in most companies. Two practices help: tying the update to a weekly rhythm (the first five minutes of the team meeting) and making un-updated goals visible in the system.

Automatic integrations are tempting but rarely pay off; most measured metrics live in different systems and the cost of connecting them exceeds the cost of typing a number.

Three common mistakes

Turning every job into an OKR. Routine work isn't a goal. Issuing invoices is not a key result; it's the job.

Imposing from above. Team objectives should align with company objectives but be written by the team. OKRs handed down aren't owned.

Skipping the close. If "what happened and what did we learn" isn't discussed at quarter end, the next quarter's goals repeat the same mistakes.

Are individual goals needed?

Most companies apply OKRs at team level and set no individual goals. The reasoning is sound: individual OKRs easily become a task list and blur into performance review.

Where an individual goal is genuinely useful is development — "this quarter I'll build this skill". Keeping that in a development plan rather than inside OKRs is a cleaner separation; the two run on different rhythms and are followed by different people. We cover the learning side in our training article.

Measurement

Three indicators for evaluating the OKR system itself:

• Update rate — the share of key results with updated progress at the mid-point check.
• Closing rate — the share of objectives scored at quarter end.
• Goal-count distribution — the proportion of teams with more than three objectives; an early indicator of a focus problem.

We recommend leaving this module to the second wave; the reasoning is in the 90-day plan.