Good vs. Bad OKR Examples

What is a bad OKR?

When I stumble across bad OKRs, their usual traits are:

1. Key results are only focused on outputs and not outcomes

2. Key results are based on a binary result and not something than can show progress over time

3. Each objective contains multiple key results that influence each other

What is a good OKR?

You might say they’re the inverse of the list of a bad OKR, but traits of good OKRs are:

1. They’re focused on reaching a specific, measurable outcome

2. They paint the finish line but not how to get there

3. They contain just enough specificity in the key results to provide a frame for the team to work within

If you want to know more about the ingredients for a good OKR, check our post about the OKR checklist for additional pointers and tips.

Good vs. Bad OKR Example: Too Focused On Outputs

This OKR is a great example of a company that is only focusing on outputs. Often those outputs should be initiatives to reach the key results. Here’s an example:

See the difference? If the goal is to grow the amount of traffic to the blog, then that should be the key result. Writing 10 blog posts could then be one of many initiatives that the team wants to do in order to achieve that key result.

As they publish the posts, they can start tracking how much they’ve grown the blog traffic and report back to their manager on that progress.

Good vs. Bad OKR Example: Binary Key Result

This example is one that I see often. It’s mostly used in engineering teams where people are building things where they’re too detached from why they’re actually building them.

Instead of focusing on the binary output (either launching the feature or not), the company should focus on increasing the metric related to why they wanted to build the feature in the first place.

This empowers the team to brainstorm several possible solutions to reach that metric. Some that management might have never thought of.

Good vs. Bad OKR Example: Key Results Influence Eachother

Another common mistake I see with OKRs is that they’re containing too many key results. This often causes them to influence each other, meaning that if a team shows progress on one, they’re automatically also showing progress on the other.

In this example, you could easily argue that if a team increases the avg. likes per post, they’re also going to affect the performance of those posts.

Instead, the team should try and combine these into one, which could easily be done by focusing on their common metric: engagement rate.

Conclusion

I hope this gave you an idea of what OKRs should not contain as well as how to turn them into something that’s actually measurable. Plus, if you’re a manager of team, it should also encourage you to let your team figure out how to get to the finish line, instead of you telling them. 

Let your team come to you for advice if they need it. And make sure to track progress on a fixed cadence.