3 key problems (and 1 non-problem) I see when attempting OKRs
Original 15 March 2020 Twitter thread.
The key overall problem I see we’re solving with OKRs is strategy deployment OR “how do we get a lot of people aligned and coordinated to achieve a shared outcome?”
My particular concern is strategy deployment when multiple teams are involved. This is one reason why I don’t particularly care about individual OKRs (the other being undermining team focus).
Problem #1: Alignment to nonsense
The first issue is Alignment to Nonsense. What data and rationale led to the Objective you’re setting, never mind how to achieve it?
Toyota people talk about this as “no hoshin kanri (strategy deployment) without A3 thinking”. Spotify created DIBBs (Data Insights Beliefs Bets) to address this kind of issue.
More generically, what is the product and/or business strategy that we are deriving the Objectives from?
Problem #2: Lack of actual alignment
The second issue is Lack of Actual Alignment. This is the use of OKRs to create a “cooperative social contract”, that is, I can trust what you will do and you can trust what I will do, so that we can reliably and efficiently produce complicated, coordinated shared outcomes.
By far, the most critical activity to create a cooperative social contract is what Toyota calls “catchball”. I also like the “shuttle diplomacy” metaphor used in Product Roadmaps Relaunched.
Catchball is essentially back-and-forth dialogue to ensure we have real, not imagined, understanding and commitment.
If you’re worried more about how OKRs are worded than how OKR dialogue is happening, you’re really missing the point. For Agile people, this dysfunction is equivalent to people worrying about how User Stories are written rather than whether, and how, the conversations are happening.
Problem #3: Not considering multiple horizons
The last issue is Lack of Multi-Horizon Planning. A quarter is typically too short of a horizon for long-term planning and is typically too long of a horizon for medium-term planning.
Google apparently does both annual and quarterly OKRs. I generally prefer 5 levels of planning (vision/strategy, roadmap, delivery plan, weekly plan, daily plan).
I also prefer rolling horizons so 3 month horizons updated every month, 12 month horizons updated every quarter. Batching OKR planning every quarter or year feels to me like a sub-optimal process capability gap to work through.
Not typically a problem: Lack of ambition
I don’t see the encouraging ambition issue that is typically emphasised with OKRs as a major one. Granted, this does depend on the specific context we’re looking at.
