If you’ve read anything on this blog in the past 3+ years or our latest book, Who does what by how much? A practical guide to customer-centric OKRs, you know that I am a big supporter of setting goals with human-centric objectives and key results. I’ve spent tens of thousands of words not to mention hours of my time promoting, teaching and helping others implement goals this way. And yet, like any framework, OKRs are not a silver bullet. When applied as one without careful consideration to the unique needs of every aspect of your organization, you may find yourself in a situation where OKRs aren’t an asset at all, but rather a burden for your teams to create and implement. I want to share three examples where OKRs have hidden costs and end up being more of a burden than an organizational improvement. 

Not everything requires an OKR

It’s tempting to give the entire organization the same method for setting goals. It simplifies and standardizes processes, workflows and decision-making. It would make sense for an organization that is new to OKRs to apply this approach across the board. There are at least two situations where this may end up becoming more of a burden than a benefit. The first is business-as-usual (BAU) functions of your company. BAU functions can include things like operations work that keeps your technical infrastructure up and running at high performance, security and scalability levels. It could also include your call center teams or even your sales teams. These teams already have proven methods to measure their work. Whether it’s technical measures like server uptime or MTTR (mean time to recovery) or call resolution speed and rates or sales funnel conversion metrics, BAU teams know how to keep tabs on their performance. Forcing them to take on a new goal-setting framework just because the rest of the organization is doing it may prove to be a distraction from doing their work properly rather than improving performance. 

A second part of the organization where OKRs may not make sense is low-risk work (or, conversely, high-certainty work if you’re an optimist). There will always be situations where the answer is unclear or needs to be explored, discovered and refined. OKRs are excellent goals in these situations. However, when a team knows exactly what they need to build, how to build it and how it will be used, OKRs become a distraction. I once worked briefly with a team at a newspaper. They had to add a meta-tagging component to their publishing workflow system. It was broadly agreed in the organization that this capability was missing and necessary. The system the meta-tagging would plug into was mature and familiar to the entire editorial team. There was broad agreement on where it fit in that workflow and what components it needed to contain. There was very little risk implementing this feature. In this case, OKRs would have been overkill. The team wasn’t trying to discover how to optimize the publishing workflow for this newspaper. They’d already done that work. It was simply an issue of implementation. Here, again, OKRs would have ended up being a burden. 

Rolling out OKRs org-wide without a clear ‘why’

Every time your company changes its ways of working a collective grumble is heard across the org. Why? Because in the majority of cases your teams don’t know why the change was implemented. They’ll go through the motions required of them but in many cases this is just another box to tick as they go through their daily activities. OKRs can fall into this same trap. If a top-down announcement suddenly imposes a new goal-setting framework on the staff without a clear explanation why the change is happening, you can be assured of an uphill battle to get broad support and usage of OKRs. Often these top-down mandates come with yet another tool the teams have to use. OKRs become a task to be completed rather than a strategic exercise to focus and prioritize work. 

If teams can clearly see the benefit of using a new way of working they’re far more likely to adopt it willingly. This improves the efficiency and effectiveness of the roll-out process. When teams see the new approach as one more thing they have to do before they can get to work, goal-setting becomes a robotic task to be completed without any of the expected improvements in productivity and focus. The costs here can be measured both in terms of money as well as in morale. Adoption takes far longer and the return on that investment even longer. In the meantime, staff members bristle at yet, “another bit of process we have to follow before getting to the actual work.”  

Teams don’t know what to do once OKRs are set

This is an issue we’ve covered multiple times here (and in the book) but it’s worth bringing it up in this context. It’s one thing to change the goals a team uses to measure progress and success. However, if we don’t equip them with the tools they need to achieve those goals, all that effort will have been in vain. OKRs become a burden in this situation as well because teams will have gone through the goal-setting process only to find themselves unsure of how to actually achieve these goals. Inevitably they’ll default to what they do know how to do effectively neutering the OKR effort. Successful OKR implementations don’t stop at writing goals. In fact, that’s where they start. 

New ways of working should be assets, not burdens

As you head into your OKR implementation work consider the situations mentioned above. Think about them critically and decide how you’re going to handle them. OKRs should be an asset to every organization. The return on investment for using them should be evident shortly after their implementation. However, if we blindly apply the change in broad strokes without considering these situations we end up with, at best, mixed results or, at works, a failed OKR implementation and a perception of OKRs as a burden to be ignored or avoided rather than a valuable way to keep the customer front-and-center in your work.