10 OKR dogmas you should ignore

‍Key Takeaway: Many of the "rules" of OKRs are not rules. They are conventions, mostly invented at Google, that hardened into dogma as the framework spread. Common dogmas to ignore include: Every team and every employee needs OKRs, Key Results must be stretch targets, OKRs can't be changed mid-cycle, and hitting 100% progress means the bar was too low. Experienced practitioners ignore these when they don't fit the company and culture. So should you.

When OKR first crossed over from being Google's internal management method to being a thing every other company tried to copy, a lot of useful guidance came with it. Some of that guidance is genuinely durable. Most of it isn't. We've covered the full framework in detail in the Ultimate Guide to OKR; this article is about the rules within that framework that you should feel free to ignore.

What's happened over the past decade is that a set of perfectly reasonable Google-era conventions ("our Objectives have 3 to 5 Key Results," "we score on a 0 (0%) to 1 (100%) scale where 0.7 (70%) is considered a success," "we set OKRs quarterly") got globalized into laws. Consultants taught them as rules. Books printed them as rules. Tools enforced them as rules. By the time most companies sat down to adopt OKRs, they were inheriting a body of dogma that bore little resemblance to the flexible, opinionated practice that actually existed inside Google.

This is the source of an enormous amount of OKR friction. Teams sit in their first OKR planning session and discover they "have to" produce 3 Key Results per Objective, even when 2 would be sharper. Programs collapse because the leadership team can't change a mid-cycle OKR even though the market has moved underneath them. Employees sandbag their OKRs because someone connected the scoring system to their bonus. None of these are framework problems. They're dogma problems.

The 10 OKR dogmas

Here are the 10 dogmas I see most often in customer conversations, and what to do instead. Most of these have been on Perdoo's blog in scattered form for years. This is the consolidated version.

1. Every team and every employee needs OKRs

The dogma says that for OKRs to "really work," they have to cover the whole organization down to the individual contributor. Every team needs OKRs. Every employee needs OKRs. Anyone left out is a gap in the system.

This is wrong for two reasons. First, some teams' work is captured better by KPIs than by OKRs. A team that operates entirely on maintenance metrics (a payroll team, a security operations team, a finance closing team in non-quarter-end months) may not need any OKRs in a given quarter. Forcing them to invent one only creates administrative overhead.

Second, individual OKRs are often a mistake. Most companies that adopt them discover within two cycles that the administrative weight outpaces the value. The Objectives at the individual level either duplicate the team's Objectives, fragment the team's focus, or become a backdoor performance-review mechanism. We've covered the broader version of this in how many OKRs should you have: coverage is not the goal. Clarity and accountability are the goal. Sometimes those are best served by fewer OKRs at fewer levels.

2. Key Results must always be stretch targets

Here is the rule, exactly as it gets stated: "If you hit 100% of your Key Results, your bar was too low." It traces directly back to Google, where OKRs were always meant to be aspirational, and 0.7 was considered the success threshold.

It's a reasonable convention. It's also culturally dependent, not universal, which is why I argued long time ago to abandon stretch goals. In a committed-OKR culture, 100% is the target, not 70%. The team is held to the number they signed up for.

Some companies thrive on aspirational stretch goals. Many don't. If your culture is one where ambitious goals routinely produce 60% to 70% progress and that's considered a win, stretch OKRs are working for you. If your culture is one where missing a target signals a real problem, committed OKRs at 100% are probably the right model. The dogma is the assumption that stretch is better for everyone. It isn't.

3. OKRs must follow a quarterly cadence

Quarterly cadence is a Google convention. Spotify uses a 6-month cadence with 6-week reviews. Many organizations run on 4-month cycles. Some run on 6-week cycles.

OKR Coach Felipe Castro has covered this thoroughly in his guest piece on how to find the right OKR cadence. His framing is that you need at least three cadences running in parallel: a strategic cadence (longer), a tactical cadence (shorter), and a review cadence. Different functions inside the same company can use different rhythms. Engineering may run on the same 6-week cycle as its sprints. Sales may run quarterly to match the commercial calendar. Strategy may run annually with a half-year refresh.

The dogma is "OKRs are quarterly." The reality is that OKRs are cyclical, and the right cycle length is whatever matches the natural rhythm of the work.

4. Every Objective needs 3 or more Key Results

The original guidance was "an Objective should have a few Key Results, typically up to 5." Somewhere along the way, "up to 5" became "at least 3," and then "at least 3" became "must have 3."

In practice, 3+ is a ceiling, not a quota. We've written that the right number of OKRs is whatever your context demands, and the same goes for Key Results within an Objective. If 2 sharp Key Results capture what success looks like, adding a third manufactured one just adds noise. The team's attention is now split across three numbers instead of two, and the third one is almost certainly less meaningful than the first two.

We've covered this directly in how to use OKRs to measure what matters: the 3 to 5 figure was always meant as a maximum, not a minimum. Some Objectives are best served by a single Key Result. The rule isn't "always 3+ Key Results." The rule is "however many Key Results actually measure whether the Objective succeeded." If that answer is one, let it be.

5. OKRs can't be changed or canceled mid-cycle

This one is genuinely destructive. The dogma says you set your OKRs at the start of the cycle, run them for 12 weeks, and only then evaluate them. If reality changes between week 1 and week 12, you're supposed to grimly keep tracking the original goals anyway.

That's nonsense, and we said so directly in how to close OKRs properly. If you hit an Objective in week 6, close it then. If an Objective becomes irrelevant in week 4 because the strategy shifted, kill it. If a Key Result needs to be replaced because you learned new information, replace it. The OKR system exists to keep the company focused on the right things; if the right things have changed, the OKRs need to follow.

