Binary: Good for code, bad for OKRs

Binary: Good for code, bad for OKRs

(Each week, I write a post about OKRs. You can see the series of posts here; if you have a question about OKRs you’d like to see me cover down the road, drop me a line.)

macbook pro beside black speaker
Photo by Ricardo Ortiz on Pexels.com

A founder I’ve known for several years reached out recently. They had just raised a round, they’d onboarded a number of new team members, and he wanted to ensure his growing team was as aligned as possible. Attached to his email was their draft Q1 OKRs; he asked if I had any feedback.

It takes at least two to four quarters for OKRs to really stick in an organization. Like learning any new skill, it takes time to develop the muscle memory. Teams need to see what success looks like, but also to see how the organization responds to failure: when a low score on an OKR isn’t stigmatized or penalized, it reinforces the idea that failure is data, and can contribute to future successes.

Back to the founder: their first quarter’s OKRs were quite good: they had metrics associated with a number of their goals, they didn’t over-commit to too many company-level objectives, and there was clear alignment across teams. For a first effort, it was pretty impressive! But there was one big issue – a common mistake that many teams make early in their implementation of OKRs: a series of binary key results.

What do I mean by binary key results? Things like “launch v1 of [product]”, “develop roadmap for [other product]”, “decide what to do about [issue]” – these are initiatives that have only two possible outcomes: you either did the thing, or you didn’t. When it comes time to score these “OKRs”, you either get a zero or a one.

What if you launched v1 of the product and it sucked? What if you develop a roadmap for some big idea and… nothing happened? The fatal flaw in committing to OKRs like these is that you can get a great score on the OKR when it’s time to grade yourselves, and fail to achieve much (or, worse: actively do damage to your organization).

Baked into many of these binary goals is a hypothesis: if we do this [ship/decide/develop], then this [other good thing] will happen. What you and your team should do is try to articulate what that other good thing is, and build your OKRs around that. When you do that, you’re focusing your team on the outcome you’re trying to provoke, not the tactic that you think might produce that outcome. (You could be right! You might be wrong. Ultimately, it doesn’t matter: it’s the outcome you should care about.)

By avoiding a binary OKR, you’re helping the team appreciate that the point of adopting OKRs is to get better at tying the work they do to the outcomes that matter. And you’ll avoid situations where good grades on the OKRs aren’t well-calibrated to the organization’s performance overall – among other things, good scores that nevertheless produce bad outcomes can teach a team that OKRs don’t work.

3 responses to “Binary: Good for code, bad for OKRs”

  1. I’ve seen many teams being initially uncomfortable with the leap of faith between outcomes and their specific projects. They would prefer to get credit for the project. But at some point they realize: that leaps gives you the freedom to change the project the moment you realize it won’t deliver the necessary value. If done right, OKRs give teams tremendous freedom to define and choose the projects that drive the most value.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.