"OKRs are a waste of time": 10 mistakes you make with Objectives and Key-Results
Objectives and Key Results (OKR) have been around for a while. Many companies implement the goal-setting framework expecting to benefit from the promises of a more empowered workforce and better business agility.
More often than not, nothing really changes beyond introducing additional processes and meetings.
What if OKRs are not the problem, but the way you use them is?
Did I get OKRs wrong this entire time?
Most people using OKRs can't see the actual benefits this framework brings. They view it as just another way to hold teams accountable for unrealistic goals devised from higher up, or as an "agile disguise" for the same old bureaucratic processes.
After working with OKRs as an employee at various companies and implementing them as a consultant, I get why. As with most management tools, OKR is used as a context-free prescription that gets copied as-is from one company to another.
It's not about the details, it's about your approach
Developing products in sprints or holding retrospectives don't make you agile. Similarly, watching sports doesn't make you an athlete.
Implementing OKRs doesn't mean you're using them correctly.
If you opt to use OKR, you better be ready to change how you approach work. This means being wholeheartedly ready to relinquish control, distribute decision-making, and accept that not everything has one root cause.
10 mistakes you are likely doing with OKRs
The following is a list of 10 things you are likely doing wrong about OKRs.
To increase the suspense, I even ordered them from the most obvious to the most surprising one:
You're setting too many Objectives or Key-Results
Even though this is maybe the most well-known OKR guideline, you might still get it wrong. The ideal number of Objectives and Key-Results is typically described as "maximum 5" or "3-5". Even if you know this, there are still 2 things you might be doing wrong.
The first, you're using your entire "allowance" by always having 5. What you should do instead is focus on the things your team should prioritize and can realistically address. Another good practice is to check mid-cycle and remove the OKRs that you won't be able to tackle and label them appropriately.
The second is cramming multiple KRs/measures in one Key-Result. Here's an example: "Acquire 5,000 new users AND generate €100,000 in revenue". In this example, you need to ask yourself would the same action/initiative cause both to improve, and if not which is more important.
Your KRs describe activities
I would go out on a limb and make the following statement - anything that doesn't follow this format is probably not a KR: <direction><measure/KPI><from x to y> (e.g., <increase><ARPU in Europe><from €10 to €15>).
It's probably describing an activity. Activities are not bad, but they are not Key-Results. A Key-Result describes the outcome of the work (how it affects the business or customer), not the work output (the deliverables).
You're doing personal-level OKRs
It sounds great in theory: each individual can see their contribution to their team and the whole organization. In reality, it's too much unnecessary work for the employees and their managers. The value with OKRs is already created before (and without) drafting individual objectives.
Personal OKRs are not only over-engineering it. Choosing to go that route has other implications, such as holding back employees from experimenting, taking risks, and leaving their comfort zone, all while leading to conflicting priorities.
You separate OKRs rituals from your regular steering rituals
"what? We need to add OKR reviews, bi-weekly check-ins, and alignment meetings?".
Nope. You need to use OKRs within your regular exiting rituals.
Let's take a product development team as an example. You have your sprint planning meeting, your retrospectives and reviews/demos, daily scrum/standup, 1:1 meetings, and even the backlog grooming. Any work that's being planned or worked on should ideally connect to the OKRs. You don't add rituals, you adapt the existing ones to incorporate OKRs or relate to the bigger picture.
You don't flash out initiatives while determining your KRs
OK, we’re half way through the list.
OKRs are not meant just for goal-setting. It's a framework that helps a team plan their work and be more effective and efficient. Most teams I've worked with focus their "OKR planning" around the Os and the KRs, but neglect one crucial element: the "how" component of achieving our goals?
Now you don't have to plan all activities up-front at the beginning of the cycle, though you can if you so choose. In any case, KR owners should map out the activities and experiments the team will run toward achieving the results. Otherwise, there's a loose connection between the goal and the daily work team members put in.
In our “OKR Planning Street” workshop template you can find an example of how to map those activities (termed “focal points” in the template) to your KRs.
You're being too efficient in your process
Is being too efficient a bad thing? It very well could be.
The pressure of meeting deadlines for presenting OKRs to the entire company or in manager-forums often result in managers rushing the process to have their goals documented in time.
To me, the biggest benefit the OKR framework brings is that it makes you stop and think about what you're doing. Teams and managers shift from thinking about executing tasks toward discussing their importance, the connection between daily tasks and expected results, and whether the workload makes sense. The quality of work design increases tremendously as it shifts from planning busy work (outputs) to planning value creation (outcomes).
You forget your user/customer
Take a look at your current OKRs - how many are phrased to showcase the value your customer would get? My bet is a big fat zero.
We all like to think we're "agile", though our internal language rarely uses the first principle from the agile manifesto: "Our highest priority is to satisfy the customer". Now, I'm not advocating that we forget about our revenue and investor/management requirements. I'm not that ideologic.
Having said this, let's be frank, the amount of time we speak internally day-in and day-out about the value to the customer is far too short. And no, marketing folks, "customers will know about us" doesn't qualify.
If you want to change how you plan and do work, you need to change your language. Don't replace all internal KPIs with customer value, but absolutely add some to your OKR mix.
You run a 3-month cycle
Isn't this what OKR is about? Wrong again.
Methodologies have building blocks. If you want to make the best use of them, you need to adapt them to fit your specific context. Take the building blocks and recombine them to suit your business setting.
The 3-month cycle is not an OKR building block. The time-boxed period in which work gets planned and evaluated is. Are three months too short for you to see change/improvement? Is your business environment too volatile, making three months into the future impossible to plan for? Change it…
You calculate the percentage of achievement for your KRs
We're closing in on the last two most surprising OKR mistakes you're probably making, so I'm guessing this one was off your radar.
Isn't OKR about stretch goals and reaching 70%?
Relax. You can color-code your OKRs even if you don't score them from 0 to 1 (or 0% to 100%).Precisely grading your OKRs brings forth two main issues. First, it puts pressure on the team that their results are not on par, even though KRs are more like experiments than a deterministic measure of future states. Thinking of KRs, or activities as experiments, makes you evaluate them differently, which brings me to the second issue.
When you run experiments you learn. You want to make sure you have reliable results and that you can plan your next steps. Not achieving a KR doesn't mean you failed. It just means that you disproved your hypothesis. You fail when you don't use that data to inform your next experiment or calibrate your assumption.
What's the alternative? You can use a qualitative scale to track your accomplishment. Here are two examples to get your wheels turning, as I'm sure you can think of a better-fitting scale for your company.
This one revolves around the status of work: Pending, Delayed (or Behind), On-track, Satisfactory achievement, Nailed it, Not achieved. The other has to do with the experiment framing: Prep work, Live/testing, Analysis, Hypothesis confirmed (i.e., result is within x% of the KR), Hypothesis disproved, Inconclusive.
You do team-level OKRs
Isn't the premise of OKR that you set goals at the top, and those cascade down to teams?
Surprisingly, that's not accurate.Let's look at this from another perspective; if you were to align and collaborate with other teams in the organization on your team's OKR, wouldn't you spend hours a day meeting with every other team? I think we can all agree that our calendars are swamped as it is.
OKRs are best suited for cross-functional teams that are structured around value streams. What's that you ask? At its core, a value stream includes everyone that works on delivering the product/service to the customer, from inception to value creation.
If you are a smaller start-up with one core product, all employees most likely work on that one value stream. You might not need more than one set of OKRs for the entire company, as everyone's work is tied directly to them.
At a larger multi-product company, each of these products or lines of products is probably a value stream. Everyone that works on one of these streams should have joint OKRs. You might even need another level of sub-value stream OKR.
Here’s how a value steam-based OKR might look like: marketing, engineering, sales, and customer success should share one set of OKRs rather than each having their own.
That's how alignment and prioritization work.
What can I do to improve my OKRs?
The first and straightforward answer is that you should go through the above list and check where you stand. If something is off, fix it.
A better answer is that you should check if there is one or two things that stick with you, and if so, note them down. Add a few examples that illustrate how this looks in real life in your organization.
Then, bring it up and discuss it with your team, the leadership forum, an agile coach, or your company's OKR champion if you have one. You might be able to correct some of the mistakes within your team. Others will require a wider organizational consideration in the approach to OKRs.
If "OKRs are a waste of time" or something in those lines has been echoing in your (virtual?) hallways, I hope you see what could be some of the underlying reasons for that.
Adopting OKRs is not a magic pill that makes your company more money, but it can absolutely improve the way you work, the quality of conversations you're having about it, and employees' engagement and sense of ownership.
