The OKR framework: how to actually run it, not just write it

Most teams that 'do OKRs' don't actually run an OKR framework. They run a quarterly template. Someone fills in an Objective. Someone else lists three Key Results. Everyone nods. The document gets pasted into Notion, and then nothing happens for ten weeks until the next planning offsite.

That isn't the OKR framework failing. That's a framework being skipped entirely.

The OKR framework is not a writing exercise. It's an operating system for how a company sets, tracks, and learns from goals over a quarter. The format (Objective + Key Results) is the smallest, simplest, and most-Googled part. The hard part, the part that actually moves the business, is the cadence of behaviours that surround it. Setting. Scoring. Check-ins. Retros. Decisions about what to keep and what to kill.

This article is for people who already know what an OKR is (or can Google it in 30 seconds) and want to understand how to run the framework so it produces results. We'll cover the four working parts, the common breakdowns, where it sits inside a broader strategy-execution motion, and a 90-day plan to build it.

What the OKR framework actually is

Start here. The OKR framework has four components. Most articles only talk about the first one.

• The format: one Objective (the qualitative shift you want), three to five Key Results (the measurable signals that prove you got there).
• The cadence: the rhythm of planning, check-ins, scoring, and retrospectives that runs every quarter without exception.
• The ownership model: who owns the Objective, who owns each Key Result, and what happens when a KR is off-track.
• The decision layer: how the OKR data feeds into resourcing, prioritisation, and the next planning cycle.

If you're only doing the first one, you don't have an OKR framework. You have a template.

The format, in 90 seconds

Andy Grove invented OKRs at Intel in the 1970s, adapting Peter Drucker's management by objectives model into something faster and less bureaucratic. John Doerr brought them to Google in 1999. They've been in roughly every Silicon Valley playbook since (we wrote up the full OKR history if you want the longer version). The shape:

Objective: a qualitative, ambitious statement of what you want to achieve. Inspiring, not boring. 'Become the default research tool for product teams in Australia.'

Key Results: three to five measurable outcomes that prove the Objective happened. Numeric, time-bound, leading indicators where possible. 'Grow weekly active product managers from 1,200 to 3,000. Move NPS from 32 to 50. Land 8 enterprise design partners.'

The format is honestly the easy part. Anyone can learn it in a workshop. What separates teams that get value from OKRs from teams that don't is everything that happens after the doc is written.

The four parts of a working OKR framework

1. Setting (the planning ritual)

OKRs are set once per quarter. The framework requires a planning ritual: a meeting, or short series of meetings, where leadership locks the company-level Objectives and teams cascade or align their own. The point of this ritual is not the document. It's the conversation that produces the document.

Two failure modes here: the offsite that produces 47 OKRs nobody can hold in their head, and the rubber-stamp process where teams paste in what they were already doing and call it an OKR.

A working OKR framework treats setting as a forcing function for prioritisation. Three to five company Objectives. Each team picks one or two of those to ladder into. Anything you can't tie back to an Objective is a candidate to defer. If you want the practical mechanics, we have a short guide on how to write OKRs in under 30 minutes.

2. Check-ins (the weekly rhythm)

This is the part that decides whether your OKR framework lives or dies. Without weekly check-ins, your OKRs are a quarterly artefact. With them, they're an operating cadence.

A check-in is short. Five minutes per KR owner. Three things: the current number, the trend (better or worse than last week), and one sentence of context. That's it. It runs every week, in the same place, regardless of whether anyone feels they have something to report.

Most teams overcomplicate this. They build a check-in 'meeting' with slides and discussion. The check-in is not a meeting. It's a status capture. The conversation is what happens afterwards, when leaders look at the check-ins and decide what needs attention.

3. Scoring (the quarterly closeout)

At the end of the quarter, every Key Result gets scored. The standard scale runs 0.0 to 1.0, where 0.7 is roughly the target for ambitious OKRs (the 'red, yellow, green' shorthand most teams use is a simpler version of the same idea). If you want the nuts and bolts, we have a detailed guide to how to score OKRs.

Scoring forces honesty. If you scored 1.0 on every KR, your OKRs weren't ambitious enough. If you scored 0.3 across the board, the planning was disconnected from reality. The score is data about the goal-setting process, not just the team's performance.

Don't tie scores to performance reviews or compensation. The moment you do that, scoring becomes political and you lose the honest signal. If you want the deeper case for keeping the two separate, we wrote it up in why we don't tie OKR outcomes to performance reviews.

4. Retrospectives (the learning loop)

This is the most-skipped part of the framework, which is a shame, because it's where most of the value compounds. A retrospective is a 60-minute meeting at the end of each quarter where the team looks at the OKRs, the scores, and asks three things: what worked, what didn't, and what we'd do differently next quarter.

Without a retrospective, you'll set the same flawed OKRs next quarter. With one, you build a flywheel where the framework gets sharper every cycle.

Template OKRs vs framework OKRs, side by side

If you're not sure whether your team is doing OKRs or just filling in a template, this comparison is the fastest way to tell.

