strategy - Allan Kelly

OKRs create strategy alignment but not in the way you think they do

OKRs, Strategy / allan kelly / July 5, 2023 / okrs, strategy

Flat 3d isometric business people came from different way but have same target. Business team and target concept.

One of the claims made of OKRs is they solve the problem of alignment, strategic alignment specifically. So, anyone reading Pull don’t push OKRs post might be wondering how this can be. I’m sure many people will ask how alignment can be achieved without some master plan and planner?

The obvious way to ensure teams are aligned with company strategy is clearly to tell them what to do. Obviously, if we have some master planner sitting at the centre they can look at the strategy, decide what needs doing and issue command, using OKRs, to teams.

Think of this like programming: there is a core controller and each team is a sub-routine which is called to do a bit. Alignment can be programmed through step-wise refinement with each layer elaborating on the ask and passing instructions down.

Obvious really. Why did even bother describing it?

Obvious and wrong

Obvious too is that this is not Agile. But heck, we’re all “pragmatic” and obviously achieving this kind of co-ordination requires some compromise and in this case commands must be passed around.

Personally, I have an aversion to any scheme that involves telling others what to do. There are just so many things that could go wrong, far better that to come up with a scheme that is failure tolerant.

Rather than spend my time explaining why this approach is wrong let us try a thought experiment: for the next few minutes accept I am right and we can’t tell others what to do. (Leave me a comment if you want me to set out the reasons why.)

Now the question is: what does work does?

Emergent alignment.

This is a design problem (“how do we are design work so disparate teams work harmoniously to a common goal?”) so the principle of emergent design should work too. We want to create a mechanism which allows design to emerge.

Now OKRs have a role to play.

By setting out what a team intend to achieve in a short, standardised, format OKRs allow intentions to be communicated and shared. Thus OKRs can be placed next to other OKRs and compared. Sharing in a standardised format allows misalignment to become clear. Once the problem can be seen action can be take to realign: OKRs build a feedback loop.

OKRs are another example an agile tool which allows problems to be seen more clearly. Someone once said “Agile is a problem detector”, for me OKRs are a strategy debugger. Simply using OKRs does not automatically solve the problem, but it makes the problem to be solved clearer.

The organisation sets out its goal(s) and strategy. Teams are asked to produce OKRs to advance on that goal. If the strategy incorporates all necessary information, is communicated clearly and teams are completely focused on the strategy then everything will work.

But, if strategy is absent, if the strategy has overlooked some key piece of information, if the strategy is miscommunicated (or not communicated at all) or teams have other demands then things will not align. When this happens there is work to do, now we want to correct problems and create OKR-Strategy alignment.

Step 1: the centre, the senior leaders set out the strategy and goals – which should themselves align with the purpose and history of the organization.

Step 2: teams look at these goals, look at the other demands on them and the resources they have, and ask themselves: what outcomes do we need to bring about to move towards those goals while following the strategy?

They write OKRs for the next period based on their understanding.

Step 3: members of the centre look at those OKRs and talk to the team. Everyone seeks to understand how the OKRs will advance the overall goal. If everything aligns then great, start work!

If alignment is missing then work is required: perhaps work on the OKRs, or perhaps the strategy needs clarifying or the goals adjusting.

Because this approach is feedback based it is self-correcting. The catch is, for the feedback loop to work people need to invest time in reading OKRs and looking for alignment, and misalignment, and correcting.

In the “obvious solution” you don’t need these time consuming steps because the centre assumes it is right and anything which goes wrong is someone else’s fault.

By the way, a smaller version of the alignment problem is sometimes called “co-ordination.” This is where two, or more teams, need to align/co-ordinate their work to create an outcome, e.g. Team A needs Team B to do something for them. The same principles apply as before, only here it is the team members which need to compare the OKRs.

So there you have it. OKRs are a strategy debugger and they create alignment by building a feedback loop to promote emergent alignment.

OKRs create strategy alignment but not in the way you think they do Read More »

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.