OKR Cascading
OKR Cascading is the practice of translating company-level Objectives and Key Results into team and individual OKRs so every level of the org pulls in the same direction. The CEO sets 3-5 company OKRs. Each VP picks ONE of those KRs and writes their team's OKRs to drive it. Each manager does the same. Done well, every IC can trace their quarterly goal back to a company outcome in 3 jumps. Done poorly — and this is the norm — cascading becomes a copy-paste exercise where the CEO's 'increase ARR by 30%' becomes the head of sales 'increase ARR by 30%' becomes the AE 'increase your quota by 30%.' That's not cascading; that's plagiarism.
The Trap
The trap is treating cascading as strict hierarchical inheritance — every team's OKRs must mathematically roll up to the parent's. This kills the framework. It removes the team's agency to figure out the best way to contribute, ignores cross-functional work that doesn't map to one parent, and creates absurd KRs at the IC level (a designer with 'increase ARR by 0.4%' as a key result). Worst of all, it creates 6-week negotiations every quarter where teams haggle over numbers instead of executing.
What to Do
Use 'aligned' instead of 'cascaded.' Publish company OKRs in week 1 of the quarter. Give teams 2 weeks to draft their own OKRs that explicitly reference WHICH company KR they support and HOW. Review for alignment, not arithmetic. Allow 70-80% of team OKRs to ladder up to company OKRs; reserve 20-30% for team-specific health metrics (technical debt, hiring, infrastructure). Publish all OKRs in one shared doc — visibility is the alignment mechanism, not the cascade.
Formula
In Practice
Google's OKR system, brought in by John Doerr in 1999 from Intel, has never been a strict cascade. Larry Page sets company OKRs. Teams write their own and post them in a shared internal directory where any Googler can read any other Googler's OKRs. Sundar Pichai has said the alignment comes from radical visibility, not from a parent-child mapping. About 60% of Google's team OKRs explicitly tie to a company OKR; the rest are health and operational goals teams need to hit regardless.
Pro Tips
- 01
The CEO should write company OKRs FIRST and publish them BEFORE asking teams to draft theirs. The most common failure is asking VPs to 'submit your OKRs' so the CEO can synthesize them — that's bottom-up consensus, not strategy.
- 02
Cap company OKRs at 3-5 Objectives with 3-5 KRs each. More than 5 means you have no priorities. If everything is a top-priority OKR, the org will pick its own priorities (and they'll be the easy ones).
- 03
Score OKRs at 0.0-1.0, not 'red/yellow/green.' Andy Grove's original system targeted 0.7 — meaning if you're hitting 1.0 on most OKRs, your KRs were too easy. A culture that punishes 0.6 will produce sandbagged OKRs forever.
Myth vs Reality
Myth
“Every employee needs personal OKRs that ladder up to company OKRs.”
Reality
Personal/individual OKRs are where most companies break the system. They turn OKRs into a performance review tool, which kills the willingness to set ambitious goals. Most successful OKR companies (Google, Stripe, Coinbase) stop at the team level. Individual goals belong in 1:1s and growth plans, not OKR docs.
Myth
“OKRs and KPIs are the same thing.”
Reality
KPIs are the metrics you watch to know if the business is healthy (uptime, NPS, revenue). OKRs are time-bound bets on changing a metric. 'Maintain 99.9% uptime' is a KPI. 'Reduce P0 incidents from 12/quarter to 2/quarter by shipping the new monitoring system' is an OKR. A company needs both.
Try it
Run the numbers.
Pressure-test the concept against your own knowledge — answer the challenge or try the live scenario.
Knowledge Check
Your CEO sets a company OKR: 'Reach $50M ARR by Q4.' The Head of Engineering's draft OKR reads: 'Reach $50M ARR by Q4 by shipping all roadmap features on time.' What's wrong with this?
Industry benchmarks
Is your number good?
Calibrate against real-world tiers. Use these ranges as targets — not absolutes.
OKR Cascade Alignment Rate
Mid-stage tech companies (200-2000 employees) running quarterly OKRsHealthy
60-80% aligned
Acceptable
40-60% or 80-95%
Bureaucratic Theater
> 95% aligned
Disconnected
< 40% aligned
Source: WhatMatters / John Doerr OKR research; Re:Work by Google
Real-world cases
Companies that lived this.
Verified narratives with the numbers that prove (or break) the concept.
1999-Present
Google adopted OKRs in 1999 when John Doerr brought the framework from Intel. From the start, Larry Page resisted strict cascading. Google's system: company OKRs are set by the CEO, every team writes their own OKRs, and ALL OKRs are visible to ALL employees in an internal directory. Roughly 60% of team OKRs explicitly tie to a company OKR; the rest are team health (infrastructure, technical debt, hiring). Google scores OKRs 0.0-1.0 with a target of 0.7 — hitting 1.0 routinely means the goal was too easy.
Company OKRs per quarter
3-5
Target OKR score
0.7
OKR visibility
100% (org-wide)
Years using OKRs
25+
Visibility, not hierarchical inheritance, creates alignment. The 'cascade' at Google is sociological — engineers see what the CEO and other teams care about and align voluntarily. Mandated cascades produce paperwork; transparent cascades produce coordination.
Intel
1970s-1980s (Andy Grove era)
Andy Grove invented the modern OKR system at Intel, which he documented in 'High Output Management.' Grove's insight: when Intel was being attacked by Japanese memory chip manufacturers in the early 1980s, the company needed every level of the org pulling in one direction. He used quarterly OKRs to coordinate the pivot from memory to microprocessors — the famous 'Operation Crush' that won Intel the IBM PC contract for the 8086. The cascade wasn't bureaucratic: it was Grove walking the floor and asking engineers what their OKRs were and how they connected to beating Motorola.
OKR cycle
Quarterly
Outcome of Operation Crush
8086 won the IBM PC design
Strategic pivot
Memory → Microprocessors
Result
Intel became the dominant CPU maker for 30+ years
OKRs are most powerful as a coordination tool during strategic pivots, when every team needs to drop the old priorities and align on the new ones. They're least powerful as steady-state goal management for a stable business — that's what KPIs and operating reviews are for.
Hypothetical: 400-person FinTech startup
Cycle 8 of OKRs
A FinTech startup adopted OKRs at 50 people and made every employee write personal OKRs that mathematically rolled up to the company's revenue OKR. By 400 people, they were tracking 1,200+ OKRs per quarter. Quarterly planning consumed 3 weeks. Engineers had OKRs like 'increase ARR by 0.08%' that they couldn't influence. The system was abandoned and replaced with team-only OKRs (40 total) and individual goals moved to a separate growth plan doc.
OKRs at 50 people
~30
OKRs at 400 people
~1,200
Quarterly planning time
3 weeks
Post-fix OKRs
40 (team only)
OKR systems must be resized as the company grows. What works at 50 people (everyone has personal OKRs) is operationally impossible at 400. The redesign trigger is when planning takes longer than executing.
Decision scenario
The Cascade Collision
You're the CEO of a 300-person Series C company. Q4 OKRs are due Friday. You've published 4 company OKRs. By Wednesday, your VPs have submitted 14 team OKRs combined. Your CFO is alarmed: only 5 of the 14 explicitly tie to a company OKR. The other 9 are team health items (hiring, technical debt, internal tools, customer support SLAs).
Company OKRs
4
Team OKRs Submitted
14
Aligned to Company
5 of 14 (36%)
Team Health OKRs
9 of 14 (64%)
Decision 1
Your CFO wants you to send the OKRs back and demand teams 'realign' so 90%+ ladder up to company OKRs. Your COO disagrees — she says the 9 health OKRs are real work that has to happen regardless of strategic priorities, and forcing alignment will produce fake OKRs.
Side with the CFO. Send the OKRs back with a mandate that 90% must ladder to company OKRs. The team has 2 days to rewrite.Reveal
Side with the COO. Accept the 36/64 split. Ask each VP to write a one-paragraph rationale for each health OKR explaining why it matters this quarter and what happens if it slips.✓ OptimalReveal
Related concepts
Keep connecting.
The concepts that orbit this one — each one sharpens the others.
Beyond the concept
Turn OKR Cascading into a live operating decision.
Use this concept as the framing layer, then move into a diagnostic if it maps directly to a current bottleneck.
Typical response time: 24h · No retainer required
Turn OKR Cascading into a live operating decision.
Use OKR Cascading as the framing layer, then move into diagnostics or advisory if this maps directly to a current business bottleneck.