What Is an OKR?
An Objective and Key Results (OKR) is a goal-setting framework invented at Intel by Andy Grove in the 1970s and later adopted by Google, LinkedIn, Twitter, and most of Silicon Valley. It answers two questions:
- Objective (O): Where do we want to go? — A qualitative, inspiring, time-bound direction.
- Key Results (KR): How will we know we got there? — 2-5 quantitative, measurable outcomes.
Think of it like planning a road trip. The Objective is "Drive to New York City by Friday." The Key Results are the measurable checkpoints: "Pass through Philadelphia by Wednesday," "Average fuel cost under $50/day," "Arrive before 5 PM Friday." You don't specify which roads to take — that's up to the driver (the team).
Anatomy of a Good OKR
The Objective must be:
- Qualitative — No numbers in the Objective itself. Numbers belong in Key Results.
- Inspiring — It should make the team feel like they're working on something that matters.
- Time-bound — Typically one quarter (12 weeks).
- Uncomfortable — If you're 100% confident you'll hit it, it's not ambitious enough. Google targets 70% achievement as the sweet spot.
Each Key Result must be:
- Quantitative — A number, percentage, or binary (done/not done).
- Outcome-based — Measures the result, not the activity.
- Independently verifiable — Anyone can check whether it was achieved.
Real Examples (Good vs. Bad)
Bad OKR:
Objective: Improve our infrastructure
KR1: Refactor the billing service
KR2: Set up monitoring
KR3: Write documentation
Why it's bad: The Objective is vague. The Key Results are tasks (outputs), not outcomes. "Refactor the billing service" — and then what? How do you know it's better?
Good OKR:
Objective: Make our platform reliable enough to win enterprise customers
KR1: Increase service availability from 99.5% to 99.95%
KR2: Reduce mean time to recovery from 4 hours to 30 minutes
KR3: Pass SOC 2 Type II audit with zero critical findings
Why it's good: The Objective is inspiring and directional. Each Key Result is measurable, outcome-based, and directly supports the Objective. You can grade each KR on a 0.0 to 1.0 scale at the end of the quarter.
The Cascade: Company → Team → Individual
OKRs work through alignment, not top-down dictation. Each level reads the level above it and proposes how it can best contribute — leadership doesn't prescribe the solution, it broadcasts the intent:
Company OKR:
O: Win the enterprise market segment
KR1: Close 10 enterprise deals worth >$100K each
KR2: Achieve SOC 2 compliance
KR3: Reduce onboarding time from 30 days to 3 days
↓ Engineering reads this and responds ↓
Platform Team OKR:
O: Build enterprise-grade infrastructure foundations
KR1: Implement SSO (SAML/OIDC) for all customer-facing services
KR2: Deploy centralized audit logging covering 100% of API endpoints
KR3: Achieve 99.95% availability on the core API (up from 99.5%)
↓ Individual engineer reads this and responds ↓
Engineer OKR:
O: Deliver production-ready audit logging
KR1: Ship audit log pipeline processing 100% of API events with <5s latency
KR2: Zero data loss verified by end-to-end integration tests
KR3: Documentation and runbook reviewed and approved by security team
Notice how each level chooses how to contribute. Leadership didn't tell the platform team "implement SSO." The platform team read the company's intent ("win enterprise") and proposed SSO as their contribution. This is alignment without micromanagement.
A common interview question is: "How do you prioritize work on your team?" The strongest answer structure is: "We align to company OKRs. Last quarter, the company objective was X. Our team translated that into Y. I personally owned KR Z, which meant I focused on [specific technical work] because it directly moved the metric from A to B." This demonstrates strategic thinking, not just task execution.
OKRs vs. KPIs: The Critical Distinction
| Dimension | KPI | OKR |
|---|---|---|
| Purpose | Monitor health | Drive change |
| Nature | Maintain steady state | Move from state A to state B |
| Action | React when threshold breached | Proactively work toward daily |
| Timeframe | Ongoing (always tracked) | Time-bound (quarterly) |
| Example | "Uptime ≥ 99.9%" | "Increase uptime from 99.5% to 99.95%" |
| Grading | Pass/Fail (green/red) | 0.0 to 1.0 scale |
The Classic Mistake: Setting a KPI as an OKR. "Maintain 99.9% uptime" is a KPI — it describes the status quo. "Increase uptime from 99.5% to 99.95%" is an OKR — it demands change. If your OKR doesn't require you to do anything differently than last quarter, it's not an OKR.
Key Point: A KPI that is currently failing can become an OKR. If your availability has been stuck at 99.5% and the business needs 99.95%, that gap becomes an Objective. Once you achieve 99.95% and sustain it, it reverts to being a KPI. The lifecycle is: healthy metric → KPI. Broken metric → OKR. Fixed metric → KPI again.