Your team's OKRs are probably broken (and how to fix them)

Most engineering teams are doing OKRs wrong. Spectacularly wrong.

👋 Hey, it’s Stephane. I share lessons, and stories from my journey to help you lead with confidence as an Engineering Manager. To accelerate your growth see: 50 Notion Templates | The EM’s Field Guide | CodeCrafters | Get Hired as an EM | 1:1 Coaching

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

You've probably seen it: teams setting a dozen objectives, cascading OKRs to every individual developer, and then forgetting about them until the quarter ends in disappointment. After reading Christina Wodtke's Radical Focus, I've realized why most OKR implementations fail - and more importantly, how engineering leaders can fix them.

Radical Focus

Common mistakes

“We have these 5 equally important goals“

If you try to focus on everything, you end up achieving nothing. Yet I've been in teams with 5 objectives for a single quarter.

The fix is radical in its simplicity: one objective per team, per quarter.

Not one objective plus "a few smaller ones". Not one primary objective with backup goals. One. This forces the necessary conversation about what actually matters most.

Cascading OKRs

I have seen OKRs cascade in many companies. Leadership sets company OKRs, then forces them down through every level until individual developers have their own personal OKRs.

By the time individuals have their OKRs they have to remember:

• their OKRs

• their team’s OKRs

• their department’s OKRs

• the company’s OKRs

That’s 4 Objectives and 12 KRs that people need to work towards and contribute within a quarter!!

OKRs and performance reviews

OKRs are team goals, not individual performance metrics. The moment you tie someone's raise to their personal OKR completion rate, you've destroyed the entire system.

Doing that will either lead to

• people sandbagging their targets

• or, get completely demotivated and give up

How great OKRs look like

A good objective isn't a metric. "Increase system throughput by 40%" isn't an objective. An objective might be "Deliver lightning-fast performance that delights users". It's qualitative and inspirational.

The key results then quantify success: "Reduce average API response time from 800ms to 200ms" and "Achieve 99.9% uptime during peak traffic hours". These are outcomes, not outputs. Not "Implement caching layer" (that's a task), but "Reduce database query time by 60%" (that's a measurable result).

If your supposed objective is actually a number, it belongs in the key results section. If your key result is a task or feature, you're tracking outputs instead of outcomes.

How to write OKRs with your team

Run a short workshop with your team, about an hour should be enough. Start by setting the reminding everyone of the company’s/team’s mission and what you learned last quarter. Then brainstorm Objectives by asking, “If we could only achieve one thing this quarter, what would matter most?” Vote and choose a single inspiring Objective.

Once that’s clear, turn it into 3 measurable Key Results. Set stretch goals with the mindset that 70% achievement counts as success. Add a couple of health metrics as guardrails so you don’t burn out the team or sacrifice quality.

Finally, sketch draft Objectives for the next three quarters to give everyone a sense of direction while staying flexible.

The 70% success rule

Good OKRs should have about a 50% chance of full success when you set them. Hitting 70% is a big win, not a failure.

Engineers hate this. We're trained to deliver what we commit to, on time, with high quality. Setting targets we might not hit feels wrong. But if you're consistently hitting 100% of your OKRs, you're probably not pushing hard enough. You're essentially doing project management with extra steps.

The 70% rule forces teams to aim higher and think bigger. It normalizes intelligent failure as a learning tool. That ambitious performance optimization might only get you 60% of the way to your stretch goal, but you'll likely learn more and achieve more than if you'd set a safe target you knew you could hit.

Health metrics / Safety net

Aggressive goals can create tunnel vision. Teams might sacrifice code quality, ignore technical debt, or burn out chasing an ambitious OKR. So you have to have health metrics.

These are the 3-5 vital signs you monitor alongside your OKRs to ensure you're not winning the battle while losing the war. For engineering teams, these might include:

• Average time to resolve P1 incidents

• Customer satisfaction scores

• Technical debt

• On-call escalation frequency

And you want to be keeping an eye on them by asking the team regularly to assess them using a RAG system.

If any health metric turns red while pursuing an OKR, you might want to stop and fix it. Sometimes that red metric becomes next quarter's objective. This prevents the "move fast and break everything" mentality that destroys long-term sustainability.

Your roadmap should be half-empty

Traditional roadmaps pretend we know exactly what needs to be built six months from now. The reality is we have hypotheses about what might work and we can rank these by impact and effort.

Start with a backlog of potential initiatives that could move your key results. Rank them by expected impact versus implementation effort. Work on the highest-impact, lowest-effort items first. When you finish one initiative, measure whether it moved your key results. If not, try the next thing on the list.

The goal isn't to ship everything on the roadmap, it's to find the minimum viable set of changes that achieve your objective. Sometimes the fifth idea on your list works better than the first four combined.

A flow you can follow

Alright, so now you have your OKR for the quarter. You need to use it. Weekly. Most teams set OKRs and then forget them until week 11 of the quarter and then panic.

Try an approach like this:

Monday mornings: Fifteen minutes where you commit to the top 3-4 priorities for the week. "This week we need to reduce login latency by implementing connection pooling and optimizing the auth query".

That should be with a view on the OKRs you have set for the quarter and what’s coming in the next 4 weeks.

Friday afternoons: Everyone demos something they accomplished that week. The frontend developer shows the new dashboard component, the DevOps engineer shares improved deployment metrics, the QA engineer highlights a critical bug they caught.

This isn't just feel-good team building. It creates peer accountability and when you know you'll need to show something on Friday, you naturally structure your work to create demonstrable progress.

Final words

This framework works when you embrace radical focus, measure outcomes instead of outputs, and create systems that drive continuous progress toward meaningful goals.

Your team doesn't need another project management methodology. They need clarity on what matters most, regular check-ins to stay on track, and the psychological safety to aim high knowing that 70% of a stretch goal is better than 100% of a mediocre one.

Start using OKRs like the focus and alignment tool they're meant to be.

The goal isn't perfect OKRs. The goal is to have better focus, which leads to better results, which leads to better teams.

That’s all, folks!

See you in the next one,
~ Stephane