Every company I work with these days claims to be using or trying to use Objectives and Key Results. Conceived at Intel and popularised by John Doerr and more recently by Christina Wodtke’s fantastic book Radical Focus, OKR’s claim to be the solution to the “feature factory” mentality that plagues most organisations as they attempt to “do Agile.” As most companies have “hired” Agile (to use the Jobs To Be Done parlance of our time) to improve their efficiency and time to market they’ve lost focus on the actual value of Agile — agility. Agility is the ability (sorry for the rhyme there) to change direction with relatively little impact based on newly discovered information — which happens ALL the time in software development.
Enter OKR’s. Made up of two seemingly simple components they are intended to state a qualitative goal for a team (the Objective), business unit or company that is aspirational and time bound and then to provide quantitative measures (the Key Results) to assess whether or not you have actually achieved this qualitative goal. However, as is often the case simple does not mean easy.
OKR’s are the tactical implementation of managing to outcomes. We’ve talked about outcomes here many times, but the tl;dr here is that outcomes are measures of customer behaviour that, when used as a definition of success (or “done”) provide teams the opportunity to discover which features (output) make the most sense to build and how best to implement these features. If done correctly, OKR’s shift a team’s purpose from delivering a specific product (the “feature factory” model) to delivering a certain level of success determined by customer behaviour (aka agility). This measure of success is clearly tied to a strategic, qualitative goal for the company.
However, most companies suck at OKR’s and end up abandoning them. Here are two reasons why:
They are written poorly
Despite reading the books, understanding the purpose of OKR’s and implementing them broadly most organisations STILL get the KR part of the equation wrong. Instead of making it a quantifiable measure of customer behaviour, organisations inevitably end up making the deployment of a product or service their KR. Yes, you could argue with me that this is indeed “quantifiable” in that it’s binary — you shipped the feature or you didn’t — however this is NOT a measure of customer behaviour. The only thing you’ve measured is your ability to get code to customer. And, as I’ve been saying for years, more code does not equal more value.
They fail to scale (so many rhymes in this post!)
Even if they write them correctly, many organisations struggle to get OKR’s to tie into each other. This is critical if they are to make sense strategically throughout the organisation. The company-level OKR’s drive the business unit-level OKR’s. Those, in turn, drive the more tactical team-level OKR’s both in the product teams as well as in other, non-tech disciplines like HR and Marketing. To get this right, however, a company must analyse many of the leading indicators of it’s overall business health, determine which ones are a priority for the next year and use these as the KR’s for each level and unit of the company.
To get answers to solving these OKR challenges I reached out to OKR consultant, Felipe Castro. I asked Felipe how he gets the teams he works with to write good OKR’s. Here’s what he said:
“OKR’s help teams keep score. They create a scoreboard, a unified definition of success that everyone can see and understand. I always ask teams the same question: If you deliver all your stories and epics, but nothing improves, are you still successful?
OKR’s are about outcomes. Scrum and Kanban are about getting things done. Both are important.
To get good OKR’s, companies need to invest in metric literacy. Teams have to understand the customers and the business and how their work contributes to it.”
I then asked him why OKR’s fail to scale and what can be done about that. Felipe said that,
“People talk about goal setting as if setting was all we need to succeed with goals. But of course, that is not enough. That is why I created the OKR Cycle, a method to avoid the most common OKR mistakes. The cycle is simple. Just three steps, repeated every quarter: Set, Align, and Achieve.
At scale, the Align step is crucial. We have to ensure cross-team alignment, and we need a distributed approach that enables teams to solve interdependencies. Getting everybody in the same room does not scale, especially for global organisations.”
Both Felipe and I believe that OKR’s can indeed be a crucial tool for scaling agility and increasing an organisation’s ability to learn, sense and respond as it builds products and services. However, if not implemented correctly they’ll be seen as yet another failed buzzword that didn’t move the company forward.
[Jeff]
Upcoming Events
See all of my amazing events in 2019