The reason this dogma persists is that mid-cycle changes feel undisciplined. They aren't, if you have the discipline of explicitly closing OKRs and documenting why. Closing an OKR mid-cycle because it's irrelevant is a sign of a healthy program. Forcing the team to slog through it is a sign of a dead one.

6. Hitting 100% progress means the bar was too low

This is the 0.7 (or 70%) rule, the second-cousin of the stretch-goals dogma. It says that if you consistently hit 100% of your Key Results, your OKRs weren't ambitious enough, and you should set bolder targets next time.

Like the stretch goals dogma, this only makes sense in a stretch-OKR culture. In a committed-OKR culture, 1 or 100% is exactly the desired outcome. The team committed to a number, the team hit the number, the system worked. 70% progress in a committed culture isn't a feature, it's a miss.

This dogma is particularly destructive because it pressures teams to inflate their targets to avoid hitting them. The result is a system that punishes accuracy and rewards posturing. If your team consistently achieves 100% progress on committed OKRs that are actually moving the business, you don't have a bar-too-low problem. You have a working system.

7. Key Results must always be quantitative metrics

The Google-era guidance was that Key Results should be measurable. Over time, "measurable" got narrowed to "expressed as a number," and now most OKR templates assume every Key Result is a metric like "increase X from Y to Z."

In reality, Key Results come in three legitimate forms: metric-based, milestone-based, and binary. We covered each in detail in different types of Key Results and when to use them. A milestone like "Launch the new pricing by end of Q2" or a binary goal like "Achieve ISO 27001 certification" can be perfectly valid Key Results when they are considered a measurement of success for the Objective.

The discipline isn't "all Key Results must be metrics" or "all KRs must be numbers." What disqualifies a KR isn't its format, it's whether it actually measures the result you wanted.

8. OKRs should be tied to compensation and performance reviews

This is the single most destructive OKR dogma, and the one most likely to kill a program quietly within a year. The logic seems intuitive: if OKRs measure what matters, and people are evaluated on what matters, OKRs should be tied to comp.

In practice, the moment you tie OKR scores to bonuses, you create overwhelming pressure to sandbag. Employees set targets they know they can (easily) beat. The OKR conversation stops being about what the team is trying to drive and becomes a negotiation about what targets will protect each person's review.

We've covered this in detail in 4 reasons why you shouldn't combine OKR and performance reviews. Google itself explicitly separates the two. So should you. OKRs and performance reviews can coexist in the same company, but they have to live in different conversations, with different rhythms, owned by different processes.

If your culture has already entangled the two, untangling them is one of the most leveraged moves you can make on an OKR program. The ambition that disappeared the day you tied OKRs to comp will come back.

9. OKRs cascade strictly top-down

The dogma is that the Company Objective produces Company Key Results, each of which becomes a Department Objective, with its own Key Results that become Team Objectives, and so on down the org chart. Every layer's Key Results turn into the next layer's Objectives. The result is a clean, fully cascaded tree.

It's also a tree that almost nobody can actually build, because the math breaks. A Company Key Result like "increase ARR from $20M to $30M" is also not an Objective for any single team. It's an outcome that depends on Sales, Marketing, Product, and Customer Success all doing different things in concert. Forcing one team to inherit it as their Objective just makes that team accountable for something they can't move alone.

The better approach is directional alignment. Teams see the Company OKRs and write their own OKRs that explicitly tie to a parent (a Strategic Pillar, a Company OKR, or a KPI). The team's OKRs are theirs to define. The alignment is on the Objective-to-parent link, not on the KR-to-Objective link.

10. OKRs replace KPIs

"We're moving to OKRs, so we don't need our KPI dashboard anymore." Or its inverse: "We have KPIs, so OKRs would be redundant."

Both miss what the two things actually are. OKRs and KPIs are not substitutes. They are complements that serve different purposes. OKRs are change goals, measuring something you want to change. KPIs are maintenance goals, for ongoing business-as-usual, measuring something you want to maintain. The car analogy from our OKRs vs KPIs article still holds: KPIs are the dashboard that tells you if the car is running well. OKRs are the GPS pointing you to a new destination.

You need both. A company running only on KPIs has no mechanism for driving change. A company running only on OKRs has no mechanism for keeping the engine healthy between quarters. The dogma that one replaces the other has killed more KPI dashboards (and more OKR programs) than almost any other misconception in this list.

Why these dogmas persist

The reason all 10 of these have stuck around long after the people who invented them moved on is that dogmas feel safer than judgment. Telling a leadership team "always have 3 Key Results" is easier than telling them "use as many Key Results as your Objective actually needs." Telling a team "stretch your goals" is easier than telling them "decide whether your culture is built for stretch or commitment, then act accordingly."

Dogma is what consultants sell when they don't trust their clients to think. Dogma is what frameworks default to when they're being adopted by teams that don't yet have the muscle to deviate. None of these dogmas are crazy. They were all reasonable defaults at some point. They just stopped being defaults and became rules.

The way out is the same as it ever was. Adopt the OKR framework, then experiment with it inside your own company. Notice which conventions actually serve you and which ones you're following out of habit. Break the ones that don't fit. The framework is robust enough to survive that. The dogma isn't.

[fs-toc-omit]How Perdoo supports flexible OKRs

Perdoo is built so that none of these dogmas are baked into the product. You can have an Objective with one Key Result or with five. You can close an Objective mid-cycle when it's done or no longer relevant. You can use stretch OKRs or committed OKRs, whichever fits your culture. You can run different cadences for different teams. Your Key Results can be metric-based, milestone-based, or binary. You can track OKRs alongside your KPIs and strategy.

If you want a goal-setting tool that supports flexible OKR practice instead of rigid OKR dogma, start for free or request a demo.