OKRs: The remedy to fixed date, fixed scope projects
OKRs change the language of goal-setting to elevate value delivery and reduce focus on arbitrary dates.
After hearing about OKRs for years I finally got around to reading John Doerr’s Measure What Matters, i.e., the OKR book. I had helped teams organize around OKRs before, and also worked with individuals to set their own OKRs as part of career development, so my goal in reading was to understand what makes for good OKRs, how to go about creating them collaboratively, and how to track them.
What I learned was different than what I was expecting. The book does gives examples of companies like Intel, Google and Intuit using OKRs successfully, but the realization I came away with was this: OKRs can help ease the fixed-scope, fixed-date project mindset. Here’s how.
Even in organizations where scope and date is being hurled onto teams there will always be a business goal (often not communicated). The assumption leadership makes is that completing the scope by the date will achieve some business outcome. However, these outcomes are obfuscated by the focus on scope and dates. As assumptions about what value a particular scope item are proven false, the focus on scope remains intact because the layers through which scope changes have to permeate are thick with politics and fear of optics.
OKRs relieve the focus from scope to business outcomes. This modified “football example” illustrates how at each level of the organization the language is specific to outcomes, not scope outputs.
Though OKRs can be time-bound, the shift of language from outputs to outcomes has a significant impact on how organization levels negotiate between themselves and what they negotiate, with respect to dates.
Instead of saying we want the Twilio integration done for account verification by December 1, we instead say, we want 5,000 verified users by December 1. The difference in language here matters because of three reasons.
First, users could be verified without using Twilio and the first version prevents even a discussion of this possibility. In order to scale effectively we need teams to figure out the how of delivering and phrasing things in terms of scope takes away that autonomy, while letting them figure out how to get 5,000 verified users increases it. You may get away with managing by scope with a couple teams, but scaling increases the error rate in an organization as an increase in the number of teams increases the probability that teams are working on the wrong things. Autonomy is a mitigant against that as long as as there is alignment.
Second, having a customer metric aligns the whole team on a business goal rather than an arbitrary yes/no on whether Twilio integration is done. Using outcome-focused language helps the team live in the business domain rather than the scope domain. It gives a purpose to the work rooted in customer centricity rather than in a technology deliverable. Doing so connects the team to the higher level objective directly rather than through the opaque intermediary of a scope item.
Third, we open the door to have a discussion of what a reasonable number of users to verify is, and stay truer to the agile value of customer collaboration over contract negotiation. Product Managers may have a different view on what the threshold for verified users should be compared to executives who came up with the goal, and an outcome-focused OKR opens up the dialogue in the negotiation of what’s truly necessary to target.
OKRs shift the language while providing a framework for increased autonomy and alignment. They are an enabler of the top-right quadrant in Henrik Kniberg’s aligned autonomy model:
Essentially, leaders focus on what problem to solve and teams are left to figure out how to go about solving them. This lends itself neatly to OKRs because lower level goals are derived from higher level goals. The impact of changing objectives at any level are more easily translatable throughout the organization because of shared language and goals.
So how does this help alleviate date-driven management? Three main ways:
Having customer value as a starting and central point of focus instead of a byproduct of date-driven technology deliverables.
Propagating the discussion around value delivery up and down the organization, making it easier to negotiate the impacts of change between levels.
Instead of a static date which deems whether an objective is met, creating a gradient of value delivery where tradeoffs can be made.