The person who owns the OKR and has no authority to move it

There is a structural gap in most OKR systems that almost never gets named directly and it consistently breaks execution before anyone notices.

Most leadership teams assign a Key Result owner. The name goes into the tracker. The quarterly review confirms ownership.

And yet, week after week, that Key Result stalls not because the person is disengaged, but because they were never given clarity on what they are actually authorised to decide.

They cannot reallocate budget without approval. They cannot pull capacity from another function without negotiation. They cannot change the approach without a meeting that takes two weeks to schedule.

They own the outcome on paper but they own very little of what it takes to move it.

This is not an accountability problem. It is a structural one  and it looks different depending on where you sit and how large your organisation is.

In organisations under 500 people, this gap tends to show up as invisible dependency on the CEO. The Key Result owner makes progress until the first decision that crosses a functional boundary and at that point, everything routes back to the top. The CEO becomes the unintended decision layer for every OKR that requires cross-functional movement. Ownership exists in name but decision authority was never transferred.

In organisations above 500 people, the same gap takes a different form. Ownership is fragmented across layers (a VP owns the outcome, a Director manages the work, a team lead runs the weekly updates). When a blocker appears, it travels up through each layer before a decision is made, often arriving too late to change the quarter's trajectory. The system looks structured but the decision path is not.

How this feels by function:

CEO / MD — You assigned owners to every Company Key Result. But you are still the one unblocking most of them. The system is not broken, the decision boundaries simply were never made explicit.

Chief of Staff / Strategy — You spend a significant part of your week translating blockers into requests the CEO can action. The work of connecting strategy to execution has quietly become the work of managing a decision queue that should not exist.

HR & People  — You are trying to build performance and development systems around outcomes that leaders are expected to own, but were never given the authority to decide. When accountability is structurally unclear, what looks like a leadership behaviour problem is almost always a decision boundary problem and that distinction matters for every conversation you have about performance.

Operations — You can see exactly where throughput is breaking. But correcting it requires capacity or priority decisions that sit above your formal authority, and the path to those decisions is slow enough that the quarter moves faster than the system does.

Sales / Commercial — Your pipeline OKR depends on Product prioritisation, Marketing conversion, and CS onboarding speed. You own the revenue number. You influence roughly one third of what determines it.

The fix is not a restructure. It is a decision boundary map, a simple document that, for each Key Result, defines what the owner can decide alone, what requires alignment with one other function, and what escalates and to whom within 48 hours. One page, built in a single working session.

When that clarity exists, ownership becomes real and execution stops routing through the people who were never meant to be in the path.

If this is a pattern you recognise in your leadership team, I am happy to share what that boundary map looks like in practice.

Mike Dias

CEO, SV Execution Partners