The Feynman Guide to OKRs: Engineering Strategy Execution

Imagine you are the captain of a massive, state-of-the-art submarine.

You have a general idea of where you need to go—say, a deep-sea research station thousands of miles away. But a submarine doesn’t have windows. You can't just look outside and steer. To get there, you need two things: a destination plotted on the map, and a set of precise instruments (depth gauge, sonar, speed) to tell you if you are actually moving toward it without hitting a reef.

In the world of corporate strategy and engineering management, this is exactly what OKRs (Objectives and Key Results) are designed to do.

Synthesizing the core teachings from the definitive trinity of OKR literature—John Doerr’s Measure What Matters, Christina Wodtke’s Radical Focus, and Ben Lamorte’s The OKRs Field Book—this guide breaks down the framework using the Richard Feynman technique: clear analogies, simple language, and zero corporate jargon.

1. The Anatomy of an OKR: The Compass and the Speedometer

An OKR consists of two inextricably linked parts:

• The Objective (The Compass): Where do we want to go? This is qualitative, aspirational, and memorable. It should inspire the team and set a clear direction.
• The Key Results (The Speedometer): How will we know we are getting there? These are quantitative, measurable, and time-bound metrics. They are the instruments that prove you are moving in the right direction.

"Objectives are the what. Key Results are the how." — John Doerr

If your Objective is to "Build the most reliable API in the industry," your Key Results shouldn't be a checklist of tasks like "Refactor the database." Instead, they should measure the impact: "Achieve 99.999% uptime for 90 consecutive days" and "Reduce p99 API latency to under 50ms."

2. Measure What Matters: The F.A.C.T.S. Framework

In Measure What Matters, John Doerr explains that OKRs are a tool for massive organizational alignment. He breaks down their superpowers into the F.A.C.T.S. framework:

• Focus: By limiting yourself to 3-5 OKRs per quarter, you make hard choices about what not to do. Steve Jobs saved Apple not by doing everything, but by focusing on a few incredible products.
• Alignment: OKRs are transparent. When the CEO's OKRs are public, the engineering team can align their specific goals to the broader company mission.
• Commitment: Everyone agrees on what the priorities are. There is no ambiguity.
• Tracking: OKRs are not a New Year's resolution. They are tracked weekly or bi-weekly. If a Key Result is failing, you adjust the strategy immediately.
• Stretching: Doerr distinguishes between Committed OKRs (must achieve 100%) and Aspirational OKRs (achieving 70% is considered a massive success). Aspirational OKRs push teams beyond their comfort zones.

3. Radical Focus: The Weekly Cadence

Christina Wodtke’s Radical Focus addresses the biggest failure mode of OKRs: setting them at the start of the quarter and forgetting about them until the end.

Wodtke introduces the Four-Square Weekly Matrix, a tactical dashboard for teams:

1. Top Right - The Objective: The single, ruthless priority for the quarter and its Key Results (with confidence levels out of 10).
2. Top Left - This Week's Priorities: The 3-4 most important things we must do this week to move the Key Results.
3. Bottom Right - Health Metrics: Things you must protect while chasing the OKR (e.g., Code Quality, Team Morale, Server Costs). You don't want to hit your Objective but burn out the team in the process.
4. Bottom Left - Next Week: A pipeline of upcoming tasks.

The magic happens in the cadence: Monday Commitments (planning the week to attack the OKR) and Friday Wins (demonstrating progress and celebrating with the team, no matter how small).

4. The Field Book Reality Check: Outcomes vs. Outputs

In The OKRs Field Book, Ben Lamorte tackles the coaching reality of OKRs. The most common mistake engineering teams make is confusing Outputs with Outcomes.

• Output (The Gears): "Ship the new microservices architecture."
• Outcome (The Impact): "Reduce server hosting costs by 30% while maintaining latency SLAs."

Shipping code is an output. It’s a task. It belongs on a Jira board, not in an OKR. An OKR measures whether the code you shipped actually solved the business problem. If you ship the new architecture but costs go up, the Output was achieved, but the Outcome failed.

Lamorte stresses: Never use OKRs as a glorified to-do list.

5. The Alignment Tree: Cascading Strategy

Finally, how do OKRs scale from a 5-person startup to a 5,000-person enterprise? Through alignment.

Imagine a beautiful, glowing tree. The company-level OKR is the thick trunk. The VP of Engineering takes one of the company's Key Results and adopts it as their department's Objective. Their Key Results then become the Objectives for the individual engineering pods (the branches and leaves).

However, alignment shouldn't be strictly top-down. The best organizations use bi-directional alignment. Leadership sets the broad direction (the trunk), but the teams closest to the work (the leaves) propose the specific Key Results on how best to get there.

Conclusion

OKRs are not a performance evaluation tool or a micro-management spreadsheet. They are a communication framework. They align the team's daily tactical execution (outputs) with the company's long-term strategic vision (outcomes).

When implemented correctly—with Focus, a weekly Cadence, and a strict adherence to Outcomes—OKRs become the central nervous system of a high-performing engineering organization.