Systems Thinking is about seeing the whole of how something works. It's about understanding not just how the parts act, but how they interact - their relationships, connections, and dependencies. Because like it or not, the way we behave is constrained by what's considered acceptable behaviour in our environment. It's far harder to go against the environment than it is to conform to it, which means that our environment constrains our individuality. And the implications of that are that the system, rather than the individual, has the biggest influence on an individual's behaviour. We're all free to make choices inside the systems we're in, but we're highly unlikely to make decisions that the system doesn't make easy or possible. It's this understanding of systems that always made me wary of OKRs.
OKRs (Objectives and Key Results) have rubbed me the wrong way for a long time. I never quite put my finger on it, so I asked my network what they thought, and why. What I got back was enlightening. (You can read all the gory details here).
While I got a lot of really interesting answers, it was John Willis's response that really got me thinking
"[Deming] argued that a focus solely on outcomes, as is common with OKRs, could lead to detrimental practices such as gaming the system, especially when outcomes are directly tied to personal incentives like bonuses."
It pointed me in the right direction and made me suspicious, because a similar argument could be made about MBO (Management By Objective), a once-popular, but now largely abandoned management methodology.
Were MBO and OKRs connected? Did they share the same set of assumptions and beliefs? Were the problems with MBO the same as problems with OKRs? Down the rabbit-hole I went.
My suspicions were validated when I started to investigate how OKRs came to be.
"In 1975, John Doerr, at the time a salesperson working for Intel, attended a course within Intel taught by Grove where he was introduced to the theory of OKRs, then called "iMBOs" ("Intel Management by Objectives")." https://en.wikipedia.org/wiki/Objectives_and_key_results
It turns out that the origins of OKRs are, in fact, Management By Objectives. For those that don't know, Management By Objective is a practice whereby the organisational leaders set out goals, and then manage the company so as to achieve those goals.
"In the MBO paradigm, managers determine the enterprise's mission and strategic goals. The goals set by top-level managers are based on an analysis of what can and should be accomplished by the organization within a specific period of time. The functions of these managers can be centralized by appointing a project manager who can monitor and control the activities of the various departments.[9] If this cannot be done or is not desirable, each manager's contributions to the organizational goal should be clearly spelled out." https://en.wikipedia.org/wiki/Management_by_objectives
The similarities between MBO and OKRs are striking.
OK, but why is MBO bad practice? Doesn't it get you to the goal?
Often, it will. But while the goal may be achieved, the side effects of achieving it, and the method by which it's achieved, may not be what the company needs. Take, for example, a classic sales case.
MBO: Increase sales by 50%.
Expected behaviour:
More work being put into sales
Finding more qualified leads
Selling more of our products
Increased profit
Alternative behaviour that fulfils objective:
Sell things we don't make
Discount products to meet sales figures
Make promises the company can't keep
Sell to anybody, even if they're a bad fit for our product, leading to ruined reputation
The objective doesn't stop any of the negative behaviour from happening. In fact, it incentivises it.
What's more, when sales starts selling things the company doesn't make, it puts pressure on other teams to stop focusing on what they need to be doing, in order to meet this new demand. Regardless of the value of their other work, the pressure exists and will build. And if the product builders (eg software, manufacturing, etc) have different objectives, or different plans for meeting the same objective, they're now in conflict.
Because MBO is only concerned with results, it reduces humanity to an optional extra. It doesn't matter why somebody succeeded or failed, they're rewarded only on whether they did it. Becoming a parent, moving house, getting depressed, or the death of a parent are all irrelevant when all you do is manage by numbers.
Ultimately, MBO introduces more problems than it solves. But it's often attractive because it's easy.
According to Radical Focus, by Christina Wodtke in 2016, OKRs should exist at the team level and the organisational level.
OKRs cascade. There should be a company-wide OKR and then each team should set their OKR to feed into the global one.
Even individuals should set their own OKRs. An engineer might decide their objective is to get great at python. She can then set KRs around that goal.
I can think of no better way to introduce conflict into an organisation than to have different objectives at different levels and different objectives at the same level. Having different objectives at every level is a recipe for more internal conflict than most organisations or people can handle.
Not long after the book came out, Rick Klau suggested dropping individual OKRs entirely
"in November 2017, Klau clarified via twitter: “6- Skip individual OKRs altogether. Especially for younger, smaller companies. They’re redundant. Focus on company- and team-level OKRs." https://en.wikipedia.org/wiki/Objectives_and_key_results
So the worst conflict - individual - is gone, but inter-team and multi-level conflict is still practically inevitable.
Now we need a method of conflict resolution, in addition to our OKRs, to resolve conflicts that only exist because of OKRs. The more we investigate, the less simple and lightweight OKRs become.
As the pace of change increases, our ability to adapt needs to increase, as well. When we see a system as a whole, if the inputs change, we can adjust the system to either maintain or change outputs, as needed.
What about OKRs? How flexible are they?
Do not change your OKRs halfway through. Suck it up and either fail or nail them.
If circumstances change, or your initial assumptions were wrong, stay the course! Don't learn early! Don't adjust or adapt!
When we make mistakes, or learn we're wrong, we should be able to adapt quickly. Measurements that are inflexible make us inflexible, increasing risk to the business.
I don't have a lot to say about this.
OKRs really got their heyday at Google. They were introduced in 1999, and lots of their subsequent popularity is a result of Google's adoption and evangelising. And for a long while, it looked like they worked. Google could do little wrong. But internal product failure after internal product failure indicates that something isn't quite right. And by now, everybody is familiar with the enshittification of Google Search. In the constant pursuit of more revenue (almost certainly an OKR measure), Google has worsened its product, consistently, until it's something that almost everybody talks about. Lots of people will have nailed their OKRs on the path to Google's current product. Why didn't they stop making it worse? Because their OKRs said they were doing the right things.
What's interesting here is that Google may be making a fundamental attribution error. They claim OKRs helped drive their success. But there's no second Google that didn't adopt OKRs and failed, so causality is hard to prove. As Deming said about American manufacturing in the 1900s, there's a good chance that Google is succeeding in spite of OKRs, not because of them. But let's take what they've said at face value - OKRs helped drive Google's success.
If Google is the poster child for why you should adopt OKRs, it's also the poster child for why you shouldn't.
Let's say we accept everything above, and still want to make OKRs work. What would we do?
The first thing is that we would stop using team-level OKRs, in order to reduce conflict. So now we just have them defined at a single level - the executive. Everybody else's role is to figure out how they can help contribute. Lots of individuals won't be contributing to the OKRs. They're going to be responsible for keeping things running smoothly, which enables others to pursue the OKRs. That means that performance can't be universally measured with respect to how it has contributed to the success or failure of OKRs. Even at a team level, that will be true. So if you do team performance measurement, or individual performance measurement, there's a new potential conflict, not between different OKRs, but between those that have them and those that don't, but are necessary for the business to succeed.
Next, we would need to make OKRs flexible; if the environment changes, we should change. So OKRs are no longer set in stone. Again, that means we don't want to tie performance measures to OKRs. If OKRs change, can you genuinely reward performance against something that's no longer relevant or important?
Third, we have another conflict to prevent. Having multiple objectives encourage people to focus on the one they think is most relevant to them. And that's fine, as long as everybody is associated with no more than one objective. As soon as a team is associated with 2 objectives, whether directly or because they provide necessary support to teams with different objectives, there will be conflict, because there's no guarantee that requests are compatible with both objectives. Requests will come in at the same time that contribute to different objectives. And the team does not have the power to resolve those conflicts. The executive will either need to prioritise the objectives, so people always know what's most important, or they will need to resolve every conflict originating at different places in the organisation.
Even easier than having completely isolated teams, or clear priorities among objectives, is to have a single objective. Pick a single thing to work towards as a company, and everybody focus on it. No more objectives, only Objective and Key Results. In the end, all OKRs end up boiled down to a single goal of the system, and the things necessary to get there.
Honestly, you'd be better off with either a strategy (because a strategy makes the 'how' clear) or a goal tree (because it captures everything necessary for success).
OKRs are the child of a management methodology that dehumanises us and creates conflict. And it hasn't gotten far enough away from its roots to escape them entirely. Fundamental to OKRs is measurement. Contrary to the implications in Measure What Matters, not everything that matters can be measured. It's just as important (sometimes more important) to manage the immeasurable, which requires a thorough understanding of the system. An understanding that runs counter to the cascading nature of OKRs, and their piecemeal approach to management.
It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth.”
– W. Edwards Deming, The New Economics. https://deming.org/myth-if-you-cant-measure-it-you-cant-manage-it/
Rather than spend a lot of time on a practice that doesn't provide much value, you're better off spending your time identifying a strategy or creating a goal tree. Either one would be more productive than management without humanity.