One of my executive coaching clients asked for some guidance recently to keep her company’s OKR (Objectives and Key Results) initiative from going stale. Our work together had started with an OKR engagement and grew from there.
Back when we started together, I foreshadowed that it normally takes a company two to three years to dial in the way OKRs are going to work for them.
Her company, now in its second year, is dealing with the challenges that come along with these types of strategic initiatives. (The OKR methodology is in the family of strategy execution methodologies, including Traction, 4DX, and so on, which all have similar implementation patterns.)
At its simplest, the OKR framework has a team specify what Objectives they’re going after (typically, thematic or qualitative) and Key Results that “cash out” those Objectives (typically, measurable or quantitative)
For instance, for PF, it might look like this:
Objective: Launch and get traction with the Momentum app
- Get 10,000 customers within the first year of launch
- Achieve a 33% active customer referral rate
- Get cost-per-acquisition to $20 or less
Simply put, if we achieved those three Key Results, we’d know we had achieved that Objective.
What often happens during an OKR initiative is that teams will start to replace real Key Results with projects. Something like “Launch a website” slides in as a Key Result, and once that one’s in, more projects start creeping in.
If I had my say, we wouldn’t call the methodology OKR — we’d call it OKP for “Objectives, Key Results, and Projects” so that we more clearly differentiate between key results and the projects that achieve those key results. As I’ve said, well, everywhere, finishing the right projects is how we push our goals forward. Alas, in this instance, I’m not the super-famous person with the famous company who got to name the framework, so people come to me asking about OKRs.
Why does it matter that a team conflates key results and projects? Three visible patterns emerge:
- Teams tend to put bigger projects on the board because they’re primed by the time horizon of the objective. If the time horizon of the objective is one year, teams choose year-sized projects.
- Teams often lose sight of how those projects are actually pushing the objective forward. In the example for PF, “launching a website” may make no significant difference whatsoever if the website’s not doing real work for us. It could simply be another of the gazillions of websites that actually work against us or something we put up and don’t use. In our case, the point of a website would be to drive customer acquisition; it’s a project that drives that key result.
- Teams get litigious about projects. This is a consequence of 1 and 2. If we only get a few big projects, we have to choose well. If we’re not clear on how the projects will drive our objective forward, we tend to champion projects we want to do for other reasons or that keep us safe.
Switching to OKPs can help avoid a lot of those traps while encouraging teams to adopt a more generative cadence for choosing projects. It also avoids over-adjusting projects masquerading as key results.
For instance, if your Objective and Key Results are on a one-year horizon, it’s easier for teams to keep those fixed to the year (as they ideally would be) but still pick month-sized projects that help them learn what best creates those key results. During their monthly OKP refresh, it’s “Where are we related to those Objectives and Key Results + how are our projects getting us there?” vs. the more time-consuming “Should we choose different Key Results?”
I’ll leave you with a sportsball analogy: Objectives tell you what game you’re playing, Key Results tell you what counts as points, and Projects are the plays you run to get those points.
Projects/plays are the most dynamic part of the process, which is why I knew to have this conversation with my client who was wondering how to keep OKRs from going stale. In a future essay, I’ll point to another common culprit of OKR hurdles.