The objective owner doesn't deliver the objective. The key result owners do

A quarterly objective has one sentence and a few key results. A key result is nothing more than an explanation of how we will know we have achieved the objective, so it is always measurable. We then assign a person responsible to the objective and to each key result: the objective owner and the owners of the individual key results. This step looks like a formality, yet it decides the quarter more than the wording of the objectives does. The whole layer exists, after all, so that people have a way of relating to the strategy. An annual goal along the lines of we will double revenue gives an individual in marketing or in a product team nothing to which they could add their own work, and a strategy locked in the CEO's drawer or existing only in the board's heads doesn't give them even that. A quarterly objective with names next to the key results is the first place where you can say at all who will do what about it in the coming weeks.

And here is the thing that gets lost most often in conversations about OKRs. The whole weight of delivering the company objective rests on the key result owners, not on the objective owner. They are the ones who lead teams and solve the most problems. The objective owner's role towards them is a supporting one, and that is not a demotion, it is the right division of work. In conversations about OKRs they get talked about far too little for how much depends on them.

The second thing that surprises companies: this structure has little to do with hierarchy. We look at the organisation from the perspective of business results, not departments, so a key result owner is sometimes someone who, on the organisation chart, is nobody's manager. The same model works in a company of a few dozen people and in one of a thousand, because the hierarchical structure serves a different purpose than achieving goals.

That is why this text is not about writing objectives. It is about who is responsible for what, where the line runs between the objective owner and the key result owner, and what happens when such a role exists only on a slide.

A key result owner is a project manager, they just rarely get told so

The closest description of this role is a real project manager: someone with a specific goal and budget who brings the whole team together, explains why and what for we are doing this, and then makes sure everything surrounding that work actually happens. This is not a reporting role. The person in it doesn't give accounts of progress, they create the conditions in which progress is possible at all. The line between the two roles is fairly simple. The key result owner is responsible for making the result happen: they pick the team, agree working rules with it, run the reviews and keep an eye on measurement. The objective owner is responsible for making sure the key result owners aren't left alone with it: they connect them with one another, make sure the numbers are up to date at any moment, and gather the lessons from the whole objective.

The team for a key result is put together by answering one question: whom do I need to deliver this. Not the question of who sits in my department. In the episode we walk through this with a hypothetical private healthcare company that wants to increase the ratio of online to phone bookings and, in a given quarter, get people to book tests through the mobile app. For a single key result it needs people from IT, sales, customer support and marketing, plus the person responsible for internal training. For one key result, not for the whole objective.

The worst thing you can do at this point is to put together a team that doesn't have the competence needed to achieve the objective. It sounds obvious, and it happens regularly, because picking people is often treated as an administrative task, when it is the first decision the key result owner makes.

That leaves something that looks like an organisational detail, yet it is exactly the moment when implementations fall apart. A team drawn from different departments is made up of people with different working habits: marketing plans one way, developers another. The wise advice then is: build a team, hold joint reviews and retrospectives. That won't happen by itself. Someone has to get these people to the point where they learn to work together at all, and that work has an owner, the key result owner.

What to do about it before your next quarter

Start with the cheapest thing. Write down what the role of a key result owner involves and present it to people before the quarter starts, instead of assuming everyone knows. Very often it isn't that someone doesn't want to. It is that they were given responsibility but not a description of the role, nor time, nor support, and were left alone with it. On the same occasion, settle the roles inside the team before it starts work: who is accountable for the result, who physically does the work, whom we consult and whom we only keep informed of what is happening. It is one conversation, and it spares the team a good part of the communication chaos later on.

Then run a negotiation workshop with the team that is actually to deliver the objective. The first time, it is a one- or two-hour workshop: you present the idea, the context, the hypotheses and how you intend to measure, and the team works out the final version of the key result from it. Along the way you check not only ideas for initiatives, but also whether the team's current work is blocking the objective. In the episode we show a scene in which IT says it has other priorities right now and marketing already has a campaign planned for this quarter, so the key result owner goes to the objective owner and says plainly that in this version the objective can't be achieved. The whole value of that scene comes from its timing: it happens before the quarter starts, so the change costs one meeting, not three lost months.

On top of that there are two conversations that are easy to forget. A horizontal one, with the objectives and teams alongside, so that it comes out in time that two objectives are fighting over the same people. It is done in one meeting at which representatives of all the quarterly objectives say what they are planning and whom they need for it. And a vertical one, with the owner of the annual goal, to check whether, after all the adjustments, the quarter still leads where it was meant to lead.

Finally, the rhythm, and here it is worth being modest in your demands. The cycle itself is quarterly or four-monthly, and with four months there are three cycles in a year instead of four. Take an inventory of the meetings the team already has and fit the review and the retrospective into them, instead of adding new ones. Put the meetings for the whole cycle into the calendar straight away for the entire period, at fixed times, because that is where the habit comes from. If the team is only just starting to work together, don't add a new tool at the start, use the one it already knows. Also settle before the start who measures the key result, where they get the data and how often they update it, because otherwise measurability stays a declaration: there is a number in the objective, but nobody is responsible for pulling it out. None of the meetings in the cycle should last longer than an hour, and a progress review of a key result fits into fifteen minutes. The objective owner and the key result owners see each other at least once a month, although in practice contact every week or every two weeks works better, in meetings of up to half an hour.

What happens when the role isn't there

The most common variant doesn't look dramatic. The role is filled, a person has their name next to it, and they have neither the time, nor the resources, nor the skills to carry it, and on top of that nobody has given them support. The objective doesn't die loudly then. Nothing simply happens around it for the whole cycle, and the key result owners come to the summary meeting without updated numbers, so you don't even know how badly it went.

The second variant is an objective thrown at a team to carry out, with the negotiation skipped. The reaction is then usually the same: why are we doing this at all, and why are we only here to execute. That is not resistance to change. It is a question someone should have answered earlier, and answering it is the key result owner's job, not an extra ambition.

The line about reviews and retrospectives that I started with is something we say too. For a long time we didn't add the second half to it: who specifically is to do it, where they will find the time and who will help them when the team turns out to be a group of people speaking different working languages. Adding that second half gives more than one more tweak to the objectives themselves.

There is one more thing left, the cheapest on the whole list and the one most often skipped. The team working on a key result draws lessons along the way that are material for decisions about the next periods: what to keep doing, what not to repeat and what to stop working on. In most organisations these lessons go nowhere, because nobody has set up a regular moment when we share them. The change you see after a well-run cycle is modest, by the way: when you ask who is delivering this key result, you hear a person's name, not the name of a department.