Why most OKR rollouts go wrong

Most OKR programs fail in the same predictable ways. Recognising the pattern is half the fix.

• Treating it as a writing exercise. Teams obsess over wording in the planning meeting, then never look at the document again. The framework is the cadence, not the doc.
• Too many OKRs. A 30-person team should have 3-5 Objectives, full stop. Sixteen Objectives means zero priorities.
• Cascading instead of aligning. Top-down cascading turns OKRs into a project management tool. Better to publish company OKRs early, then let teams propose how they ladder in.
• Vanity Key Results. 'Publish 12 blog posts' is not a Key Result. It's a task. A KR is an outcome the work is supposed to drive. 'Grow organic traffic from 40k to 80k' is a KR. Publishing 12 posts is the means.
• Tying scoring to bonuses. Kills the honesty signal. Teams sandbag KRs to make sure they hit 1.0. Don't do this.
• No retrospective. The flywheel breaks. Without learning, you'll redo the same planning mistakes for years.

Where the OKR framework fits inside StratOps

The OKR framework is one of the foundational tools inside a broader strategy-execution motion. Specifically, it's the layer that connects long-term strategy (where the company wants to go) to short-term execution (what we're working on this quarter).

This is the operating model that strategic operations (or StratOps) owns. StratOps teams treat the OKR framework not as a stand-alone goal-setting tool but as one piece of an operating cadence that also includes the annual operating plan, monthly business reviews, and quarterly retrospectives. The OKR framework, run well, is the heartbeat that makes the rest of that cadence work.

Without something like StratOps owning the framework, OKRs tend to drift. People stop running check-ins. The retrospective gets dropped because someone's busy. Within two quarters, the framework collapses back into a template. The job of strategic operations is to make sure that doesn't happen, which usually means owning the calendar, the tooling, and the discipline of running each cycle the same way.

Building your OKR framework: a 90-day rollout

If you're starting from scratch, here's the sequence that works most reliably. Don't try to do everything at once. Stand up the framework piece by piece across one quarter.

Days 1-14: Set the company OKRs

1. Pick a planning method. Either a leadership offsite or a structured async process where exec proposes drafts, the team comments, and you ratify in week 2.
2. Lock 3-5 company Objectives. Each with 3-5 measurable Key Results. Resist the urge to add more. Cut what doesn't matter.
3. Publish, don't cascade. Push the company OKRs to the whole company before teams set theirs. Teams need to know what they're laddering into.

Days 15-28: Team OKRs and ownership

4. Each team picks 1-2 company Objectives to align with. They set their own 2-4 Objectives that ladder up.
5. Assign explicit owners. Every Objective has one owner. Every Key Result has one owner. No shared ownership.
6. Capture baselines. For every KR, write down the current number. This is the only way you'll know if you're moving it.

Days 29-84: The weekly rhythm

7. Set the check-in cadence. Every Friday (or whatever day works) every KR owner posts a check-in. Number, trend, one sentence.
8. Hold a 30-minute weekly review. Exec team reads the check-ins. Discusses anything red. Resourcing decisions happen here, not in the next quarter's planning.
9. Mid-quarter health check (day 45ish). Look at the trends. Anything that's clearly not going to land? Talk about it. Adjust resourcing if needed. Don't move the goalposts.

Days 85-90: Score and retro

10. Every KR gets a 0-1 score. Owners propose, the exec ratifies. No politics.
11. Hold a 60-minute retrospective. What worked. What didn't. What we'd do differently. Capture in writing.
12. Roll learnings into Q+1 planning. Now the flywheel starts.

Do this for two quarters and the framework will start to feel natural. Do it for four and it becomes part of how the company operates.

Tools that support the OKR framework

You can absolutely run an OKR framework in a Google Doc and a spreadsheet. Many teams do, especially in the first quarter. It's a good way to feel where the friction is before committing to tooling.

Friction shows up around week six. The doc is stale. Check-ins are in five different places. Nobody knows the current score for KR-3.2. Someone built a dashboard that nobody updates. This is the moment to look at dedicated tooling.

Tools like Tability are built specifically for this. The product gives every KR a single source of truth, automates the weekly check-in nudges, scores the quarter for you, and surfaces what's off-track so the exec review meeting takes 15 minutes instead of two hours. It's the operating layer for the framework, the part that lives between the spreadsheet and the all-hands.

Don't pick a tool until you've felt the pain. Pick one when you're ready to lock in the cadence as a permanent operating habit.

The framework is the cadence

If you take one thing away: the OKR framework is not the format. The format is the easiest part. The framework is the four-week rhythm of planning, the seven-day rhythm of check-ins, the quarter-end rhythm of scoring and retrospective, and the year-on-year rhythm of getting better at all of it.

Teams that get value from OKRs treat the framework as the product. The Objective and Key Result wording? That's just the artefact the framework happens to produce.

The companies that run this cadence consistently, for years, end up with something rare: a workforce that knows what matters, can tell when they're winning, and feels the connection between their week and the company's quarter. That's the goal. Not a perfect KR statement.