What is an OKR? A basic guide.

Objectives and Key Results – OKRs. Ask around, and you’ll hear a level of adoption across industries and domains similar to the big wave of Agile adoption in the late 00’s into the 10’s. For a 40-year-old goal-setting framework, OKRs are having quite an impact on the business world. There are increasingly more books on the topic, software to support OKR rollout and a rising number of consultants specialising strictly in their deployment across companies large and small.

Fundamental to the success of OKR adoption is an actual understanding of what an Objective and Key Result is, why it’s different than traditional goal setting and what impact a good OKR will have on your team and, at scale, on your organization. I thought I’d spend this month’s newsletter sharing a clear, simple primer on what a good OKR looks like and identify common pitfalls I’ve seen in my work that lead to poor OKR writing – which effectively neuters their efficacy.

(Caveat: Everything (good) I’ve learned about OKR’s I learned by reading Sonja Mewes & Natlija Hellesoe’s OKRs At the Center and Christina Wodtke’s Radical Focus. Yes, there are other books on the topic and some are even good, but these two books distil complicated ideas into digestible pieces and serve them up in an engaging narrative.)

Objectives

What is it: Objectives are the actual goals your team is setting for itself or for the organization (if you’re in a leadership position). The job of the objective is to inspire the team and give a clear answer to the question, “Why?” Why are are doing this work? What do we hope to achieve?

A good objective is qualitative and focuses on the change the team wants to see if it is successful. That change could be a team-level change. It could focus on something the business is aspiring to achieve or it could even be a change in the world. In most cases, objectives are aspirational and push the team to stretch further than they may have without the explicit objective.

Finally, an objective is timeboxed. We want to set a deadline for when we believe we will achieve it. The further up in the organization you are, the longer the time horizon is on these timeboxes.

What a good one looks like: The specificity of each objective will vary based on which team is writing it. An executive team will write a company-wide objective that could look like this:

Become the single source of truth for COVID-19 information, facts and updates for the world’s media outlets by the end of 2020.

This is an organization-level goal and inspires the team to aspire to become the go-to company for this type of information complete with an explicit deadline.

A departmental objective looks like this:

Ensure the accuracy, usability and value of the data we serve to humans and machines alike by end of Q2 2021.

This is the goal for the data science team. It focuses the team on the tasks at hand and filters some of their priorities based on the explicit goals of accuracy, usability and value.


A product team’s objective will often focus on the impact they’re trying to have on their target customers:

Ensure our partners can access our data regardless of where they are in the world by Q3 2021.


Finally, an infrastructure or internally-facing team will typically refer to the other teams they support (hint: these are their customers):

Protect the integrity of the data our teams use in our products and services by bringing the power of AI and Machine Learning to bear on our security infrastructure by Q1 2021.


Anti-patterns: One of the most common anti-patterns when writing objectives is detailing out the systems, projects or initiatives the team will be working on. For example, if your objective is:

Deploy the new payment gateway by end of year

What you’ve not done here is answered the question why. Why are we deploying the payment gateway? What benefit will doing so provide to our customers?

Another thing I’ve seen a lot is leaving out the time box. This is important because without a deadline the goal can go on forever. How will we know we should revisit it? At what point should we say this isn’t worth the effort? Deadlines help force those conversations. Yes, they may be arbitrary and can be extended but without them we could spin indefinitely on a challenge.

Key Results

What is it: Key results answer the question, “How will we know we’ve achieved the objective?” This is where the numbers come in. We want to quantify the success of our efforts with metrics. Now, these metrics are unique in that they are always measures of customer behaviour. In most cases we call these outcomes. It’s imperative that your key results measure customer behaviour because this is how you know that the feature, product, initiative or system you’ve put into play has met the needs of your customers. It’s not enough to simply ship a service these days, you have to measure what kind of impact it had on your customers. Did they come back more frequently? Did they use more of the product? Did they tell their friends about your service? Those are good key results.

What a good one looks like: Key results are always metrics, always measure customer/user behaviour and should, in most cases, be ratios or rates rather than absolute numbers.

Here’s an example key result based on one of the objectives from above:

Objective:
Ensure our partners can access our data regardless of where they are in the world by Q3 2021.

Key Result:
15% increase in successful log-ins from mobile devices

There are many instances where the team writing OKRs is an internally-facing team that supports other teams in the organisation. These teams invariably struggle to write good OKRs because they forget that those “other teams” that consume the services, code, tools or data they create are their customers. Here’s one example of an internally-facing key result.

Objective:
Protect the integrity of the data our teams use in our products and services by bringing the power of AI and Machine Learning to bear on our security infrastructure by Q1 2021.

Key Result:
Reduce the number of manual security processes for the infosec team by 50%.


Anti-patterns: The most common and egregious anti-pattern I’ve seen for key results is putting features (or output) as a key result. If the measure of success for your team is “we deployed the new mobile app” then OKRs lose their value immediately and you’re back in the waterfall world of linear planning. As soon as the key result stops being a measure of behaviour the system can be gamed and the real measure of success, the impact (hopefully positive) you’ve had on your customers is no longer considered something worth striving for.

What happens once you have good OKRs in place

Here’s the kicker: even if you write excellent objectives and key results, it’s all meaningless if you’re not prepared to change your ways of working. Why? Because OKRs change the definition of done. Instead of shipping features, throwing a party, giving everyone a t-shirt and moving on to the next item in your backlog, you have to actually check and see whether what you shipped changed customer behaviour in the way your KR’s predicted. If they didn’t, you’ll have to go back and iterate on your work. This often means that instead of launching a scalable, high-performance, secure software solution you’ll end up running and shipping lightweight experiments, learning from them and then adjusting what you’re building (and yes, your roadmap too) until you find the right combination fo code, copy, design, value proposition and business model that delivers the results you’re after.

I wrote about this a bit more here but the tl;dr is you’ll need to teach your teams how to do product discovery.

The upside is that this is the ultimate goal of your agile implementation as well so by writing good OKRs and then holding your teams accountable to them you’re encouraging their agility at the same time. Not too shabby!

OKRs aren’t just for business

The amazing thing about Objectives and Key Results is that they’re applicable in all parts of your life, not just for software products or work-related initiatives. In my newest book, Forever Employable, I discuss how to conceive, experiment and learn your way to developing a thought leadership platform that transforms the way you find your next career opportunities. The measures of success for these types of efforts? You guessed it, OKRs. The main difference here is that your “customers” end up being the audience you’re targeting with your content development and their behaviour change (their key results) are the actions they end up taking with your content. More on that topic here.

I am firm believer in the transformational power of OKRs. The key to making them work starts by writing them correctly. Everything that comes after that isn’t easy either, but without a properly written statement you’re off on the wrong foot from the get-go.

I’d love to hear what you think about this article and your experience with OKRs.