OKRs (Objectives and Key Results) are, for many organisations, still a relatively new term that, as such, can hold the promise of an idealised future while moving again the goalpost to a later tomorrow.
And the term OKR creates enough ambiguity allowing different conflicting interpretations (e.g. a new fancy name for KPIs) to coexists. But once OKRs are well understood and properly put to practice, are they really good for innovation?
Which OKRs for horses would have helped to invent the car?
Which OKRs for bookshops would have helped to invent Amazon?
Which OKRs for road atlases would have helped to invent Google Map?
Which OKRs for rotary dial phones would have helped to invent the iPhone?
This below is a summary of an extensive conversation about the limitations of OKRs when used to drive innovation. The conversation was triggered by the four questions above.
Many agree that OKRs can be good for an ordinary evolution, operationally.
But what about for innovation: such as making a new discovery, an invention, creating a new product that did not exist before, producing a disruptive change?
I may be wrong but It seems to me that for driving innovation OKRs do not help. In a sense, OKRs are backward-looking and future-blind.
These below are the main objections and the related answers that emerged from the conversation.
OKRs are a form of Management by Objectives (MBO) which itself was first popularized in 1954 by Peter Drucker. This leads to an interesting question: can innovation be “managed“?
When one tries to write down the OKRs for the four questions above, the related Objectives would end up being either too generic or too specific.
For example in an Apollo 13 “Houston, we’ve had a problem here” situation, any Objective would inevitably boil down to “Get the crew back safely to Earth.” And how does that generic Objective help to find a working solution to the problem?
Alternatively, the Objective would contain elements of one possible solution, leading to a tunnel vision. Try yourself.
The issue is, how can one define an Objective for opportunities that are still unknown, yet to be discovered or invented? One cannot.
Because most inventions are oblique, unpredictable, emergent, the result of a mistake or of repurposing something novel for a totally different purpose (think microwave ovens, coca-cola, post-it notes, penicillin, gin and tonic, …) instead of being the result of a linear effort to fulfil a predefined Objective.
The solution found for the “Houston, we’ve had a problem here” was to repurpose some of the instrumentation available onboard to achieve an incredible mission. The invention of the car was made possible by the creation of the clutch that allowed standing stars for terrestrial cars. Before that, the internal combustion engine could only be used in outboard boats that in the water did not face that problem.
One way that could work would be to define multiple parallel Objectives representing multiple promising directions of investigation. Yes, but this way would be something different from the OKR technique.
Setting and tracking Key Results for innovation makes things even harder than setting Objectives for innovation.
One way is to set KRs as generic high-level business outcomes and impacts. Those will likely be lagging indicators moving the needle with a long delay after any action. So they will be of no use to inform or drive the innovation. Even more, when an action or experiment fails to deliver the expected KR, that leaves us alone with a blank page to figure out the next experiment, and how to pivot, without suggesting any direction and without giving any indication. The KRs will leave us alone at the exact moment when we need help the most. In this regard, these KRs are useless for innovation, a waste in Lean terms.
An alternative to setting generic high-level KRs is to set KRs that are specific. But how can someone know what to measure and how to measure something that does not exist and has yet to be invented? Even figuring out the unit of measurement would be impossible when one doesn’t know what to measure. That would be like asking how much time it takes to fix a bug, when to answer the question one first needs to find the defect that is causing the bug, and in most cases that already would account for 80÷90% of the time needed to fix the bug.
And even if one magically succeeds in the impossible, predicting the right things to measure in order to drive a specific innovation, KRs have the same problems as any other numeric-objectives system: they tend to get what you measure, not necessarily what you want (e.g. see gaming the metrics), and as the context quickly changes and evolves they quickly become outdated and irrelevant. And otherwise, KRs that change again and again as things change and evolve, once again would be something different from the OKR technique.
Some of the merits of OKRs is to catalyse the conversation around the goals and the vision, to create common understanding and consensus between management and employees, to align objectives across the organization. To shift the conversation from output to outcomes, that has the potential to empower employees.
This sounds great. Is it enough when we are working toward an Agile environment?
OKRs are a form of Management by Objectives (MBO), they are a step forward from a hierarchical-driven organisation, but they still lack the trust and collaborative nature of a people-centred relationship-driven organisation such as in an Agile organisation. This becomes more evident when OKRs are cascaded in a top-dow fashion or when they are connected to individual bonuses and individual performances reviews leading employees to try achieving the set goals by any means necessary, often at the cost of the company.
When OKRs are used for innovation even those merits become fragile. How can an organisation align toward something that does not exist yet? An opportunity that has yet to be discovered? And invention that has yet to be made? And when we try to define the objectives anyway, this brings us back to the first point A from the beginning.
In the end, taking into account all the points above, it is a matter of context. As it is described in the visual at the top.