OKRs offer a way to connect strategy – high level abstract goal type things – with delivery – low level concrete detailed task level things. OKRs offer a middle level planning. They are replanned often enough to be flexible while lasting long enough to give enough stability to take on bigger, more ambitious work.
As with so much else about OKRs there is a more agile way of going about this and a less agile way of going about it. Connect strategy to OKRs in the less agile way and you end up back at command and control. The give away sign is that OKRs cascade down the company so teams don’t control their own destiny, ambition is neutered and motivation is lost.
Which approach you take will largely depend on the seemingly academic question: “what is strategy?”
Many people see strategy as a one way street. Strategy making and execution is hierarchal with decisions made at the top are passed down. Alternatively strategy can be seen as emergent property of a cooperating network. Strategy is a two way street, each node both informs strategy making and execution is guided by the resulting strategy.
Depending on how you view strategy you are going to implement OKRs very differently.
Is strategy a kind of planning?
Sad to say, the predominant view of strategy is that it is some sort of grand plan. The plan sets out the “place” the company aims to get to (price, position, etc), plus the route for getting there. Anyone who has studied a little strategy will recognise this as the “Porter view of strategy.”
Strategy as planning inherently sees strategists as master planners, all the relevant information is fed into the strategy/planning department. Experts analyse the data and rationally decide what needs doing. The plans are sent out.
This is inherently hierarchical so it natural to use cascading OKRs as the implementation mechanism. But because teams have little say in setting their OKRs motivation is lost and ambition is neutered.
The is a machine like view of organizations, inherently top-down, deviation from the plan, the strategy, is an error. When OKRs do not directly support strategy OKRs need to be changed.
Study a bit more strategy and you will find that while Porter’s view has appeal it is not the only view. There are in fact many different schools of thought on what strategy is.
Emergent strategy is more agile
To my agile mind the “emergent view of strategy” fits better. Strategy emerges over time from the activities of the organization, part planned, part reactive and part backward looking to explain the past. Professor Henry Mintzberg describes strategy as “a pattern of behaviour over time” which chimes with my pattern thinking.
Strategy is a two way street, teams are edge sensors: detecting technology changes, production techniques, putting products in the hands of customers and gathering feedback. This allows learning and adaption. The organization as a whole is a learning entity: discovering customer need and mastering new capabilities. Teams have the authority to act in the best interests of the company and customers. Over time strategy emerges.
When OKRs do not reflect stated strategy it is a learning opportunity. Ask: why do team OKRs deviate from strategy?
Is the team seeing something which the strategists do not? – in which case the OKRs are signalling back from the edges to the centre.
Is the team able to follow strategy? – maybe it lacks skills or capacity, or maybe it is overloaded with “business as usual.”
Has the intended strategy has been clearly communicated? Or maybe there is no explicit strategy?
Strategy, OKRs and agility
OKRs, like other agile tools, are problem detectors exposing opportunities for improvement.
Perhaps obviously, the “Strategy as a plan” view is going to limit agile to a back-room delivery thing because it passes over the opportunities for feedback and centralises decision making. Conversely, the “Emergent strategy” view entirely compatible with devolved authority, independent teams, experimentation and “the agile mindset”.
When teams act on their own initiative the organization will be more agile. When teams wait for instructions everyone is less agile. There may be a price for agility: teams may repeat work, teams may pursue the “wrong” goals but the price of that efficiency is lost agility which costs in missed opportunities and improvements.
If you want high levels of efficiency and believe in planned strategy you will look to decide strategy and align OKRs with the strategy before you do anything else. However, that results in less agility.
If you want to using OKRs and maximise agility then you need to take an emergent view of strategy. In many ways, we back to the Theory X or Theory Y question.
Download Continuous Digital for free when you subscribe for Allan’s updates
Great and relevant article. For me it also raises a question of the scope of the strategy and if is there One strategy or several strategies for different areas of the business/enterprise? –
Contekst; I work in an enterprise, and we have an overall strategy formulated by the C-level leaders. This strategie set an overall direction for the next 3-5 years.. but that document don’t mention anything on what we want with our CS. Should it? or Should there be a departmental strategy for that area, that not only mention what we want to change/improve, but also how we want to run operations..?
Could you ask? – the ommission creates space for you to fill, understanding whether the omission was an oversight or wheather there was some unexplained thinking behind it would help.
You might also find the idea idea of Level 1 and 2 goals useful here https://www.allankelly.net/archives/6651/level-1-goals-purpose-and-meaning/