Going organisation-wide looks faster. In practice a pilot delivers conclusions sooner

The question usually sounds simple: do we go into the whole organisation or start with a piece of it. Intuition says the whole thing, because if it has to be done anyway, better to do it once and properly. This episode starts from that intuition and ends by turning it round. Going in across the board takes more than a dozen weeks of preparation alone: building a transformation team, training twenty, thirty, forty leaders, and once there were eighty of them, and planning out the process. Then several dozen objectives have to be aligned with one another. Instead of one fire in one area, we get a whole forest burning at once, and all of it has to be dealt with at the same time. On top of that comes a risk you don't see in the schedule: a failed organisation-wide launch puts people off and slows down the next attempt.

A pilot is faster, because it yields conclusions faster, but only if it isn't what its name suggests. It isn't a test on something less important, nor an implementation in one department. It is choosing the one thing that matters most to the organisation and focusing all attention on it: one or two objectives for one or two quarters. Around such an objective you gather a working group with the competences it needs, but you don't take people out of their functions full time; you carve out time for them by putting the rest of their work in order. At a small scale you see more, and the conclusions come earlier. In the meantime the rest of the organisation gets metrics and ordinary tidying up of work, so that the day-to-day doesn't collapse.

Under this choice lies an assumption from which everything else follows. OKRs are for operationalising strategy and for quickly testing strategic assumptions, not for tidying up the day-to-day. Hence a conclusion that sounds uncomfortable: not everyone in the company needs their own objective, although everyone works towards an objective indirectly. Covering the organisation in a web of objectives ends in what the numbers from one implementation show: the top wrote a few objectives, each team added five, and there were around ninety of them. Writing objectives per department also entrenches the existing structure and comes down to finding work for everyone, instead of asking what the organisation wants to achieve and whom it needs for that. Objectives like these come out operational, and there are tools better suited to optimising processes.

An implementation is change management, not an exercise in a method

The biggest cost of going organisation-wide isn't in the objectives. It is in the fact that the company then runs two systems of work at once: the old one, which is already a habit, and the new one, which isn't yet. It ends either with the objectives dying or with a lot of frustration. There is one way out, and it isn't glamorous: audit the existing meetings and build work on objectives into what already happens in the company, instead of launching a second circuit alongside it. This applies to the board too, because a board working the old way while the rest of the organisation switches to a new rhythm cancels out the whole change.

The second thing looks like a detail but is a fundamental difference. An implementation exposes dysfunctions and forces decisions about people and processes, but you may only fix what stands in the way of the objective. If the strategy leads into a new market, we don't fix the department serving a market that will be wound down anyway. Some changes also happen without a separate initiative, because working on an objective polarises people in a good sense: they start to see for themselves that something is missing, and either get more involved or drop out. We say all this with a caveat that is stated plainly in the episode: our conclusions are based on experience from around twenty organisations, and beyond that limit guesswork begins.