Most companies use OKRs as a quarterly template. Here's how to use them as an operating system.

OKRs are everywhere. Google famously attributes much of its early growth culture to them. Every growth-stage playbook recommends them. Every accelerator cohort gets a session on writing Objectives and Key Results.

And yet most companies that "use OKRs" are using them in name only. They fill out the form at the beginning of the quarter, file it somewhere in Notion or Confluence, and don't look at it again until the grading meeting — where they realize they hit 40% of what they wrote down and aren't entirely sure why.

The form isn't the problem. The problem is that teams learn the structure without learning the purpose. OKRs aren't a reporting mechanism. They're an alignment mechanism — a way of ensuring that what individuals work on every day connects, clearly and explicitly, to what the company is trying to achieve this quarter.

When they work, they're extraordinary. When they're just a template, they're a tax.

Here's how to do them right.

What OKRs Actually Are (And Aren't)

OKRs stand for Objectives and Key Results. The framework was developed at Intel by Andy Grove and popularized at Google by John Doerr. The core idea is deceptively simple: define what you want to achieve (the Objective), then define how you'll know if you achieved it (the Key Results).

Objectives are specific, ambitious goals. They describe an action and an outcome — what you're doing and why it matters.

Key Results are the measurable benchmarks that track progress toward the Objective. Each KR has one or more KPIs that can be graded at the end of the period.

What OKRs are not: a to-do list, a performance review mechanism, a project management backlog, or a way to micromanage individual output. They operate at the level of outcomes, not tasks. An OKR shouldn't tell someone how to do their job. It should tell them what success looks like.

Why OKRs Achieve the Four Metrics First Principles

When built correctly, OKRs naturally satisfy the four principles of a good metrics framework.

Relevant: Every Objective traces back to the company mission. Every KR traces back to its Objective. There's a direct, auditable chain from the metric to the strategy.

Precise: Key Results require specific, measurable KPIs. Vague aspirations — "improve user experience" — don't work as OKRs because they can't be graded. The format enforces precision.

Aligned: OKRs cascade from company level to department to team to individual. The whole organization operates from the same strategic starting point.

Comprehensive: When every team has OKRs, and those OKRs cascade from company-level Objectives, the collective picture is collectively exhaustive. Nothing important is flying under the radar.

Step 1: Building Objectives

The structure of a good Objective is: Action + Outcome.

The Action describes what you're doing. The Outcome describes what it achieves — why it matters at the company level.

Example from Etsy's Customer Service team:

"Improve the product return experience to increase efficiency and reduce costs in Customer Service."

• Action: Improve the product return experience

• Outcome: Greater efficiency and lower CS costs

This Objective is specific (it's about the returns experience, not all of CS), ambitious (improving a whole category of experience is hard), and impactful (the outcome ties directly to cost reduction, which is a business priority).

Example from Etsy's Product team:

"Build a search experience that improves search-to-conversion and wows customers."

• Action: Build a search experience

• Outcome: Higher conversion, delighted users

Notice "wows customers" — this is deliberately ambitious language. It sets a standard beyond just incremental improvement. That's intentional.

One of the most important principles for Objectives is the 70% rule: if your team achieves 100% of its Objectives, they weren't ambitious enough. The right calibration is roughly 70% completion. An Objective that can always be hit is an Objective that isn't stretching the team.

The other critical principle is cascading. Company OKRs get set first. Department OKRs then align to the company Objectives. Team OKRs align to department OKRs. Individual OKRs align to team OKRs. This cascading structure is what gives OKRs their alignment power — it ensures that every engineer, analyst, and product manager can draw a direct line from their weekly work to the company's quarterly priorities.

Step 2: Selecting Key Results

Key Results benchmark progress toward the Objective. The structure is: Action + Measure/Milestone + Outcome.

Each Objective should have 3–5 Key Results. Any more than that and the Objective becomes a catch-all. Any fewer and you may be missing important dimensions of what "achieving the Objective" means.

Example Key Results for the Etsy CS Objective:

KR 1: "Implement one or more fulfillment features or processes that reduce Customer Time to Refund by 20%."

• Action: Implement fulfillment features or processes

• Measure: Customer Time to Refund — the elapsed time between a customer initiating a return and receiving their refund to their bank account

• Outcome: 20% reduction

KR 2: "Improve website customer information in order to reduce CS Requests related to returns by 20%."

Note the specificity: "related to returns." An earlier draft of this KR just said "reduce CS Requests by 20%" — which is too broad. The CS team is working on returns, not all of CS. The KR needs to reflect the scope of what this team can actually influence.

Three principles for good Key Results:

Relevant: The KR must directly benchmark progress toward the Objective. If you can hit the KR without making progress on the Objective, it's the wrong KR.

Verifiable: There must be a clear way to determine completion or partial completion at the end of the period. "Customer Time to Refund decreases by 20%" is verifiable. "Customers feel better about returns" is not.

Time-bound: The KR should have either an explicit deadline or an implicit one (the end of the quarter). This creates urgency and enables grading.

Step 3: Using OKRs Day-to-Day

Writing OKRs is the easy part. The real test is whether they function as a living operating system throughout the quarter.

Access: OKRs need to be visible. Whiteboards in the team area, a pinned Notion doc, a Jira board — the medium matters less than whether people actually look at them. Weekly standups and team meetings should reference OKRs: "Does this work support a KR? If not, why are we prioritizing it?"

Within-team alignment: For individual contributors, OKRs create "freedom with guardrails." Engineers, analysts, and designers can largely self-direct their work — as long as that work is contributing to a Key Result. This respects autonomy while maintaining accountability.

OKRs also create space for personal development. An engineer who wants to learn TypeScript can propose a KR that refactors legacy code using TypeScript — serving both the team Objective and their own growth. The key is making the connection to the Objective explicit and reviewable.

Cross-team alignment: One of the most underrated benefits of OKRs is visibility across functions. When Product publishes their OKRs and Data publishes theirs, both teams can immediately identify dependencies — and address them in planning, rather than discovering them mid-quarter.

If the Product team's Objective requires new instrumentation, and the Data team's capacity is fully committed elsewhere, that's a conversation to have in week one of the quarter, not week eleven. OKRs make these dependencies visible before they become emergencies.

Step 4: The OKR Calendar

OKRs are quarterly artifacts, but the planning process runs across two quarters. Getting the timing right is essential — if company OKRs come out after departments have already started planning, the cascade breaks.

Here's a recommended timeline for a Q1 cycle:

• Mid-November: Executive team drafts company-level OKRs

• Early December: Company OKRs finalized

• Mid-December: Company OKRs communicated broadly

• Late November: Department heads begin drafting (they can start before company OKRs are final, given visibility into the direction)

• Early January: Department OKRs finalized; team leads begin drafting

• Mid-January: Team OKRs finalized and communicated; individuals begin drafting

• Late January: All levels finalized; Q1 begins in earnest

The most common failure in the calendar is rushing the lower levels. If executives finalize company OKRs in the second week of January and expect team OKRs to be done by January 15, nobody has time for genuine thought. Build in cross-team review sessions before finalization — particularly for OKRs with dependencies.

Step 5: Grading OKRs

Grading happens at the end of the quarter. It's a two-part process.

Part 1 — Scoring: Grade each Key Result from 0–100%, reflecting the degree of completion. Average the KR grades to get the Objective grade. Remember: 70% is the target, not the floor. An Objective scored at 70% reflects genuine ambition and solid execution. An Objective scored at 100% every quarter means the team isn't setting ambitious enough targets.

Part 2 — Retrospective: This is where organizational learning happens. The retrospective is a structured conversation about what worked, what didn't, and what the team should do differently next quarter.

The simplest retrospective format:

1. Give everyone 10 minutes to independently write Post-it notes (or their digital equivalent) in two columns: What went well and What can we improve

2. Group similar ideas and discuss patterns

3. Identify Continue (things to keep doing), Start (new behaviors or practices to adopt), and Stop (things that aren't working) actions for next quarter

One critical principle: retrospectives should be about improving processes, not about evaluating people. Blame shuts down learning. The goal is institutional knowledge — understanding what structural factors led to the outcomes, and how to design better conditions for next quarter.

OKRs as a System

The difference between organizations that use OKRs well and those that don't isn't sophistication. It's commitment to the system.

Start simple: one set of company OKRs, shared broadly, reviewed weekly, graded and retrospected quarterly. Don't try to implement all five levels of the cascade in the first quarter. Build the habit first.

The question at the center of the OKR system is always the same: How do we know if we're making progress on what matters most? If your OKRs are answering that question — if they're creating shared clarity, surfacing dependencies, and holding the organization accountable to genuine ambition — they're working.

If they're just a form you fill out at the beginning of the quarter, they're not.

The OKR framework, along with the full metrics design methodology, is covered in The Data Strategist course. Get the worksheet and start your first cycle.