OKRs (Objectives and Key Results) remain the most common quarterly planning framework at growing tech companies. Done well, they align teams to outcomes that matter. Done poorly, they become bureaucratic theater. Senior EM interviews probe whether you can run effective OKR planning without falling into the common traps.
The structure
- Objective: a qualitative statement of what you want to achieve. “Make onboarding feel effortless.” “Reduce p99 latency to industry-leading levels.”
- Key results: 3–5 measurable outcomes that, if achieved, mean the objective is met. Numeric, time-bound.
Note: KRs are outcomes, not tasks. “Ship feature X” is a task. “Increase activation rate from 35% to 50%” is a KR.
The quarterly cadence
- Week -2: drafts circulate
- Week -1: alignment meetings with stakeholders
- Week 1: kickoff with the team
- Week 6: mid-quarter review
- Week 12: end-of-quarter retro
Writing strong key results
A strong KR is:
- Specific: “p99 latency under 200ms” not “improve performance”
- Measurable: there is a number you can pull on day 1 and day 90
- Achievable but ambitious: 70% confidence; if you would bet your career on hitting it, it is too easy
- Outcomes, not outputs: “checkout conversion 18%” not “ship one-click checkout”
- Tied to the objective: hitting the KR should mean the objective is met
Common KR mistakes
- Vanity metrics that are easy to game (page views without engagement)
- Metrics with no baseline (“improve X” without knowing current value)
- Too many KRs (5 max; 3 ideal)
- Project list disguised as KRs (“complete the migration” with no metric)
- KRs that overlap with peer teams’ KRs without coordination
Stretch vs commit
Some companies (Google) split KRs into “commit” (90% confidence) and “stretch” (50% confidence). Others (Andy Grove’s original) aim for 70% confidence overall.
If your team consistently hits 100% of KRs, they were too easy. If you consistently miss 50%+, calibration is off.
Cascading and alignment
Top-level company OKRs cascade down:
- Company OKR: “Reach $100M ARR”
- Engineering OKR: “Ship features that drive 30% of new revenue”
- Team OKR: “Increase enterprise feature adoption from X to Y”
Avoid cascading too rigidly — let teams own how they contribute to the higher-level goal.
Mid-quarter review
Halfway through, review:
- Are KRs on track? (red/yellow/green)
- Has anything changed externally that invalidates the OKR?
- Are we doing work that does not map to OKRs? (yellow flag)
Update if needed — it is more honest than pretending the original OKR still applies.
End-of-quarter retro
- Score each KR (0.0–1.0)
- Discuss what worked, what did not
- Identify lessons for next quarter
- Don’t treat scores as performance evaluation — they are calibration data
The “OKR theater” problem
Symptoms:
- OKRs written in Q1, ignored until Q4 review
- Teams pad OKRs to ensure 100% achievement
- Daily work has no relationship to OKRs
- OKR review is a checkbox exercise
Counter:
- Refer to OKRs in standups and planning
- Make KR progress visible (dashboard, Slack channel)
- Reward teams for ambitious targets, even partial hits
- Kill OKRs that become irrelevant — do not cling to them
The interview question
“How do you run OKR planning?”
Strong answers describe a specific cadence, give concrete examples of strong vs weak KRs, and acknowledge the common dysfunctions.
Frequently Asked Questions
Should engineering teams use OKRs?
For platform / infrastructure teams, OKRs work less well — outcomes are sometimes “did not break” or “absence of incidents.” Use SLOs and reliability metrics instead.
How many OKRs per team?
2–4 objectives per team per quarter. More fragments attention.
What if my company does not use OKRs?
Use whatever planning framework they have. The principles (measurable outcomes, quarterly cadence, alignment with company goals) are universal.