I almost despair when I hear people advocate cascading OKRs: the idea that someone, some team, some central planning department, can set OKRs which then flow down the organization with each “lower” group implementing some small part of some “higher” ask. What could be more waterfall like?
I admit, when I started working with OKRs I kind-of-expected to be shown the OKRs of the “above” before my team wrote theirs. But when I thought about it, and the more I thought about it, the more I realised if you did do it that way then it is decided unAgile. How can a team be really autonomous, self-organising and self-managing if they have goals handed down to them?
There was a point when I was wracked with self-doubt: am I interpretting OKRs differently to the rest of the world? How do I reconcile agile and cascading OKRs? What am I missing? – but, when you look around, I am not the only one. In fact, if you read, watch and listen to OKR commentators the majority agree with me: the teams delivering OKRs need the latitude to set their own OKRs.
Reconciling OKRs with agile is far from the biggest problem. In fact there are, at least, two bigger problems, one concerns team motivation. Can a team ever be motivated to do something they have no say in? Perhaps some can, I can’t and I know others who don’t. At the very least team members need to be asked.
Motivation becomes especially problematic if you want OKRs to be stretching. If you set someone a stretching goal and ask them to hit it without involving them then don’t be surprised if they shrug their shoulders.
Still, we haven’t got to the biggest problem.
The biggest problem with OKRs is not the metaphysical issues of motivation and whether one is truly agile or not. The biggest difficulty is simply: cascading OKRs are not practical.
First think about the timetable.
If every team is waiting for the team above them to issue OKRs before they set their own then you have a delay built into the system. And the more levels of hierarchy you have the greater the delay is going to be.
For example, suppose you have an executive team, and middle management team and several delivery teams. Then each cycle the exec team need to set some OKRs, once they have set their the middle management can set theirs, and then the delivery teams can set theirs. At each cascade point there needs to be communication, and each point creates the possibility of misunderstanding and mistakes.
Setting OKRs isn’t instantaneous, I think you need about a week to have a think, reflect overnight, iterate once or twice but, if you are well practices, and don’t hit any delays, you might do it in two days. Either way it is going to take at least a week, and possibly three, to get all three layers set. And if anyone runs late then it has a knock on effect.
I’ve heard it said that the Key Results of higher levels become the objectives of the next layer down. The key results of this layer the become the objectives of the one below them. But that assume that the OKRs themselves are a series of “items to do” and that each objective is made up of several pieces which are themselves things to do.
Sure, it sometimes happens that way. I may even have been guilty of interpreting them that way sometimes. But these days I see Key Results not as small pieces of work which, lego style, build into a bigger objective but as Acceptance Criteria: the parameters which the outcome needs to satisfy.
Now to some degree acceptance criteria can be translated into work items to do, and vice versa, but not always. Consider this:
Objective: Improve overnight batch processing to save 10% of work processing costs
Key result #1: Shorten batch processing time by 1 hour so staff do not need to wait for run to complete in the morning
Key result #2: Reduce false positive alerts by 100 per day so that staff waste less time
Now these key results could be packaged as individual work to do but perhaps they are the same piece or work. Perhaps a database upgrade could address both issues in one go. Which path you take is a design decision.
Seeing key results as acceptance criteria changes them from work to do into bounding conditions.
In Succeeding with OKRs in Agile I advise against having domino key results: don’t set key results so that failing to hit one makes others impossible to hit. So, for example, if the DB upgrade had been added to that previous example as key result #1 then the team would have been committed to doing it. And if the upgrade had failed then the other key results would have been lost. Leaving it out gives the team the decision on how to proceed: the people doing the work decide the best way of meeting the objective.
That advice is given within teams but it also applies between teams. If, the Middle Management team require three lesser teams to deliver work to build their own objective then, if any one team fail the middle management team will not only miss one key result but will therefore miss their objective.
Done like this the OKRs become fragile and a dependency nightmare. That will have two effects, first more time will be needed when setting OKRs to identify and mitigate the dependencies, then more time will be needed to manage the dependencies. Progress will only occur at the speed of the slowest.
Second, these problems will encourage people to play it safe and not set stretching and ambitious OKRs. Predictability and safety will be prioritised.
Now if we take the alternative approach and each team sets its OKRs independently then the time lag is removed, teams set OKRs in parallel and if someone is late it doesn’t matter. Dependencies may still exist but they have not been baked into the OKRs so teams can put effort into removing dependencies (reducing coupling and increasing cohesion) rather than putting that energy into managing the dependencies.
So, while we might argue about whether OKRs should, or should not, cascade down; and while we might argue about the psychological effects of being given an OKR by another, simply remember: cascading OKRs mean setting OKRs is going to be more complicated and take longer.