Perhaps the hardest thing to grasp about OKRs is the concept of key results. This is because the obvious way to see them – and in a way I’ve been guilty of myself on occasions – is as small pieces of the objectives. It is too easy to see the key results as lego bricks which when put together form the objective.
If you are lucky, like building a complex lego model, the whole is greater than the sum of the parts. Unfortunately, the reverse can also happen: the whole is less than the sum of the parts.
Perhaps agile folk are even more susceptible to this mistake than most. Superficially it is too easy to map Objectives and Key Results to Epics and Stories.
While it sometimes happens that key results are smaller pieces of work that can be broken off from the objective that should not be the intention when setting OKRs. Simply seeing key results as smaller objectives is the wrong way of looking at them.
The relationship between objectives and key results is not a question of mereology. It is far more enlightening to see the key results as the attributes of the solution which need to be satisfied.
Or, to map them into the agile world in another way: key results are the acceptance criteria against which you can measure your solution to see if it meets the objective. Key results describe the criteria that must be met to satisfy the objectives.
Imagine you are building an online store. The objective is; A functioning online store offering a range of products that can be purchased and shipped directly to buyers.
The lego brick approach would have key results such as a database containing a catalogue of items for sale, shopping basket, checkout, return and refund. In other words: in functional decomposition, each lego brick could be handed over to a separate team to create.
Conversely, setting key results as acceptance criteria would have the capacity to list 1,000 items of stock with sub-second access times, a payment system accepting major credit and debit cards, and an intuitive administration interface.
The first starts to read like a good old-fashioned requirements document while the second approach is closer to the vertical slices of functionality espoused by agile development.
As I write those words I can hear someone saying: “But what if the team forget about the need to offer refunds?” Well, there are, at least, three answers to that question.
First, OKRs shouldn’t be concerned with details.
OKRs should deal with significant chunks of work. If you must capture details then write an old-fashioned requirements document or stuff those stories into your backlog.
The second answer is: to trust the team.
The team have an objective, the team is staffed with experts, and at least one of those experts is responsible for understanding customer needs and ensuring the team is building what is needed. If the aim is to build a “functioning online store” then it is reasonable to assume that returns is part of that offering.
Even if the product owner type person misses such capabilities one can expect professional testers to pick up the omission. And then there are all the other people on the team and regular customer demos. Someone is bound to notice.
If nothing else team members should be asking their customers: “how do you want to deal with customer returns?” A customer-focused team shouldn’t need every detail included in high-level OKRs.
Thirdly, so what?
What if the team do fail to deliver a return system? Of course, this might undermine the whole offering but not necessarily.
The team might feel it is better to get a lesser product into the market and get customer feedback before investing in building a returns system.
Or the team might undertake the analysis of returns and decide the minimal approach to returns is financially justifiable. Returns might be processed by phone initially. Or, like several companies I’ve “returned” products to in recent years, the client might simply ship replacement units and ask customers to dispose of the original product themselves.
Looked at this way key results start to look a lot more like the non-functional requirements of old. They are not necessarily the things a solution must do to satisfy an objective but the performance constraints. As Tom Gilb pointed out:
"From the point of view of understanding 'competitiveness', ... the performance requirements are by far the most interesting requirements."
When key results are written as lego bricks then the solution and design are decided when setting the OKR. And because these are set the delivery team are constrained to produce that design thereby robbing them of autonomy and depriving the organization of their insights.
Setting key results as acceptance criteria give the team the power to agree on their own design and define what needs doing. This enhances the autonomy of the team and makes the most of their brainpower.
Simultaneously, deferring the design decision until after the objective has been set allows for focusing on the desired outcome rather than the technology or mechanics of construction. And delaying those decisions not only allows more time to learn about what is required but avoids the need for a lengthy design discussion before agreeing on the OKR.
Moving away from lego brick key results exposes the idea that OKRs can be cascaded down an organization. There are those who advocate a cascading approach where “one team’s key result is another team’s objective.” The first team set OKRs and then hand off the key result to other teams for delivery.
Such an approach works with lego bring key results but once you view key results as acceptance criteria that model falls apart.
Consider the key result to have “sub-second access times”. How is one to hand that off to another team? To start with there is nothing to do, is the “sub-second” team to wait until another team has built the store and then set to work optimising the code?
Handing teams targets without their involvement do not create motivation. When a team is handed an objective on the plate they are disempowered. Their understanding of the problem, the solution needed, and their creativity is not valued. Treating a team as a feature factory is not going to make for motivated workers.
Writing key results as success criteria allow teams to find their own way of meeting the objective, it hands the team control and responsibility, it minimises dependencies and maximises commitment.
Now, at the risk of contradicting myself, it is worth pointing out that while one may avoid functional decomposition of key results and focus on success criteria there can be opportunities to turn acceptance criteria into discrete pieces of work.
Take for example the key result: “capacity to list 1,000 items of stock”. This could be broken into two parts. The first would mock out the stock items or just return one item. Part 2 would be a separate piece of work to build a system that handles 999 more items for real. However substitutability is not perfect, one cannot undertake part 2 until part 1 is in place, which also means that if part 1 is missed part 2 will also fall.
So, when it comes to key results think of acceptance criteria. Ask yourself: “How will we know, we have achieved the objective?” Think about tests rather than components. Once you do this you might start to see why I sometimes like to think of OKRs as Test First Management.
DOWNLOAD FREE GUIDE TO STRATEGY DELIVERY USING OKRs
Learn how to write and manage OKRs. Discover how to combine Strategic Themes, OKRs, KPIs and Strategic Initiatives to achieve high levels of performance across teams.
