10 Most Common OKR Writing Mistakes

Niklas Olsson Niklas Olsson
Writing OKRs May 17, 2026 12 min read
Flat illustration of two people sorting OKR shapes into clean and discarded piles, representing common OKR mistakes.

When teams struggle with OKRs, the framework is rarely the problem. Most of the difficulty comes from how the OKRs were written. A set of OKRs that looks reasonable on the page can quietly undermine focus, check-ins, and team engagement for an entire quarter.

This article walks through the ten most common OKR mistakes we see when teams put their goals on paper, what each one costs you a few weeks later, and how to recognise them in your own draft. It is meant as a self-review tool, not a verdict on your team.

One simple habit makes most of these mistakes obvious before you commit. As you read each draft OKR, picture yourself in the next check-in, talking your team through it. Will this OKR create focus? Will it spark a real discussion about progress? Will it tell the team what to do next week? When the honest answer is no, the OKR almost always needs rewriting. We will come back to this check-in test throughout the article.

1. The OKRs are a task list, not goals

This is by far the most common of the OKR mistakes we see. The team sets out to write OKRs and ends up with a project plan, where every key result is an activity the team intends to do rather than an outcome the team wants to reach. Once that happens, the OKRs add nothing on top of any decent project management system. You have lost the goal management perspective that made OKRs worth introducing in the first place.

Objective Improve our website performance to drive more leads

  • Complete a website update by [date]
  • Update 10 blog articles
  • Engage an agency for outreach before [date]

In the version above the team is busy. It is just not clear from the OKR whether the busy work moved the needle. Rewriting the same objective with outcome key results changes the conversation.

Objective Improve our website performance to drive more leads

  • Grow monthly inbound leads from the website from 80 to 150
  • Lift the lead-magnet landing page conversion rate from 1.2% to 2.5%
  • Reduce bounce rate on the top 10 landing pages from 70% to under 55%

The website update, the blog articles, and the outreach agency are still likely to happen. They have moved to where they belong, the team’s plan of work, not the OKR itself.

2. Key results that can’t be measured

Unmeasurable key results come in two flavours. The first is a key result with no metric attached at all, where the team realises in check-ins that there is nothing to read off. The second is a metric that is technically there but ambiguous, where nobody can quite agree on what it counts. Both fail in the same way, the team cannot honestly say whether anything is moving.

Objective Sell more to our current customers by improving our processes

  • Send 10 proposals to old customers
  • Engage in 50 meetings with satisfied customers

Who counts as an “old customer”? What makes a customer “satisfied” for the purposes of this key result? The team will spend check-ins arguing about the definition rather than discussing progress.

Objective Sell more to our current customers by improving our processes

  • Grow expansion revenue from existing customers from €80k to €130k this quarter
  • Lift net revenue retention from 101% to 108%
  • Reach a 15% upsell rate among customers in the renewal window this quarter

Each key result now has a number you can read off a system, a starting point, and a target. Disagreements move to where they should be, on the strategy, not on the definitions.

Close-up of a person reviewing a printed OKR draft with a red pen, mid-correction.

3. Workshop ambition that overshoots reality

Workshops have a way of pulling ambition upwards. Energy builds, optimism is high, and what looked stretching at the start of the morning has become aspirational by the end. The OKRs that come out of that mood are often unreachable in any honest sense. By week three the team has stopped believing in them, and an OKR you do not believe in cannot focus you.

It is easier than it feels in the workshop to take on too much. The honest read on whether the OKRs were set too high usually only arrives a couple of weeks into the quarter, sometimes a month, once the team has started the work and seen how much of it there really is. The workshop room and the working week paint very different pictures of what is reasonable.

4. Too many OKRs

On paper four objectives with four key results each looks lean. In a 30-minute check-in it means just over a minute per key result. The team never has time to discuss what to do next, to surface blockers, or to recognise something that moved. The check-in becomes a status report, engagement drops, and so does the impact of the OKRs.

A practical ceiling for most teams is two to three objectives, with two to four key results each. Less is more here. If you cannot decide which of five objectives to cut, that itself is a useful conversation about priorities.

Flat illustration of two people untangling a knot of cords into clean parallel strands, representing clarity in OKR writing.

5. The manager drives the whole process

OKRs work when the team feels ownership of them. When the manager writes them in isolation and presents them to the team, the OKRs become another set of priorities passed down from above. The team treats them as the manager’s tool, not their own. Check-ins turn into reports rather than working sessions, and the energy that comes from a team chasing its own goal is lost.

The fix is to let the team co-write the OKRs. The manager still frames the strategic direction, sets the boundaries, and challenges weak formulations, but the wording, the targets, and the path are written together with the people who will actually do the work.

Get a second pair of eyes on your draft OKRs

OKRnest's Feedback feature reviews your objectives and key results, compares them against the wider set of OKRs in the organisation, and suggests reformulations where activities, weak measurability, or unclear alignment show up. The OKRs stay yours and your team's, Feedback is there to sharpen them before you commit.

6. The objective is just a label

