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.