Getting Started with Objectives & Key Results

OKRs are not plug-and-play. They’re not a magic framework you sprinkle on top of chaos and suddenly get strategy, alignment, and velocity. They are a discipline. A set of practices. And they only work when the foundations are in place.

So what do you need?

1. A Clear Strategy

I’ve worked at a few customers that have tried, unsuccessfully, to implement OKR, and every time it comes down to a lack of leadership in defining and communicating clear strategies that everyone can understand.

“Is there a product charter that lays out the mission and strategic goals? Do all members of the team understand both, and are they able to see how their work contributes to both?” — DIB: Detecting Agile BS

Strategy should drive execution. If you don’t know where you’re trying to go over the next 1 to 5 years, OKRs won’t help. They’ll float. They’ll drift. They’ll get turned into a quarterly to-do list that looks busy but delivers nothing that matters. Worse, they can just become a work breakdown structure and a disaster waiting to happen.

2. A Culture That Embraces Transparency, Inspection, and Adaptation

OKRs will fail if your organisation tries to turn plans into contracts, hide things it does not like, or resist feedback. We need to be open by default. We need to welcome inspection and are willing to adapt.

Change is something to be expected and the norm rather than the exception. This is about building systems where learning is baked into the way that we do things. Agile, Scrum, and DevOps all share the same fundamental requirement for success. If you are failing at them, then OKRs will not solve any problems. You need to look in the mirror and deal with what’s there first.

OKRs surface misalignment; they are as much like a mirror as Scrum is. They expose a vague strategy and an incoherent execution. But they only help if people feel safe to inspect and adapt. Without that culture, OKRs become fear-driven, and the outcomes become distorted.

3. Team Agency

OKRs only work if the people doing the work have the agency to shape how they deliver outcomes. If you’re still managing with command-and-control, resource allocation, individual performance metrics, centralised plans, and siloed functions—admit it. You don’t want agility. You want a Gantt chart and a work breakdown structure. You’ll never unlock the creativity and accountability that OKRs demand.

“Are teams empowered to change the requirements based on user feedback?” “Are teams empowered to change their process based on what they learn?” — DIB: Detecting Agile BS

OKRs work best when teams self-manage against shared constraints. This requires clarity on purpose, context for decision-making, and boundaries that support autonomy rather than inhibit it.

4. A Belief That Outcomes Matter More Than Output

OKRs are fundamentally about outcomes. Not effort. Not headcount. Not feature delivery. If your leaders still reward activity over impact, OKRs will feel performative and punitive.

You have to believe that measurable, meaningful change is the point. Everything else is just activity.

Shifting to an outcome mindset means asking better questions:

• What behaviour are we trying to change?
• What evidence will show we’re making progress?
• How can we empower teams to find better ways to achieve the outcomes?

Without this mindset, OKRs will get gamed, ignored, or weaponised.

The OKR Structure

OKRs exist to translate strategy into action. That’s it.

• Objectives clarify where you’re going.
• Key Results define what success looks like.
• Execution is how you actually move toward it.

A simple, powerful format: “I will [Objective] as measured by [this set of Key Results].”

This structure gives you clarity, focus, and alignment. And when used well, it drives the shift from output to outcome.

Too often, organisations obsess over the Objective and treat the Key Results as a laundry list. That’s a mistake. It’s the Key Results that create leverage. They force clarity. They reveal intent. They make progress inspectable.

Why Do We Need Objectives?

Objectives provide direction in the chaos and reconnect execution to strategy. Without them, you’re just busy. And busy doesn’t mean valuable. We just have output.

The purpose of objectives is to:

• It forces you to focus. Limit the number. Ruthlessly.
• Connect directly to your strategic goals.
• Give teams something meaningful to rally around.
• Shift the conversation from “what are we doing?” to “why does it matter?”

The objectives help us resolve the goals from Scrum or Evidence-based management and can create the intent from intent-based leadership. They make the strategy visible and the contribution clear.

A well-written objective is outcome-oriented and time-bound. Not vague. Not incremental. And never written as “continue doing X.”

Why Do We Need Key Results?

Key Results aren’t just metrics. They’re commitments.

They:

• Push teams to define what success looks like
• Enable autonomy by giving teams room to decide how to achieve it
• Anchor discussions in data, not opinions
• Help leaders focus on enablement, not interference

Key Results aren’t there to punish failure. They’re there to surface learning. If you hit 100% of your Key Results every time, your goals were too easy.

That’s not success. That’s sandbagging.

Execution Isn’t Optional

OKRs aren’t a quarterly workshop. They live and die in the execution. If you’re not inspecting progress weekly or biweekly, they will drift. Strategic priorities will get lost in the noise of delivery.

You need a cadence. A rhythm. A system for:

• Reviewing progress
• Re-aligning focus
• Adapting based on learning

Additionally, reassess your OKRs at least every quarter. But don’t wait until the end to find out if they mattered. The feedback loop is the heartbeat of OKRs. Without it, they become theatre. With it, they become a mechanism for continuous adaptation.

OKRs are iterative and outcomes incremental

You won’t get it right the first time. Or the second. Or the third. You’ll write vague Objectives. You’ll write vanity Key Results. You’ll set goals that are either too big or too small.

That’s fine.

OKRs are a practice. You refine them over time. The point isn’t perfection. The point is progress. Use a retrospective on your OKRs and refactor your goals. Treat them as living artefacts. That’s how you get better.

  
flowchart TD
VMV["Vision, Mission, Values\n(5 to 20 years)"]
STR["Strategies\n(1 to 5 years)"]
OBJ["Objectives\n(Quarterly to Yearly)"]
KR["Key Results\n(Quarterly to Yearly)"]
ACT["Activities (Execution)\n(Day to Day)"]
MEA["Measure\n(Day to Day)"]
LEA["Learn\n(Weekly to Quarterly)"]

    VMV --> STR
    STR --> OBJ
    OBJ --> KR
    KR --> ACT
    ACT --> MEA
    MEA --> LEA
    LEA --> STR

    classDef yellow fill:#f9c74f,stroke:#333,stroke-width:1px;
    classDef green fill:#90be6d,stroke:#333,stroke-width:1px;
    classDef blue fill:#43aa8b,stroke:#333,stroke-width:1px;
    class OBJ yellow
    class KR green
    class ACT,MEA,LEA blue


  

This is what OKRs make possible: a living connection from strategy to execution, and back again. This is the cadence that drives organisational agility. This is why OKRs matter.

If you’re struggling to make OKRs stick, don’t blame the tool. Inspect your system. Look at your strategy. Look at your culture. Look at your cadence.

Because you can’t shortcut clarity. You can only create the conditions for it to emerge.