It is tempting to drop a short phrase at the top of the OKR block, treat it as the file name, and pour all the energy into the key results below it. When that happens, the objective stops doing its job. A good objective tells the team why the work matters, anchors the key results in a clear ambition, and gives the team something to rally around. A label does none of those things.

Objective Create a great workplace

  • Run 4 culture initiatives this quarter
  • Score 4.0 or higher on the engagement survey

Now compare the same OKR with an objective that carries weight.

Objective Create the Nordics' best workplace in our category to lower our attrition

  • Reduce voluntary attrition from 14% to under 8% this year
  • Achieve an employee NPS of 50 or higher (top-quartile in our industry benchmark)

The second objective tells the team what success looks like and why it matters, and the key results sit underneath it as natural measures. The OKR has gone from a label to a direction.

Flat illustration of a person on a ladder swapping a crooked block in a tower for a clean replacement piece held up by a colleague.

OKRs that float free of the company’s strategy can still be useful for the team, but they do not deliver the alignment effect that makes OKRs valuable across an organisation. If a team cannot point to the strategic OKR, the mission, or the bigger goal that their OKR is supporting, the OKR has lost its alignment value. The team can still focus on it and work with it, but the cross-organisation lift that comes from connecting team work to company direction is gone.

The fix is small. For every team OKR, write a single line on which higher-level goal or strategic theme it ladders up to. If nothing fits, that is a useful signal in itself.

8. Key results that don’t move between check-ins

This is where the check-in test pays off most directly. A key result tied to a launch date will look identical at every weekly check-in for nine weeks, and then change once. The team has nothing to talk about in between. A key result tied to a metric that moves every week gives the team something to look at, something to react to, and a way to feel whether last week’s work made a difference.

When you write a key result, ask whether the value would realistically shift between two consecutive check-ins. If the honest answer is no, see whether the work behind it can be expressed as a leading indicator instead.

Close-up of hands swapping a sticky note on a whiteboard, replacing it with a fresh note in a different colour.

9. A KPI dashboard in disguise

A team that lists a handful of standing KPIs and calls them OKRs has created a reporting dashboard, not a goal set. KPIs are continuous metrics you monitor, OKRs are goals with a starting point, a target, and a cycle they belong to. When the two are conflated, the team never feels the focus of a stretch goal, just the steady ambient pressure of “the numbers.”

A practical test: for each key result, is there a clear “from X to Y by Z” wrapped around the metric? If the key result is just the metric on its own, it is a KPI, not a key result.

10. OKRs the team can’t impact enough

This is not about avoiding dependencies. Collaboration across teams is a good thing, and most ambitious OKRs touch other teams in some way. The issue is when your team does not have enough impact of its own to move the needle. Check-ins turn into status updates about somebody else’s work, and the team cannot build engagement around a goal it cannot meaningfully influence.

The test is one of impact share. Does your team have enough levers, decisions, and work on this OKR that it will move on the back of what you do? If the honest answer is no, the OKR belongs to the team that does, or needs to be reshaped into something your team can genuinely drive.

When “imperfect” OKRs beat textbook-perfect ones

Textbook-perfect OKRs are seldom perfect for the team that has to live with them. A set of OKRs that follows every rule but does not connect to the team, does not drive engagement, and does not feel worth chasing will lose to a slightly less polished set that the team genuinely owns. A date-shaped key result here, a soft objective there, may stay in the final set because removing it would weaken what the team actually cares about.

The goal is not a perfect OKR document. The goal is a set of OKRs that focuses the team, makes check-ins worth attending, and moves the work forward. If your draft passes the check-in test more often than it fails, you are likely closer to a strong set than a textbook-perfect one would be.

The OKR writing checklist is a good follow-up once you have caught the bigger mistakes in this list, and the Writing OKRs guide collects the rest of the articles on this topic.

FAQ

Is a key result with a fixed end date always a mistake?

No. A milestone-shaped key result can work when the milestone genuinely changes the system, for example "go live with self-serve checkout by 31 March." The trap is when every key result is a date and the team is really tracking a project plan. If only one or two key results in your set are date-shaped, they may still be valid. If all of them are, the OKR has slipped back into being a task list.

What if we genuinely cannot put a number on the outcome we want?

Look for a proxy that moves with the outcome. A culture change cannot be counted directly, but eNPS, attrition, or specific behaviour ratings in a 360 review often track it. If you really cannot find a proxy that moves within your cycle, the topic may be better tracked as a programme or initiative, with one or two outcome key results sitting on top of it.

Can a key result depend on another team?

Yes. Dependencies are normal, and collaboration across teams is part of how ambitious OKRs get done. The question is impact share: does your team have enough of the work, the decisions, and the levers on this key result for it to move on the back of what you do? If yes, the dependency is fine. If no, the key result needs to be reshaped, or moved to the team that does have the impact.

What is the fastest way to spot any of these mistakes in a draft?

Read each OKR as if you are standing in your next check-in. Will it generate a real conversation about progress, focus, and next steps, or only a status update on tasks? When the answer is the second one, the OKR needs rewriting.

Make more out of your OKRs

Try OKRnest with your team and upgrade to a paid plan when you are ready!