Introducing OKRs (Objectives and Key Results)

Allan Kelly, @allankellynet, https://www.allankellyassociates.co.uk/

"The main thing to remember is, the main thing is the main thing." General Gary E Huffman

OKRs = Objectives and key results: obvious, perhaps.

OKRs are about goals. Objectives are big goals; key results are smaller goals that build towards the objective. You might think of it as epics and stories, but stories and acceptance criteria might be a better analogy neither is quite right.

The question is, how ambitious do you want to be?

OKRs were created by Andy Grove at Intel before he became CEO. The success of OKRs at Intel mean they spread to other Silicon Valley companies and, around 2000, Google started using them. At first glance they look like a reinvention of the older management by objectives - MBO - techniques but on closer inspection they are different.

It turns out that OKRs are highly compatible with agile working. Both OKRs and agile are outcome focused, both adopt a regular cadence cycle and both allow for failure. Although it is easy to see OKRs being used as a top-down command-and-control mechanism it makes more sense in an agile setting to use them as a bottom-up tool for team-enablement.

Engineers may think of OKRs as an abstraction of the desired outcome to be delivered by the end of the quarter. That outcome is described in terms that speak to the customer and the benefit to be delivered. The engineering and implementation details are hidden behind the abstract interface.

As with software design there are different ways of approaching the same thing: each has its own benefits and trade-offs. There may not be an obvious answer, but it is critical that everyone shares the same abstraction.

I sometimes think of OKRs as 'Test-Driven Management'. Decide what you want (the objective), next set a series of acceptance criteria: key results. Now get on and develop. Don't consider yourself done until you can pass the tests and meet the objectives.

When the acceptance tests are known, engineers have a wide degree of latitude in deciding how to meet their criteria. In doing so they will use their professional judgement and experience. They will also be constrained by the time and resources available: the existing products and technology will further bound a solution.

Why?

OKRs focus on outcomes, deliverables, things which are delivered and generate benefits. OKRs give teams goals. Those goals serve both to focus a team on the work to be done and communicate with others - stakeholders and superiors.

Unlike MBOs - the earlier technique which OKRs grew out of - OKRs need not be set top-down - at least not in an agile environment. Rather, in an agile setting OKRs would be set by the team. Managers, and other stakeholders, certainly influence what OKRs get set but agreeing OKRs to target is a team activity - for it is the team which must deliver on those goals.

Product Owners, BAs and Product Managers who are tasked with understanding users, customers and markets and will take a lead in setting OKRs because they know best where the team can add value.

Equally, in an agile setting senior leaders should not expect to set OKRs - especially not OKRs which cascade down the organisation. Instead such leaders should specify overarching goals, set a mission or paint a picture of the desired future. Leaders may outline a strategy for pursuing that goal but, within that context it is up to each agile team to decide how it can best contribute to that mission.

Thus OKRs act to communicate goals throughout the organisation. In accepting the goals set by each team leaders approve and license the team to pursue their own goal thus increasing alignment.

Setting and reviewing OKRs serves both to reflect on and consider strategy, and then to turn strategy into action. Closing and resetting OKRs on a three-month cycle allows time to deliver and for regular reflection and strategy consideration.

Dissecting OKRs

An objective is something you and your team wish to achieve. That objective is a goal to be achieved, something to aim for. It might be a mission in itself, or it might be part of a larger mission or some other 'higher purpose'. (See my earlier book Continuous Digital (2018) for a fuller discussion) The mission might be your product, a business initiative or some endeavor to help a client. Whatever it is, today's objective requires some significant work.

Key results are the important things that build towards that objective. Milestones, if you like, but I like to think they are more than just milestones. When I think of milestones I think of markers along a route. Such milestones don't have value in and of themselves; unless a milestone represents some tangible outcome, reaching it delivers little more than the right to say "We've reached the milestone".

Good OKRs are outcome-focused. OKRs are not about measuring progress towards a goal. Nor are they about ticking off work items on a manifest. OKRs are about delivering outcomes that add value. That's one reason why they are a good fit with agile.

Each objective will have several key results. Each result should be useful in and of itself. Achieving a key result should deliver some benefit - some value - to someone.

An objective should have its own wholeness that is more than the sum of its parts - the key results. Achieving the key results builds towards the objective, but the whole thing, the whole objective, should create more value than simply the value of the key results added together.

While the mission is largely immutable, OKRs get reviewed at the end of each quarter and new ones created for the next quarter. Some may need to flow over from one quarter to another, but each OKR-setting session should start with a blank sheet. If something is worth continuing into the next quarter it's because there is more value to be gained, not because something wasn't finished or sunk costs incurred.

