Don’t sleep on OKRs
Looking back, I did myself a huge disservice by writing OKRs off. At that time, OKRs would have helped tremendously to grow my previous company.
Fast-forwarding to years after exiting that business, I started working with a company that had just begun using OKRs. It was a great introduction to what OKRs are and how they can help — but I also got my first taste as to how difficult they can be to implement.
OKR stands for Objectives and Key Results.
The system is relatively simple and straightforward. For each Objective you define, you also want to identify a few key metrics that define how you will measure how much success you’ve had with achieving the objective.
On the company level, you aim for one to five OKRs each year. Then, based on the company OKRs, each team in your organization will plan one to five OKRs each quarter.
Easy right? Well… Maybe not.
As they say, the devil is in the details and OKRs may be the best example of this. After working with companies around the world and helping them implement OKRs, there are a number of extremely common pitfalls that most first-time users of the framework fall into.
Pitfall 1: Unrealistic Optimism (too many objectives)
Have you ever looked at a long to-do list and told yourself you’re going to be able to get it done today (no problem!)? Then, by the end of the day, there’s only one or two things checked off and you wonder what you did all day?
Imagine that, but instead of saying “I can get this done today”, you say “I can get this done this quarter”, then looking back at the end of the quarter wondering why none of it got done.
The same optimism that gives us the power to take chances in our business also gives us the ability to sign ourselves and our teams up for way too much work to get done in a given period of time.
Think about it this way. If you have too many objectives, you’re going to be left with things that didn’t get done. If you have too few objectives, you not only achieved everything you set out to do, but you’re ahead of schedule.
With too many objectives, the worst thing that happens is that everyone becomes unmotivated to keep working on objectives, because “what’s the point!”. With too few objectives, the “worst thing” that happens is that you get to celebrate your accomplishments and get started on the next batch of objectives ahead of schedule!
Pitfall 2: Word Choices (getting stuck for too long on how they are worded)
If you Google enough, you’ll find plenty of definitions for how Objectives should be written and how Key Results should be composed.
Some are excellent and others… not so much. Some things you read will conflict with other information you find. And, if you research enough, you’ll spin yourself in circles on how to write OKRs at all.
I find myself saying this a lot: “do what works.” The idea is that if it works for you, then it’s probably good enough. While it’s critical that the objectives and key results are clear, it’s also equally important to get just them in use and learn from them (see Pitfall 7).
Pitfall 3: Projects not Metrics
Without fail, I can guarantee this will happen when you first start to try to plan with OKRs. You will come up with a great objective and then immediately start listing the projects that need to be completed in order to achieve the objective.
Warning: This is the hardest pitfall to avoid.
We’ve all been trained for working in a Goal-to-Task mentality. It’s easy for us to think about what we want to achieve and then how we’re going to achieve it.
What’s missing is how we measure success. And this success metric element is what makes OKRs so effective.
Contrary to what you may have read on the internet, there are times when you need to use projects as a key result (see Pitfall 8), but they shouldn’t be the default.
Pitfall 4: Not bending the OKR Rules (trying to do it exactly as one person describes)
Similar to Pitfall 2: Word Choices, this pitfall will eat up all your planning time and never let you get off the ground with OKRs.
It’s easy to decide on using OKRs and then finding descriptions of how the framework should be used. But every situation is different and if you don’t allow yourself to bend the rules to your situation, you’re putting yourself in a box with no exit.
All your planning time will be spent trying to cater OKRs to your situation using a set of guidelines that may not apply. An impossible task and it’ll create frustrations and disagreements with everyone involved.
If you don’t do OKRs perfect the first time, don’t stress about it. Stick to the basics. Design minimal objectives that can be measured by key results, plan those annually on the company level (or even bi-annually!), and then do the same on the team level quarterly. It’s far more important to help your teams focus and think critically by understanding where you want them to go, versus struggling to implement OKRs perfectly the first time.
Pitfall 5: Pessimism (not thinking big enough)
There are plenty of stories online about how OKRs have led to great innovation. But, you can only set the stage for this if the objective is big enough to force people to think creatively for how they may achieve this lofty goal.
It’s easy to design objectives that can be hit without issue, and it feels good to see the 100% mark on the key result metrics.
But, is that what you want? Teams that aren’t trying hard to do things better? A company that just hits the status quo? Probably not, or you wouldn’t be reading this.
Missed OKRs are as important as achieved OKRs. In fact, a successful OKR is in the 70% range. If an OKR is missed, the information and data on why it was missed is sometimes more important and helpful than knowing how an OKR was successfully achieved (because that’s usually pretty clear and easy to understand).
Set big goals and support your team in helping them think creatively on how to achieve them!
Pitfall 6: Available Metrics (not being able to track what you need to track)
This pitfall can sometimes relate to Pitfall 1: Unrealistic Optimism. You may find yourself in a situation where you create an objective and some fantastic key results. The problem? You have no way of tracking the key results.
This forces you into a position where you can’t measure success until your build the solution to track the key result metrics. Of course, that takes time away from actually working on the objective. Nine times out of ten, it’s going to lead to a situation where you either don’t get the objective done because you are focused on building a solution to track the metrics, or you simply work on the objective without any way of knowing if it’s successful or not.
This sounds easier than it is, and it’s a big one that causes a lot of headaches in first-time implementations of OKRs.
See Pitfall 8 for one way to handle this.
Pitfall 7: Thinking it’s going to work the first time
We’ve all been there. We try something new for the first time and we tell ourselves that if we just follow the instructions, it’ll work perfectly! Ever tried making pastries or baking? You can follow the recipe perfectly, but that’s just the instructions and not the art. A good pastry chef or baker has followed the same recipe many, many times in order to learn the art that’s needed to do it well.
OKRs require the same patience and dedication.
Let your team know that you’re all learning together and that you’re going to do this multiple times before it’s going to work well. You need to learn what works best within your specific situation and culture. Try it, adjust, try again next quarter. Measure and get feedback, work as a team.
Going back to thinking about the worst that can happen… if you try to get it 100% right the first time, two weeks of planning will quickly turn into two months (or worse!) and you never get OKRs launched. If you aren’t perfect the first time the worst thing that happens is you learn from your mistakes and improve the next time, but OKRs are launched and teams are united in a common and clear vision.
Pitfall 8: Not creating projects when you need them
This pitfall is nearly a culmination of all other pitfalls mentioned. Most articles will tell you that you need key results to be metrics, not projects. However, for first-time implementations and growth-stage startups, it’s quite common that you won’t have the systems in place to get the measurements and metrics.
It creates another impossible task and will dramatically lengthen the planning process because you’re trying to measure something you don’t have the capability to measure. That is, unless you build the tools to measure it. And that’s where it makes sense to allow projects in as key results.
You’ll see examples all over the internet relating to good key results. Things like “increase sales by 40%” or “increase customer satisfaction by 10%” (note: I’m paraphrasing, these could be better key results). But, how do measure an increase in customer satisfaction if you haven’t been measuring customer satisfaction in the first place? You first need to build a way to measure customer satisfaction (project), then get a baseline (also a project), and finally measure the increase (key result metric).