Two models of OKR implementation. Neither is better, each pays its price somewhere else

The first model is team-based. Every department has its own goals, and the goal structure copies the company structure. Its advantage is real: it is easy to lay out, because it uses something that already exists, and nobody has to think about who works with whom. The price is paid in two places. The first shows in the numbers: our guest's first implementation, eight years ago, in an organisation of a thousand people, in which every team got its own goals, ended up with roughly two hundred goals and was described as a nightmare of alignment and administrative overhead. The second is quieter. When I have my department's goal and I see the company's goal, sooner or later I reach a moment when I would have to neglect mine to help someone else deliver the shared one. That conflict can't be resolved at my level, so it lands with the board.

The second model is cross-functional. There are fewer goals, and teams are formed around them, not the other way round. The decision from the previous paragraph then stays within the team, because the team is built to deliver that one goal. The price is concrete too: you have to drop the assumption that everyone must have an OKR, and in companies that assumption can be stronger than any argument. Neither of these models is better. The choice follows from the answer to the question of why we are implementing OKRs, and from the size and maturity of the organisation, with problems in the flow of information between departments starting somewhere around thirty or forty people. If you don't know which to choose, it is more sensible to run pilots of both and compare than to settle it in theory.

The second strand of the conversation is sharper than the comparison itself. OKRs don't describe all of a company's work, and pushing maintenance and support work into them is the source of goal bloat. Accounting, the helpdesk or support don't need a quarterly goal, but a health metric with a green line they must not fall below. A team that has no real influence on sales doesn't have to pretend to contribute to the strategy: it is better to start from the question of its own mission and build goals around quality, volume and productivity. That is an operational goal, and that is fine.

What you can't see when you run an implementation from the inside

Two remarks from this conversation stay with you for longer, because they concern things you won't find in textbooks. The first: the cost of alignment is not fixed. As long as the key results go according to plan, synchronisation is cheap and short. When things start to fall apart, meetings and coordination multiply sharply, so the implementation costs the most precisely when you can least afford it. The second: a board member should not run the implementation in teams they themselves depend on. That is a conflict of interest in which the role of the facilitator gets mixed up with the role of the boss, and none of the participants will say so openly.

There is also an admission in this conversation that is close to our own experience. An implementation run from the inside loses the whole structural layer: the implementation plan, a written-down way of working, owners and a measure of success for the process itself. Someone from outside adds it by reflex, because they have done it before, and that is one of the reasons they are worth their price. Our guest talks about this using his own implementations in which that layer was missing. On top of that comes something we in this industry spoil ourselves: the most important effects, namely focus, clarity and better questions at board meetings, often have no number, and the dogma that says without a number it isn't a goal makes you throw them out of the account of success.