Make lemonade from OKR lemons
Nobody likes them, but everybody is doing them
Most large organizations use OKRs (Objectives and Key Results) as their primary method for planning work and directing the business. This is how it all works, at least in theory.
An Objective represents the goal the organization aims to achieve. It typically originates from leadership and, ideally, is measurable. Examples of Objectives include “achieve a 10% market share for Product X” or “reach three-nines availability for System Y.” However, the measurability aspect is often omitted, leaving the Objective more high-level and directional (for example, “increase market share for Product X” or “improve availability for System Y.”) Objectives are usually aligned with core company priorities. Otherwise, they won’t be approved by leadership, and you'll likely face pushback.
Each Objective is paired with Key Results (KRs), which are metrics and outcomes designed to support the Objective. KRs should be measurable, especially when the Objective is high-level or qualitative. They are often expressed in terms like “Metric X moves from A to B.”
Very few companies manage to define KRs in a truly quantitative way. For one, it requires consistent and trustworthy metric definitions and measurement practices, already a significant challenge for most organizations. Douglas W. Hubbard’s excellent book on measurement highlights that while anything can be measured, doing so requires effort and is not a free lunch.
Organizations must first recognize the importance of measuring specific business aspects, but that’s only the beginning. Metrics need owners who are accountable for driving them in the right direction. The metric owner must define a realistic delta between the current value and the desired value in the KR. This requires a deep understanding of the business’s operations and its responses to input variations, often using methodologies like Statistical Process Control (an excellent resource for this topic is Commoncog). Only a few organizations are equipped to operate at this level. Amazon is the prime example (pun intended), where executives review over 400 metrics in their Weekly Business Review.
Another critical aspect of OKRs is synchronization: the entire company needs to dance at the same rhythm (or at least closely collaborating teams). For example, if an engineering team is building a product for a revenue team and the engineering organization operates using OKRs, the revenue team need to be aware of how the OKR process works, in order to give requirements at the right time.
You might have noticed that neither Objectives nor Key Results specify what to build. They focus on the why and the how, but not the what. However, engineering teams often think in terms of shipping features, building products, and addressing technical debt … essentially, what to build. This is where friction between top-down and bottom-up approaches becomes evident.
There is considerable debate about top-down (Taylor) versus bottom-up (Deming) approaches to persuade a team to pursue a certain objective and hold them accountable. In practice, the Taylor approach has often prevailed in how OKRs are implemented, even though OKRs were originally considered a Deming-inspired concept (see this post for more on this topic).
Implementing OKRs correctly is incredibly challenging. So why do we continue to use them? Because OKRs remain the best framework we have. OKRs provide teams with purpose, establish accountability, and serve as a valuable tool for performance evaluations, even if their real-world application often diverges from theory. At the end of the day, they’re better than nothing.
If your Objective isn’t measurable, don’t worry. Think of it as a keyword reminding the team of the company priority they’re addressing. Core company priorities, set by the CEO or a VP, are generally well understood and don’t require excessive justification.
If your business struggles to define measurable KRs (as it’s not Amazon), start with the tangible deliverables the engineering team will ship, then reverse-engineer a measurable outcome. These will often be "0 to 1" or "all or nothing" KRs, such as “the monetization dashboard is delivered to the product team” or “the data model to track the conversion funnel is available in the data warehouse.” And that’s perfectly fine.
Do you like this post? Of course you do. Share it on Twitter/X, LinkedIn and HackerNews