michaelsvanbeek/okrs

OKRs (Objectives and Key Results)

When to Use

• Setting team OKRs at the start of a quarter or year
• Cascading company or org-level OKRs to your team
• Writing or refining individual contributor OKRs
• Preparing for mid-cycle or end-of-cycle OKR reviews
• Coaching a team member on how to write better OKRs
• Auditing existing OKRs for clarity and measurability

---

OKR Fundamentals

Objectives

An objective is what you want to achieve. It is:

• Qualitative — a direction, not a number
• Inspirational — ambitious enough to drive action
• Time-bound — scoped to the planning period (typically quarterly)
• Actionable — the team can influence the outcome directly
• Concise — one sentence, no jargon

Good: "Establish our platform as the most reliable in the industry" Bad: "Improve uptime SLA metrics by optimizing infrastructure monitoring and alerting"

Key Results

A key result is how you measure progress toward the objective. It is:

• Quantitative — a number, percentage, or binary (shipped / not shipped)
• Measurable — you can check it at any point during the cycle
• Outcome-oriented — measures the result, not the activity
• Ambitious but achievable — 70% completion is healthy; 100% means you aimed too low

Good: "Reduce P1 incident count from 8/quarter to 2/quarter" Bad: "Implement better monitoring" (activity, not outcome) Bad: "Improve reliability" (not measurable)

Structure

Objective: <What we want to achieve>
  KR1: <Metric from X to Y>
  KR2: <Metric from X to Y>
  KR3: <Binary: Ship X by date>

Aim for 2–5 key results per objective and 2–4 objectives per team per quarter.

---

Cascading OKRs

Company OKRs flow down through the org, but cascading is not copying:

Company OKR
  └─ Org OKR (how this org contributes to company goal)
       └─ Team OKR (how this team contributes to org goal)
            └─ Individual OKR (optional — how this person contributes to team goal)

Cascading Rules

1. Align, don't duplicate — Your team OKR should contribute to the org OKR, not repeat it verbatim
2. Own your scope — Team OKRs must be within the team's control and influence
3. Not everything cascades — Some team OKRs are locally important (tech debt, developer experience) and don't map directly to a company OKR. That's fine — cap these at 1 per quarter
4. Avoid cascading to individuals unless your org requires it. Team-level OKRs with shared accountability are more effective

Example Cascade

Company: "Accelerate enterprise customer acquisition"
  └─ Org: "Deliver enterprise-ready platform capabilities"
       └─ Team: "Establish SOC 2 compliance for the data pipeline"
            KR1: Pass SOC 2 Type II audit by end of Q2
            KR2: Remediate all critical findings within 2 weeks of discovery
            KR3: Automate 90% of compliance evidence collection

---

Writing Quality Checklist

For each OKR, verify:

| Check | Pass? | |-------|-------| | Objective is qualitative and directional | | | Objective fits in one sentence | | | Each KR has a specific metric or binary deliverable | | | Each KR has a baseline ("from X") and target ("to Y") | | | KRs measure outcomes, not activities or tasks | | | KRs are within the team's control or strong influence | | | Achieving all KRs would clearly achieve the objective | | | 2–5 KRs per objective (not more) | | | 2–4 objectives per team (not more) | | | At least one KR is a stretch (not guaranteed at 100%) | |

---

Common Anti-Patterns

| Anti-Pattern | Problem | Fix | |-------------|---------|-----| | Task masquerading as KR | "Deploy monitoring dashboard" is a task | "Reduce mean time to detect from 45min to 5min" | | Sandbagging | All KRs are easily achievable | At least one KR should be a genuine stretch | | Too many OKRs | 6 objectives with 5 KRs each = 30 things to track | Max 4 objectives, 5 KRs each | | Vanity metrics | "Increase test count to 500" | "Reduce escaped defects from 12/quarter to 3/quarter" | | No baseline | "Improve page load time" — from what? | Always include current state: "from 3.2s to 1.5s" | | Annual OKRs only | Too long to course-correct | Quarterly OKRs with annual themes | | Set and forget | OKRs written in January, never reviewed | Check-in monthly at minimum |

---

Scoring

At the end of each cycle, score each KR:

| Score | Meaning | |-------|---------| | 0.0–0.3 | Failed to make meaningful progress | | 0.4–0.6 | Made progress but fell short of the target | | 0.7–0.9 | Hit the target or came close — this is the sweet spot | | 1.0 | Fully achieved (if all KRs score 1.0, you probably aimed too low) |

Scoring Process

1. Self-score each KR with supporting evidence
2. Team review — discuss scores together, calibrate
3. Document lessons learned: What worked? What would we change?
4. Feed forward — carry insights into next cycle's OKR planning

Quarterly OKR Review Template

# Q[N] YYYY OKR Review — [Team Name]

## Summary
Overall score: X.XX / 1.0
Key wins: ...
Key misses: ...

## Objective 1: <Title>
Score: X.X

### KR1: <Description>
- Target: <what we aimed for>
- Actual: <what we achieved>
- Score: X.X
- Evidence: <link to data, dashboard, or artifact>
- Notes: <what helped or blocked>

### KR2: ...

## Lessons Learned
- What we'd do differently next time
- What we'd double down on

## Carry-Forward
Items to continue in the next cycle

---

Cadence

| When | Activity | |------|----------| | Quarter start (Week 1–2) | Draft OKRs, align with org, finalize and publish | | Monthly | Check-in: update KR progress, flag risks, adjust if needed | | Mid-quarter | Formal mid-cycle review — are we on track? | | Quarter end (Last week) | Score OKRs, write review, feed into next quarter planning |

---

Tools

• Spreadsheets / Docs: Simple OKR tracker for small teams (Google Sheets, Notion, Airtable)
• Documentation wiki: OKR review pages linked to your team's space (Confluence, Notion)
• Issue tracker: Epics can map to initiatives that support KRs
• Dedicated goal platforms: Lattice, Leapsome, 15Five, or your company's goal-tracking system