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