Book: Succeeding with OKRs in Agile (2nd Edition)
Author: Allan Kelly
Part: II — Writing OKRs
Chapter: 7 — Objectives
Reading time: 12 minutes
Tags: writing-objectives objective-design outcome-framing value-articulation wide-objectives feature-factory-avoidance team-capability-okrs testing-objectives objective-inspiration okr-structure
Summary: Kelly explains how to write effective objectives that describe desired outcomes rather than work to be done. Objectives should inspire, articulate clear value, and avoid quantification (numbers belong in key results). The chapter warns against ‘feature factory’ objectives that simply list deliverables, and recommends each team reserve one OKR per cycle for improving future capability.
Objectives within objectives – like Russian Matryoska dolls
In the process of decision those alternatives are chosen which are considered to be appropriate means of reaching desired ends. Ends themselves, however, are often merely instrumental to more final objectives. We are thus led to the conception of a series, or hierarchy, of ends.
Herbert A Simon, Administrative Behavior, 1947
So the first thing to decide is: what is the objective? or, to put it another way, what is the outcome you are seeking?
Key results help to define and build towards that objective, so the first thing to write is the objective. The objective needs to be something the organization wants, something the organization values, something that contributes towards the bigger goals and visions that leaders have outlined.
The objective is the thing you are trying to achieve, perhaps the thing you are trying to build or create, or perhaps a change you are seeking to make. Your objective may be only a part
of someone else’s grand plan, a building block on the way to another objective: that in turn might be a small part of something bigger.
The objective does not so much describe the problem you are trying to solve. Rather, the objective is the state in which the solution has been build and the problem has been resolved.
Although I write ‘problem’, I could just as easily write ‘opportunity’. It may not seem it at the time, but problems can be opportunities in disguise. In which case, the objective is the state in which the opportunity has been seized.
The objective doesn’t need to explain the problem in detail, or how you know it is a problem. Rather, it is the objective that is the resolution of the problem or realization of the opportunity.
Objectives should inspire, so don’t let details get in the way. This also means objectives are often free of quantification. The place for numbers is in the key results. At the risk of abusing the English language, one might say “Objectives are subjective, key results are objective”.
7.1 Background analysis
You may want to do some analysis to make sure you are addressing the right problem with your objective. You might even want to share your analysis and reasoning with others. However, the OKR itself is not the place to do this. The objective should be short and sweet.
If you need to explain your choice of analysis and reasoning then do so: sometimes explaining oneself can provide new insights – but don’t include that explanation in the OKRs. Park the rationale, the explanation, elsewhere. Your objective can always be accompanied by a footnote that tells the reader where to find out why that objective was chosen.
In my experience, as long as the objective has value and someone can verbally explain why the objective was chosen, then little or no supporting collateral is needed.
7.2 Objective value
It goes without saying that the objective should be meaningful and deliver some benefit to the organization. If the objective does not deliver business benefit of some form, why pursue it?
‘Business benefit’ is a bit of a mouthful – seven vowels – so it is easier to talk about value – does the objective have value?
That’s fine, except that to many ears ‘value’ implies a number, and a number implies a financial quantity, maybe $100,000 or €1,000,000. In a commercial enterprise it is wonderful when an objective results in hard cash, but not all objectives deliver money, and money is not the only measure of value.
A previous chapter discussed value, so just note that valuable outcomes can include:
- Learning: by the team (“We learnt Scala this quarter”) or by the business (“We learned that our customers prefer green”).
- Risk reduction: for the piece of work the team is focused on or for the wider organization.
- Strategy advancement: executing on strategy goals may mean incurring costs and risks today that will not pay back for a long time.
- Furthering the aims of stakeholders and society at large.
Money, such as new revenue or cost savings, can also be an outcome. Remember that despite what is often claimed, few people are really motivated by money.
Note too that I’m avoiding the term ‘profit’. That’s for two reasons. Firstly, profit is constructed by accountants. There are so many rules regarding what is profit and what is not that it becomes a subjective thing. Private equity companies in particular have a habit of loading companies with debt that wipes out any profit but in doing so reduces tax. The net effect is that the private equity company makes a bigger return.
The second reason for avoiding profit is that stating an objective as ‘Make more profit’ is so general as to be meaningless. Such an objective doesn’t really say much about what the objective actually is.
7.3 Obvious value
When crafting an objective, make the value the objective brings blindingly obvious. That the usefulness of the objective is obvious to you, and even to your team, does not mean that it is obvious to others. Don’t worry about ‘dumbing down’ – wait until people tell you that you are stating the obvious before you start making assumptions.
In particular, it may not be obvious to your senior managers. So…
Retool the delivery pipeline to facilitate continuous delivery.
Might be better phrased as:
Accelerate time to market by retooling the delivery pipeline to adopt continuous delivery approaches.
Which could be still better stated as:
Increase return on investment by reducing time to market with a new delivery pipeline and continuous delivery practices.
Hopefully you can see a way to spell out the value even more clearly.
The old user story technique of appending a ‘so that’ to the end of an objective can help here:
Reduce the time it takes to complete regression testing.
Becomes:
Reduce the time it takes to complete regression testing so that time to market is reduced and the cost of testing is reduced.
Although the problem with ‘so that’ is that it comes at the end. Therefore bring the benefit to the front:
Reduce time to market and testing effort by reducing time spent in regression testing.
These become like Matryoska dolls: you can continue refining and improving objectives almost infinitely. However there comes a point of diminishing returns, where an extra 20 minutes spent on the next improvement won’t make much difference. Far better to take a break, come back a day or two later and look at them with fresh eyes.
Better still, try them out one someone else.
7.4 Wide objectives
The objective part of an OKR is the place to ‘go wide’. What you want is a beneficial outcome. You want to avoid boxing yourself into a specific approach or solution – you might do that in the key results – but leave yourself space in the objective. That space allows the team to make tradeoffs so as to find a solution within the constraints of technology and time. When the objective is so specific that it allows for only one solution, tradeoffs are not possible and options are closed. Consequently the team is disempowered and the chances of achieving the objectives diminished.
What you want is an outcome statement that has clear business value but which is wide enough for the delivery team to be able to find different ways of realizing that objective. For example:
Show competitive advantage in data processing by ingesting priority data sources faster than competitor XYZ.
Faced with this objective, the delivery team may start by profiling the application and finding where it spends its time, then methodically working through each to increase speed. While rational, this approach might itself be time-consuming.
Alternatively, the team might use its existing knowledge and make an educated guess as to which part of the application requires attention. This might be a database change, or it might be application logic rework.
Another approach might be to improve the data connection between the application server and the main data sources. This might even mean physically moving resources from one data centre to another. In the extreme it might mean paying extra to locate machines next to one another.
Given three ways of meeting their goal, the team might decide to pursue all three in parallel – a set-based engineering approach¹. The team might pursue all three options to their conclusion, or reduce the number when one option shows that it can deliver the expected result.
It can be helpful to ask the team how might we approach this? when setting the objective. In answering the question don’t try to find one complete answer, seek to find several probably feasible options.
¹Morgan and Liker, The Toyota Product Development System, 2006
Sometimes something that looks narrowing may actually widen the options. Look at the word ‘priority’ in the previous example. Including that word in the objective may look as if the objective is narrowed, but it actually allows more scope for creative approaches.
In this case the team has the scope to focus just on the priority sources. General changes are not required. The team could reprogram the application to simply prioritize a limited number of data sources – the priority ones.
Writing objectives that allow for different approaches lets the team doing the work decide the best way to deliver an outcome within the constraints they face on the day.
Tom Gilb tells a story of an attempt by the US Army to rewrite their logistics system in the 1990s. This multi-year effort was cut short when the army realized the real need was not for everyone to have a faster system, but for generals to have a faster system. Changing the existing logistics system to prioritize by the rank of the person making the request meant colonels and generals could have instant answers while nobody else noticed any difference.
7.5 Feature factories
You don’t want objectives to specify a single feature, and you certainly don’t want your list of objectives to read like a list of features you must build during the next period. And you really don’t want a list of objective that just says ‘Do A, B, C… Z’.
If you are regularly expected to just deliver one pre-specified feature after another, perhaps that is the way the world is for you, but maybe it also means OKRs aren’t for you. While I wouldn’t want to work in such a place, I know they exist and that some people think they are a good idea.
In such ‘feature factories’ the people doing the work have very little autonomy over what they do. Implicit to the OKR model – and explicit in agile – is that the people doing the work have a say in the work to be done. The workers get a say in objectives, and have latitude in how they meet those objectives and key results.
OKRs are not a good match for a feature factory. If you are running a feature factory, don’t bother with OKRs and don’t claim to be agile. Just hand out the work and tell people to stop complaining. I wouldn’t recommend this approach: I think software teams work better when they are engaged, but it is your choice.
If you are running a feature factory then by all means set out a list of features to be done in priority order and tick them off as they are completed. Dressing the process up as OKRs may win some brownie points, but it will also take more of your time. Be honest: you want features, so measure features in, features out. Don’t waste your time dressing this up as OKRs just because OKRs are fashionable.
However, even in a more enlightened environment where people are engaged in the work and have a say in what is done, there are times when there is just ‘stuff to be done’. So you might set an objective such as:
Do eight high-value backlog items
Although that reads more like a key result for a objective, so maybe the objective is:
Deliver high value/priority backlog items
Even that could be better:
Deliver priority backlog items for key customer accounts into production
Such objectives may be difficult to test – does one backlog item count as success? – but it does allow the team latitude over what they actually do.
It may not be beautiful, but it is possible. However, if you find yourself setting such objectives on a regular basis then consider it a red flag: something is wrong. Either your process needs to change or your attitude to the team does.
7.6 One for the team
In setting objectives and key results a balance needs to be struck between productive work – customer-facing objectives that directly deliver value – and work that increases the productive capacity of the team. The aim of this work is to build in future capacity. Such work might be technical in nature (for example, refactor database connectivity) or team-focused (for example undertake some team training), or something completely different.
The business value here is not immediate but is potentially greater. Capacity is being directed away from immediate value towards increasing capacity in the longer term. While I hope
your superiors recognize and respect this, I know that all too often managers and even developers choose ‘jam today’ over ‘more jam tomorrow’.
I encourage teams to adopt a hard and fast rule: one objective per quarter nominated by the team that will increase future productive capacity.
Without a formal rule, teams should be encouraged to suggest such objectives. Sometimes they will be included and sometimes not. But teams should also strive to improve their productive capacity in all the work they do.
Robert C Martin has likened this the boy scouts’ rule:
‘Leave every campsite slightly tidier than you found it.’
Specifically with code this becomes:
‘Leave every source code file slightly better than you found it.’
7.7 Testing trouble
The objective might be more than the sum of the key results, so it needs to be testable in its own right. You need to be able to determine whether the desired outcome is met or not.
Herein lies a problem: time.
There are some objectives that take time to demonstrate. For example:
Increase customer website visits by 10% over the next month.
It is entirely possible to achieve all the key result and do everything you think you need to do in order to increase website visits, but until a month has passed it is hard to know. While one could reduce the timescale (a week rather than a month), that might not provide a representative sample.
Alternatively, an OKR could be provisionally marked as ‘achieved’ because some key results were achieved and people believed others will be in time, but final judgement could be reserved for a later date. That could work, but then what happens if, when the day of judgement comes, the objective is not met? One might reopen the OKR and do more work, which could put the next set of OKRs in jeopardy.
Or maybe the objective is just not met. The team tried, they did some good stuff, but the objective was not met. It might be that a new OKR will be needed in the next quarter to reach the goal. Such an OKR would need to fight for prioritization against all the new candidates.
Ultimately it might not matter: things have moved on. The gains the team did make were an achievement themselves, whether they met the goal or not. Meeting yesterday’s goal might not be that important any more.
In fact these problem are even more difficult than they seem. History shows that it can be very difficult to really measure the impact of technology change. The 1970s and 1980s saw large investment in corporate IT systems, but this was not visible in productivity statistics – indeed productivity growth seemed to slow during this period. Economist Robert Solow posed what became known as the productivity paradox:
'You can see the computer age everywhere but in the productivity statistics’².
Eventually productivity did pick up and the IT investments did deliver. In part this was due to the fact that investments took years or decades to deliver, but in part it was because economists were measuring the wrong thing. As much as we like to think $10,000 of IT improvements directly creates more than $10,000 of benefit, the actual benefit might not be quite as expected.
Finally, in part the productivity paradox was caused by the fact that process changes and management thinking did not change as fast as the technology. As every business analyst knows, getting the full value of technology improvements often requires process changes as well.
These same issues are at play when measuring objectives and key results: delayed effects, missing expected and unexpected benefits, and changes beyond the technology. So while one should strive for testable and tested objectives, one also has to recognize their limitations.
7.8 Take time but not too much time
When writing objectives, indeed OKRs generally, there can be a temptation to seek perfection. Indeed, when you look back at OKRs from the past, you can always see possible improvements. By all means aim high with both target and expression of OKRs, but don’t let the perfect be the enemy of the good.
²Robert Solow, We’d better watch out, New York Times Book Review, July 12, 1987
By all means spend time crafting your objective and key result; don’t rush the process. But also accept that your OKR could always be phrased better. Don’t procrastinate when setting OKRs, a good enough OKR today is more valuable than an almost perfect OKR next week.
7.9 Summary
- Objectives describe the outcome you want to bring about.
- Objectives should inspire and don’t necessarily need numbers.
- Make benefits blindingly clear and keep any background analysis and research out of the way.
- Team members to nominate one OKR each cycle to improve future capability.