Are OKRs management malpractice?
This blog post seeks to answer the following questions
What are Objectives and Key Results (OKRs)?
Do tiered OKRs increase conflict?
Do OKRs reduce flexibility?
Do individual-level OKRs cause conflict?
How could OKRs damage an organisation?
Why this subject?
I was reading my friend Noah’s blog and thought I’d provide an alternative view. I’ve got OKRs working well in several places, and I didn’t agree with many of the points raised. Please take a look if you want to understand Noah’s view first.
https://noahcantor.com/blog/b/okrs-are-management-malpractice
Please note that this reply is simplified, as the subjects covered are very large, so I’ve sought to cover only the key points. Without this approach, I’d have to write a book!
What are Objectives and Key Results (OKRs)?
OKRs have two parts:
The Objective - Provide a simple, concise description of the strategy
The Key Results - Measure the current baseline and set a target to aim for by a certain point in time. You may or may not commit to achieving the target
OKRs use the following format:
Objective - A single sentence summarising the strategy
Key Result(s) - From [baseline metric] to [target metric] by [date] stretch / committed
Do OKRs reduce flexibility?
A few quotes from Noah’s post to start this section off starting with a quote from a Radical Focus article:
Do not change your OKRs halfway through. Suck it up and either fail or nail them. - Radical Focus Summary
Here’s Noah’s response… “If circumstances change, or your initial assumptions were wrong, stay the course! Don't learn early! Don't adjust or adapt!”
So I think this is tricky as I have issues with the way the Radical Focus Summary is worded here. The description can easily cause confusion.
Your Key Results are measures of success and can indicate if a strategy is working (your objective). If they are way off target it means your strategy isn’t working. If you change the strategy halfway through, you are talking about 2 options: pivot or stop.
1) Pivot means to shift the strategy but not radically change it. For example, you may keep your strategy but target a slightly different customer group.
2) Stop is obvious; your strategy isn’t working, so you should do something different.
Let’s say you are trying to drive sales with a new advertising campaign and found it wasn’t working. When you learn this isn’t working to such an extent that you need to stop, then, of course, you shouldn’t “suck it up”. When you need to pivot, it may mean your solution needs some changes, and you may keep the same objective if it makes sense. In this case, you could carry on.
So, what is missing from the Radical Focus Summary is the concept of a strategy sitting behind the OKRs. It is this that you looking at. If the strategy is so bad you stop it, you do “fail" the OKR. If the strategy can be pivoted, continue and aim to “nail” the OKR. So, in fact, this is the opposite of “don’t learn early” or “Don’t adjust or adapt”.
In summary, OKRs don’t reduce flexibility, they allow you to make good strategic decisions based on data.
Do tiered OKRs increase conflict?
Noah’s insight below suggests that OKRs will cause conflict based on them being deployed at the organisational and team level as suggested by Christiana Wolke in her book Radical Focus:
“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.”
I don’t see a major issue here with this setup, as it is pretty simple to tier OKRs this way and ensure they complement each other. However, I don’t recommend using OKRs like this. Here is my preferred method:
I recommend introducing a Strategy layer. This could be a strategy for multiple teams such as improving the efficiency of a sign up process. Now the organisation may have an overall strategy but my preference is to have this as a mission statement that each Strategy can align to. The strategy layer here may have one or many teams underneath it.
This is how I structure OKRs in my CAF framework. As Strategic Area results can take a long time to come back, we can use Minimum Viable Increment OKRs to show if we’re going in the right direction. These are under the control of the people who own the Strategic Area, and you get no conflict.
Do individual-level OKRs cause conflict?
Although I’m not a major proponent of OKRs at the individual level I can see a few issues you’d have to be careful with. The OKRs for the individual would be the same as any personal objective; they must support organisational success. Even without OKRs, within most appraisals, we find goal setting. An appraisal system will usually identify weaknesses, create focused interventions and track if we are improving. For OKRs we would be making the objective clearer and have a good method for measuring success. The problem with OKRs at the individual level is the amount of effort to baseline the metrics. This can be hard and put people off. Outside of OKRs, most teams will be asked to create SMART objectives. However, I’ve rarely seen the measurable aspects implemented well.
So, do they cause conflict? Well, if you set any objective that takes away from your strategy, then yes, they will. For example, I want to learn a new programming language, and this impacts the delivery. There is always a balance here, it is ultimately up to the manager to decide if the personal objectives provide value. Some of this value may not be immediate, and there is a trade-off. However, having personal goals should be seen as a good thing, it can help us improve and contribute more.
What do personal OKRs look like? Well, I would strongly recommend that they aren’t a subset of the overall strategy; this will get really messy. For example, trying to say, “I’ll create 4 screens with <10 bugs found in 1 month”, to support a strategy is just overcomplicating things.
In summary, it is up to you if you use personal OKRs or not; you just need to make sure they are helping.
How could OKRs damage an organisation?
OKRs done badly can cause damage:
With a badly behaved dog you should start with the owner!
If you set a bad strategy (represented by the cake in this picture below) it doesn’t matter what OKRs you create. Therefore it’d be easy to blame OKRs. Aspects like a bloated product or one that tries to make money at the expense of customer satisfaction are not issues with OKRs.
If you set multiple OKRs that conflict with each other you will cause damage.
If you set multiple OKRs for the same people and don’t manage prioritisation you will cause damage.
A final few points
So just to pick up a few conclusion points from Noah’s post and wrap this up!
Let’s start with this one:
”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.”
The problem with this is the OKR becomes very abstract for everyone. In other words, without a strategy layer and work item OKRs, you can’t easily see if what you are doing is making a positive difference. Let’s say we want to increase customer satisfaction. How do I know that my change is making a difference? It may be doing the opposite! Perhaps I’ve simplified a screen but don’t realise that my customer base now finds is less flexible. Being able to baseline this and measure it gives me confidence my change is working. This is why I operate with tiered OKRs in CAF.
“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.”
Yes, this is absolutely right, a team should have one strategy to work on.
Here are a few reasons why I like OKRs: they help you avoid the following:
Ineffective strategy that is run for far too long and causes very high costs
Strategy that does damage and the product team doesn’t realise it. How often do you see a company producing software that gradually destroys them?
Strategy based on a hunch rather than any sort of data
Well, this turned into a long post! Thanks to Noah for his thoughts on this subject.
Why not consider training if you want to deep-dive into this subject. Perhaps you are already convinced and would like a full rollout.
I welcome your comments….