OKRs as a strategy debugger (& sandwich maker)
Intended strategy goes wrong in one of two ways. First: it is the wrong strategy. It might be badly conceived, it might aiming at the wrong target, it might be based on weak analysis or mis-understanding.
Or it might go wrong because it is poorly executed. Strategy execution begins as soon as strategy is decided on because it needs to be communicated. Bungle the strategy communication and you are unlikely to recover.
Indeed communication issues run all the way through strategy execution because the meaning of any message is decided not by the speaker but by the listener. The executive charged with explaining strategy might think it is clear but each received understands the message in their own context. Even if the executive uses clear language – and lets face it, many don’t – they have no way of knowing what the receiver takes away.
The only way to know if a message is received correctly is with feedback. Similarly, feedback is needed if bad strategy is to be exposed. The executives setting strategy may lack information which those on the ground have and which undermines strategy. Executives think the strategy is great but to everyone else, the emperor has no clothes.
In other words: Linus’ Law applies to business strategy as much as computer software: “given enough eyeballs, all bugs are shallow”. Exposing more people to a strategy allows more brain power anymore information to be applied. But those brains can only have an influence if there is some means of feedback.
This is where OKRs come in. OKRs make strategy visible.
Remember that in my formulation teams set their own OKRs. This is the first test. Leaders set out the organization purpose, missions, visions, grand goals and strategic intent then ask the teams: “how can you help?”
Teams respond by setting OKRs which will advance on those goals. OKRs, written in a standardised format, are feedback from the teams to the upper echelons.
In my model leaders and managers are stakeholders in teams. While teams, which may include managers, are as autonomous as possible they are not free to do what they like. They are part of a system and exist to deliver to stakeholders. As such I expect team OKRs to be reviewed by leadership and those leaders to provide feedback. This is a debugging loop.
1. Leadership sets the strategy and intent, then communicates it out.
2. Team members hear and formulate OKRs to deliver that strategy and intent as they understand it.
3. Leadership reviews OKRs and will expect to find OKRs which, well, support their intent.
This “OKR sandwich” is fits with the Strategy Rethink I’ve talked about before. The sandwich creates two opportunities for misalignment (bugs) to be exposed. First when the team sets the OKRs, they might find the strategic intent does not match their world. That might be a misunderstanding or it might be because team members have information leadership does not.
Second, when leadership reviews OKRs they have the opportunity to find bugs. Discrepancies found at this point might indicate communication has failed, or it might indicate the team have additional information.
To be clear: OKRs which don’t match expected strategy are not the cause of problems but a symptom. Noticing the discrepancy early means corrective action can be taken quickly. Yes the OKR needs, but so too does the cause of the discrepancy.
Even after the OKR setting and review process, during execution, OKRs continue to play a debugging role. It is at this point that the “rubber hits the road” for the first time. Thus it is necessary for executives to keep feedback channels open.