Teams pursue several objectives over the course of a quarter, and each objective has several key results - hence objectives (plural) and key results (plural), although for a really focused team it could be one objective (singular) and key results (plural).

OKRs and agile

Those schooled in agile may say "Oh, an objective is an epic, and the key results are stories", but OKRs are more than that. OKRs are not a mini-backlog, rather they are a machine for generating stories. OKRs are more akin to sprint goals; indeed each key result may be a sprint goal itself.

So throw away your epics - they aren't a perfect fit for objectives and they don't add much anyway. The objective fills the same role as an epic: the big thing to aim at.

Then, rather than seeing key results as stories, see them as targets. Ask yourself: what do we need to do to move towards that target? And ask again, and again. Every time you need to decide the next thing to work on, go back to the OKRs and ask the question afresh.

I'd go as far as to throw away any backlog and drive all work from the OKR story machine.

While a quarterly cycle is standard, you might choose to work on some other cycle duration. It's up to you, but working in quarters has a good rhythm.

Some see the quarterly OKR review and setting as a giant sprint. While there are similarities in the routine, the logic is different. Sprint planning is very focused on immediate action and delivering in the next few days. OKR-setting should be more thoughtful and customer (demand) focused.

Think broadly, execute narrowly

OKRs need to be measurable. While this is good because it sharpens one's thinking and enforces honesty, it is also bad because hard numbers can get in the way of big thinking. Targets can blind one to unintended consequences and side effects incurred in meeting the target; the numbers used in targets have a nasty habit of changing in unpredictable ways.

The laser-like focus of delivering OKRs needs moderating with expansive and considered thinking during OKR-setting. Teams should alternate between reflection and broad thinking during OKR review and setting and really focused actions during delivery. The former should last hours, the latter months.

When it comes time to set OKRs again the results of the previous OKRs will inform thinking, so too should thoughts on the OKR process. Were the OKRs too vague? Too strict? Too detailed? Did enough, or too many, conversations happen beforehand?

The most perfect execution in the world is nothing if it aims for the wrong target. Equally, the most perfectly defined target is worthless if setting it uses all the time and strips away risk and motivation.

Despite the hard thinking that goes into OKR-setting, the real success of OKRs is not whether any particular objective or key result has been achieved. OKRs are transient objects that serve to focus thinking and work. The real benefit is in the outcomes delivered.

The ultimate objective of any OKR is to produce an outcome that creates value and benefit to customers, users and other stakeholders.

So, think broadly for a short window of time to set OKRs; then work narrowly for a far longer period to deliver OKRs.

Default to staying focused on OKRs during delivery, but be prepared to fight fires if need be. There is no point in delivering against targets if the world has burned down. If all you ever do is fight fires, then you will only ever be a firefighter.

Ambition over estimation

Unlike burn-down charts, velocity and story points, OKRs are not for estimation or forecasting. I'd advise against estimating any objective or key result, but rather to challenge yourself. The aim of OKRs is not to do everything, rather the aim is to be ambitious, to be prepared to push further. For that reason, OKRs shouldn't be used to benchmark teams or individuals.

Teams are not normally expected to complete 100% of their OKRs - 70% is more common. Hitting 100% is easy if the team sets easy goals. With OKRs teams are encouraged to aim high - not impossibly high, but high enough to be challenged. If teams are meeting 100% then maybe they are not aiming high enough?

Each of us want to do well and achieve 100%, in many places anything less than 100% looks like failure. Therefore it is important that leaders at all levels provide an environment in which it is safe to fail - that is, provide psychological safety.

Benchmarking OKRs against other teams, attaching money to OKRs, attaching blame for missed OKRs, linking performance reviews or promotion to OKRs will all destroy that safety.

When using a burn-down chart the implicit goal is to reach zero. In the traditional project model the aim is to do everything asked for, even if that needs more time. With OKRs, in contrast, achieving 100% of the targets is failure: achieving every key result and every objective suggests the team was not ambitious enough.

The thinking behind OKRs is that a team that aims high and only achieves three-quarters of their target will still deliver more benefit than a team that aims comfortably low and achieves everything. Therefore it is wrong to judge teams and individuals on how many OKRs they achieve.

Instead, when it comes to assessing performance, look at the outcome, look at the value delivered, and how things are different compared to three months ago. Ask yourself: How is the product, the company, the world, a better place for what the team has done?

For that reason, OKRs are not going to sit comfortably with those who want certainty. Nor are OKRs going to sit well with those who want to tell others what to do. OKRs are set by the same people who are going to deliver them. OKRs are not about top-down control, they are about bottom-up engagement.

