Objectives And Key Results (OKR)

For over 20 years, I’ve seen countless methodologies come and go in the software world. Agile, Scrum, Kanban… the list goes on. Often, these frameworks become more about doing the process than actually achieving results. Lately, Objectives and Key Results (OKRs) have been gaining traction, and I'm seeing a similar risk. Everyone’s talking about OKRs, but too few teams are truly reaping the benefits.

This isn't another “OKRs 101” post. You can find plenty of those explaining the basic structure. Instead, I want to share how I’ve successfully implemented OKRs within engineering teams – at both fast-paced startups and more established enterprises with over 500 engineers – and, crucially, how to avoid the common pitfalls that turn them into pointless exercises.

The Problem with Most OKR Implementations

Before diving into how to make OKRs work, let’s address why so many implementations fail. I've observed a few common themes:

• Vague Objectives: Objectives like “Improve System Reliability” are a recipe for disaster. What specifically does that mean? It lacks focus and makes measurement impossible.
• Too Many Objectives: Overloading the team with too many priorities leads to diluted effort and nothing getting done well. Aim for 3-5 Objectives maximum per cycle (quarterly is typical).
• Key Results That Aren’t Truly Key: Key Results need to be measurable and directly contribute to achieving the Objective. A Key Result like "Explore new database technologies" might be interesting, but it doesn't necessarily move the needle.
• Treating OKRs as a Performance Review Tool: This is the biggest killer. OKRs should be aspirational, encouraging stretch goals. Tying them directly to individual performance reviews discourages risk-taking and focuses people on safe, achievable targets.
• Lack of Cadence and Review: Setting OKRs and then forgetting about them until the end of the quarter is a waste of time. Regular check-ins are vital.

A Framework for Engineering OKRs That Work

Here's how I approach building effective OKRs within an engineering organization:

1. Start with the “Why” – Linking to Company Strategy:

Before even thinking about Objectives, understand the overarching company strategy. What are the key business goals for the quarter? Engineering OKRs must demonstrably contribute to these. If the company is focused on user growth, your engineering OKRs might center around scaling infrastructure or improving onboarding.

2. Focus on Outcomes, Not Outputs:

This is critical. Avoid OKRs that focus on doing things (outputs) and instead focus on achieving results (outcomes). Shifting to this mindset can be challenging, but it’s essential for realizing the true power of OKRs.

• Bad: Objective: Ship Version 2.0 of the Mobile App. Key Result: Complete 10 user stories.
• Good: Objective: Improve User Engagement with the Mobile App. Key Result: Increase daily active users by 15%.

The first example focuses on tasks. The second focuses on a measurable impact on the user base.

3. The "How Much?" Test for Key Results:

A good Key Result should answer the question, "How will we know if we're succeeding?" and include a specific, measurable target. Think percentages, numbers, or clear thresholds.

• Example:
  • Objective: Enhance Platform Stability
  • Key Result 1: Reduce critical production incidents by 20%.
  • Key Result 2: Improve average API response time to under 200ms.
  • Key Result 3: Increase automated test coverage to 85%.

4. Embrace Stretch Goals (and Accept Failure):

OKRs are not about achieving 100% on every Key Result. Aim for ambitious targets – 70-80% achievement is often considered successful (Doerr, J. Measure What Matters, 2018). This encourages innovation and allows for learning even when goals aren't fully met. Think of it as aiming for the moon – even if you miss, you'll land among the stars.

5. Implement a Regular Check-in Cadence:

• Weekly/Bi-Weekly Check-ins: Brief team meetings to discuss progress, roadblocks, and potential adjustments. These aren’t status reports; they're collaborative problem-solving sessions.
• Mid-Cycle Review: A deeper dive to assess progress against Key Results and make course corrections if necessary.
• End-of-Cycle Review: A retrospective to analyze what worked, what didn’t, and lessons learned for future cycles.

OKR Scorecard

Tracking progress visually can be incredibly helpful. Here’s a simplified example of an OKR scorecard:

Objective	Key Result	Target	Current Progress	Notes/Blockers
Enhance Platform Stability	Reduce critical production incidents	20% reduction	12% reduction	Investigating root cause of recent incidents
Improve API Response Time	Under 200ms	250ms	Working on database optimization

Beyond the Framework: The Human Element

Ultimately, the success of OKRs depends on fostering a culture of transparency, collaboration, and continuous improvement. It's about empowering the team to take ownership, experiment, and learn from both successes and failures. Don't treat OKRs as a bureaucratic exercise; treat them as a tool to help your team achieve its full potential.

I’ve seen countless methodologies come and go. OKRs, when implemented thoughtfully, can be a powerful force for driving focus and achieving meaningful results. But remember: OKRs are a means to an end, not an end in themselves.

Key Takeaways:

• Focus on Outcomes: Prioritize results over tasks.
• Embrace Ambition: Set stretch goals that encourage innovation.
• Maintain Cadence: Regularly check in on progress and adjust as needed.

What one change will you make to your OKR process this quarter to drive more impact?