Enterprise OKR governance. Steer the portfolio, not the people.
In a large organisation, OKRs rarely fail at team level first. They fail one level up, where nobody decides which goals get the people, so every goal gets a bit of everyone. Governance is the layer that decides. It isn't glamorous. It's also where most of the value is hiding.
Five decisions that keep a portfolio honest.
01Not every team gets a strategic OKR
Which teams carry strategic OKRs follows from the strategy and this year's crux, never from fairness. Most teams, most quarters, should be running their day job brilliantly on a KPI scorecard. Hand every team a strategic OKR because it feels inclusive and twenty company goals quietly reappear, each wearing a team's name badge.
02If you can't name the team, it's a wish
The portfolio holds as many strategic OKRs as leadership can genuinely resource. The test is simple: name the dedicated team and the capacity you freed up for it. Can't? Then it isn't in the portfolio, it's on a wish list. Wish lists are lovely. They don't ship.
03Teams choose the bet. The portfolio funds it.
Aligned, not cascaded, still holds. Teams draft their own OKRs without approval chains. What governance controls is entry into strategic resourcing, because a dedicated team and freed capacity are leadership commitments, and no amount of empowerment can conjure those out of thin air.
04Priority order is for arguments, not for goals
Leadership ranks the portfolio. The ranking settles resource fights and decides what gives first when something lands badly. It doesn't generate goals for the divisions. The moment it does, you've rebuilt the cascade with extra steps.
05Nothing joins without something leaving
Every quarter, each strategic OKR is continued, completed or killed. Anything new has to name what it replaces, because capacity is conserved, not wished into existence. And when a shock hits, review the whole portfolio, not one goal. Shocks rarely have the manners to hit one bet at a time.
Four kinds of conflict. One ladder.
Conflict is a sign people are taking OKRs seriously. The failure is leaving it unflagged. A conflict raised in week two is a plan. Raised in week eight, it's a post-mortem.
The day job against the OKR. The everyday one.
Two OKRs want the same specialist. Usually the one data engineer everybody has heard of.
One division's dependency is another division's distraction.
Genuine disagreement about the approach. Often the most useful kind.
01Inside the team
At the weekly check-in. Most time conflicts end here.
02OKR lead and line manager
When day-job demands exceed what was agreed when the team formed.
03Executive sponsor
The designed first escalation. Unblocks, renegotiates, or takes it to peers.
04Portfolio level
Decided by the priority order. Never by whoever shouts loudest or books the meeting first.
Belief conflicts don't go up the ladder. They go into a room, with the evidence on the table, one question to take the ego out of it (what would have to be true?) and the decision-maker named before anyone starts.
OKRs can't be the container for everything.
In most large organisations, OKRs end up holding outcomes, outputs, discovery and keep-the-lights-on work all at once. Each thing is there for a sensible reason. Together they drown the signal. Governance gets much easier when every type of work has its own home, its own logic and its own reporting.
01Strategic OKRs
Executing strategic choices. Anchored to why a customer would choose you over a competitor.
02Operational Excellence OKRs
Running the core better. Labelled honestly, because the label changes how they are resourced and judged.
03Initiatives
The work that moves key results: projects with an end date, and experiments with a hypothesis.
04Discovery
A process, not an OKR. Starts with a hypothesis, ends with go or no-go.
05KTLO and business as usual
Health metrics, projects and sprints, on their own reporting layer.
The real example: converging OKRs across a multi-category group.
Count the teams a goal needs.
One team holding everything it needs is the safest goal you can write. Two teams is fine, with one named owner. Three or more, each with priorities of their own, is a redesign, not a coordination challenge.
Here's why. For a team in one division to serve another division's goal, that goal has to outrank its own goals in its own priority list. It almost never does, and it shouldn't, because the team is measured on its own results. So the dependency is honoured when it's cheap and quietly dropped when it isn't, which is exactly when it mattered.
That isn't a coordination problem. It's a conflict of accountability, and it only resolves where the teams share an owner. Better dependency tooling makes a bad structure visible. It doesn't make it work. Redraw the goal, or form one team that holds the whole thing.
You know governance is missing when...
Q&A
What is OKR governance? +
The layer above team OKRs that decides which teams carry strategic goals, how many the organisation can genuinely resource, how conflicts between goals are settled, and what gets continued, completed or stopped each quarter. It governs resourcing, not what teams choose to commit to.
How many OKRs should an enterprise have? +
As many strategic OKRs as leadership can name a dedicated team and freed capacity for. In practice that is far fewer than most organisations start with. If the leadership team cannot name them from memory, there are too many.
Who owns OKR governance in a large organisation? +
The leadership team owns the portfolio, an executive sponsor runs it, and an OKR lead keeps it honest week to week. It works best as a decision forum, not a compliance office checking whether goals were entered on time.
How do you resolve OKR conflicts between divisions? +
Resolve at the lowest level possible: inside the team, then the OKR lead with the line manager, then the executive sponsor. Conflicts between two strategic OKRs are decided by the portfolio priority order, agreed in advance. Disagreements about approach go to a workshop with the evidence, not up the ladder.
We'll show you how it works and share case studies.
Then you decide.