Design Okr Framework

---
name: design-okr-framework
description: Use when setting up an OKR (Objectives and Key Results) system for a team or organization to align goals and measure progress
source: Doerr "Measure What Matters" (2018); Grove "High Output Management" (1983) MBO/OKR origin; Google OKR implementation (Patel & Lamorte methodology)
tags: [okr, goals, strategy, measurement, alignment]
verified: true
---

# Design OKR Framework

Implement an OKR (Objectives and Key Results) system that aligns organizational direction, focuses effort on what matters, and creates measurable accountability from company to team to individual.

## Why This Is Best Practice

**Adopted by:** Google (since 1999, 10 employees to 100,000+), Intel (Grove's original MBO system), LinkedIn, Spotify, Twitter, Adobe — all documented in Doerr (2018)
**Impact:** Google attributes significant culture of prioritization and focus to OKRs; Doerr (2018) documents Intel's productivity increases under Grove's MBO system; companies using OKRs consistently report 30–40% improvement in goal alignment scores (Perdoo benchmark research)
**Why best:** Grove's insight (1983) that "a manager's output is the output of their organization" extends to OKRs — the Objective provides direction, Key Results provide measurement; together they answer "where are we going?" and "how will we know we've arrived?"

Sources: Doerr "Measure What Matters" (2018) Part I; Grove "High Output Management" (1983) Ch. 7; Google re:Work OKR guide

## Steps

1. **Define the OKR cadence** — select: Annual OKRs (company vision), Quarterly OKRs (team delivery), Monthly OKRs (optional for fast-moving contexts); most organizations use Annual + Quarterly.
2. **Write company-level Objectives first** — 3–5 qualitative, inspiring Objectives that define what success looks like for the quarter/year; Objectives must be ambitious (stretch), clear, and actionable: "Become the leading developer platform in Southeast Asia."
3. **Write Key Results for each Objective** — 2–5 measurable, specific outcomes (not activities) per Objective; each Key Result must have a measurable target: "Achieve $5M ARR from developer tools by Q4" not "Grow revenue."
4. **Cascade to teams** — each team defines their own OKRs that align with and contribute to company OKRs; teams have autonomy to define how they contribute, not just what the company dictated.
5. **Write team Objectives** — team Objectives connect directly to 1–2 company Objectives; clearly link them: "To support Company Objective 2, we will: [Team Objective]."
6. **Write team Key Results** — Key Results must be outcome-based not activity-based; "Ship 3 features" is an activity; "Reduce developer onboarding time from 4h to 1h" is an outcome.
7. **Set a scoring system** — score OKRs from 0.0 to 1.0 at end of period; 0.7 is the target (not 1.0 — consistently hitting 1.0 means OKRs were not ambitious enough); 1.0 should feel like a stretch achievement.
8. **Run weekly check-ins** — each week: update Key Result metrics, flag any OKR at risk (red), note what will be done to recover; check-ins keep OKRs alive rather than a quarterly ritual.
9. **Conduct mid-quarter review** — at the halfway point: assess progress to target; re-prioritize if external circumstances have changed; do not change the OKR scoring retroactively — note the change and reason.
10. **Run end-of-quarter retrospective** — score each Key Result 0.0–1.0; discuss: what drove results, what was missed, what was learned; do not use OKR scores for performance review — this creates sandbagging.

## Rules

- Objectives must be qualitative and inspiring — an Objective that reads like a Key Result ("Achieve $5M ARR") is not an Objective; Objectives describe the destination in human terms.
- Key Results must be measurable and outcome-based — if you cannot measure it with a number or a binary (done/not done), it is not a Key Result.
- Maximum 5 Objectives and 5 Key Results per Objective — beyond this, OKRs become a to-do list and the focus benefit is lost.
- OKR scores must never be used for performance reviews — this creates sandbagging (sandbagging = setting easy OKRs to guarantee good scores); OKRs are separate from performance management.
- 70% achievement of an ambitious OKR is better than 100% of an unchallenging one — reward ambition, not sand-bagging.

## Common Mistakes

- **Treating OKRs as a task list** — "Complete Q3 roadmap items" is not an OKR; it has no measurable outcome or directional purpose.
- **Setting OKRs in cascade (top-down only)** — dictating OKRs from the top without team involvement reduces buy-in; team OKRs should be co-created within company direction.
- **Too many OKRs** — 10+ OKRs means no prioritization has occurred; every goal having equal priority means nothing is a priority.
- **OKRs set and forgotten until quarter end** — OKRs require weekly check-ins; without regular review, they become an abandoned annual ritual.
- **Confidential OKRs** — OKRs are most powerful when transparent across the organization; seeing others' OKRs creates alignment and surfaces dependencies.

## When NOT to Use

- Organizations in crisis mode requiring rapid daily tactical decisions (OKRs require stability to be useful)
- Very small teams of 1–3 people where informal alignment is sufficient
- Projects with a fixed scope and timeline where objectives are defined by the project brief