Those at the top can set the final destination, give some directions and paint a picture of the promised land, but it is those who are making the journey that get to decide on the means of transport and the route. OKRs are a permission giver, not a control rod.

Outcomes

OKRs aim to achieve some objective - the 'O'. That objective should be an outcome - something that has been changed, something that has been achieved, something that makes the world or at least one person happier.

Outcomes should be things in their own right and not proxies for something else. For example, counting work 'done' on a tracking chart - be it a project plan or burn-down - is a proxy measurement for the work itself. However, outcomes can be subjective: one person's outcome is another person's milestone.

Outcomes are often wrapped inside other outcomes. The thing you define as an outcome of your work might be little more than a milestone or proxy measurement along the route to an outcome I am aiming for.

Not all outcomes are equal, some have more validity than others. The term 'vanity metrics' describes quantified measurements that don't actually represent a beneficial outcome.

When defining objectives, always strive for outcomes rather than proxies. Be prepared to challenge yourself and let others challenge you. Know the people your outcome will benefit: preferably be able to name them. Seek to remove any intermediaries between your outcome and actual end customers receiving benefit.

It might be impossible to define perfect customer-enhancing outcomes; some element of proxy might remain. Just be prepared to challenge easy answers and go as far as you can.

Remember that money itself is a feedback mechanism: when customers part with cold hard cash in return for your outcome it is a form of feedback. A customer paying $100 for your product indicates that the customer is prepared to give up the other things that $100 could have provided.

Business benefit and value

Outcomes should benefit customers, the wider business and even society itself. Although it is easy to talk about businesses as monolithic blobs, all organizational entities are collections of people. Ultimately benefits flow to individual people.

Maybe an outcome makes someone's job easier, more productive, more satisfying or just more fun to do. Sometimes the benefits accrue to managers who are responsible for a process, product or group of employees.

An outcome may create benefits for an external customer: maybe the outcome is a better product, a cheaper product, a more widely available product or one of many other benefits.

In addition to internal users and external customers, there are plenty of other stakeholders: shareholders, regulators, customers-of-customers, special interest groups (think Greenpeace or the WWF), the families of employees and more.

In general, the words 'value' and 'benefit' are synonymous. Value has the advantage that it is slightly shorter, but the disadvantage that people tend to associate 'value' with a number. Benefit fits more easily when talking about non-financial value.

Value

Value may come in different forms. Money is a perhaps the most obvious form of value, but it is not the only one.

Learning is valuable, for example gaining knowledge of new technologies or learning better ways to create the product. Learning also happens as you understand your customers more, how they use the product and the problems they face.

Feedback is valuable, as it feeds learning and helps extend our existing knowledge. Perhaps the most valuable form of feedback is that which doesn't fit our existing models and understanding. Such feedback often looks like failure but can be the most valuable, because it forces us to relearn.

Feedback is valuable in itself and helps create value. Perhaps feedback allows for price increases or cost reductions.

Risk reduction is valuable: there is always some uncertainty attached to an outcome, so reducing risk increases the likelihood of achieving the outcome and the value.

Risk reduction is valuable, but risk reduction costs. Economists like to say that 'profit is the reward for risk'. The cost of removing all risk may be negation of all benefit. For example, delaying the start of work by one month may reduce risk, so is valuable, but a later start means a later end which, thanks to cost-of-delay, may mean that the value lost is greater than the value gained.

Money: while not the only form of value, do not overlook simple money. In a modern free-market economy incoming revenue is not only necessary to pay our salaries: income also tells us what other people (our customers) value. I like to joke that "Money is the best form of feedback".

Similarly, money saved (costs reduced) tells us that there is a more efficient way to do the same thing. Saving money in one place frees money for use elsewhere, which allows businesses to adapt and change.

Even when outcomes deliver money, subjectivity is still at work. Accounting techniques (such as exceptional items and capital expenditure) provide for a lot of judgement calls. To complicate things further, the 'financial engineering' performed by corporate financiers and bankers can produce a reality distortion field.

Ultimately value is recognized by people. As a general rule the more people who value an outcome, the more valuable it is.

Conclusion

For an agile team OKRs hold the potential to increase autonomy, sharpen focus, bring value to the fore and prioritise beneficial outcomes over simply delivering backlog. This requires a whole team approach: the team set and deliver the OKRs as one combined unit.

This is a edited except from Allan Kelly's latest book, Succeeding with OKRs in Agile, available now. © Allan Kelly, 2021

Related people articles

Measuring And Increasing Team Alignment

Goals on Every Level - Enabling Your Team to Become More Productive

Fear of Intervention - How Subordinates Grow to be Entrepreneurs

---

Click here to view the complete list of Methods & Tools articles

This article was published in March 2021