To be blunt: when I first encountered the term OKR, which stands for Objectives and Key Results, I wasn’t exactly thrilled. To me it sounded like a bunch of management mumbo-jumbo, which basically boils down to setting goals with corresponding KPI’s, as @mattbarcomb was silently whispering on twitter. The thing is, although he is probably more right than wrong, it doesn’t really matter much. Because the new language and super-simple format still helps focus, alignment, autonomy, local decision making and working towards outcomes instead of outputs, and that is often missing when companies decide to ‘go Agile’.

So. What are OKR’s then?

The idea originated inside Intel and was cooked up by one of its founders Andy Grove, who wrote about it in 1983 in his book “High Output Management”. Google in its early years embraced the methodology and claims to have immensely profited from it, and currently lots of other high profile companies use OKR’s as a means to align and focus on strategy throughout their organization.

In theory it’s simple

In theory, implementing OKR’s is simple: somewhere at the C-level of an organization a mission, vision and strategy have been formulated, which translates into certain annual strategic goals, and below them quarterly Objectives to aim for in the upcoming months. Just 3 or 4, they should be easy to remember, they should stick!

For example: in a financial business to business company which offers a suite of products a quarterly Objective might be: “In the next quarter surpass our biggest competitor in market-share”. A goal should be public, inspiring and clear. Having a goal to aim for gives direction and focus, but is of little value when there is no way to measure success. Key Results are used to solve that problem. Key results aren’t exactly the same as KPI’s (Key Performance Indicators) though. They are better described as ambitious targets to aim for, a bar that is intentionally set too high. There is a sweet spot however. They should indeed be ambitious, but not to the point that they will be impossible to hit. When achieving 70% - 80% of the Key Result, you actually hit that sweet spot. Higher means you might want to reach for stars further out in the galaxy, lower indicates that you set the bar too high and might want to reach for the moon first (to stretch that analogy to its limits).

Back to the example. One of the underlying Key Results for this Objective could be “In the next quarter the number of product suite subscriptions in our home country should increase by 20%”. The Objective and Key Result along with a couple of others are handed down one level, where they form the context in which on that level OKR’s can be set. So your software development teams will set their own goals, for instance by researching the top 3 problems that keep new customers from coming in and forming initiatives around these issues. The sales team might set its goals based on market- or product segment, in this way creating more fine grained OKR’s for themselves based on the overall Objective.

This floats all the way down the organizational hierarchy, ensuring alignment from the more abstract goals at C-level down to very concrete ones where ‘the actual work happens’. At the same time every hierarchical level is responsible for setting it’s own OKR’s, based on the assumption that people are motivated to ‘work hard and do good’, with the intent to empower and create ownership over ones own OKR’s.

So basically we have a simple model for creating direction, alignment. With a focus on outcomes, creating ownership and empowerment in the right place. Sounds good right?

In reality

Well yeah, in theory that is. In practice I assume most of us know about the fact that culture eats process for breakfast. From my experience, and this is one of the most important lessons I’ve learned implementing OKR’s so far, is that it takes a lot of time to shift from an output-based mindset to an outcome-based one. Output being: features, velocity, ‘stuff’ out the door versus outcome meaning a particular value metric being moved in the right direction. Think for example: ‘cool shiny new other people also bought’ (feature) versus cross-sell numbers increasing significantly during checkout (result).

When talking to (middle) management, they are more often than not inclined (and incentivized!) to propose ánd deliver specific outputs. Even worse, they have roadmaps full of ‘stuff’, unvalidated and sometimes more ego- than market driven, ready to be ‘produced and delivered’. The so called HiPPO* determines what teams get to deliver.

Development teams in the meantime are so used to getting pixel perfect designs passed to them to ‘refine and estimate’, that they start feeling uncomfortable when they are asked to experiment around a problem or opportunity. It is frequently the teams that start begging for visual designs before they are willing to even discuss a particular problem area.

So implementing OKR’s and reaching the point where you start reaping its fruits is hard. Here are some tips you might find useful and common pitfalls to avoid.

Do’s & don’ts

3 times the charm

Set up for failure. That is: expect the first couple of rounds of creating OKR’s to fail, and set expectations accordingly. Describing the right objective, genuinely thinking about what you want to achieve instead of what you want to produce is really hard. It is even more difficult to get the Key Results right. You need to establish your current baseline in terms of metrics, and really have an idea of what initiatives you can take on in one quarter to move that number in the right direction. Working together with a data-analyst helps a lot. It took us about 3 attempts to get OKR’s that feel somewhat on the mark, others have had similar experiences**.

Key Results != task lists

This again boils down to working towards outcomes, but happens before you know it. Somehow there is this intrinsic tendency to think in to-do lists, functionality, tasks. So its all too easy to create Key Results like ‘Create 30 unit tests for module X’ or ‘Hold 30 job interviews for department X’. In no way is it clear how these so called Key Results have any effect on the Objective. Better would be something like ‘A maximum of 5 bugs are found in production’ and ‘Fill in 50% of the vacancies in department X’ (the last one should probably be accompanied by a Key Result indicating the quality of the hires).

OKR’s != road maps

At first different involved parties will for better or worse try to cram their existing road map into OKR’s. Existing features will be converted to initiatives, Key Results are made up based on these initiatives and eventually Objectives arise from these. Although this is far from ideal, it might actually be a good first step in working with OKR’s, as long as everyone is clear on the fact that this is only step one, and the next step should be to start defining the Objectives and work downwards from that (this is what we did at one of our clients). If you can skip this step, make sure you do, because it takes quite some energy later on to convince people that the approach should be flipped and one should start working from Objective down to Key Results down to initiatives. Especially convincing them it doesn’t really matter what the initiatives look like as long as Key Results are moved in the right direction can be quite hard.

All in

Go all in. Get top-level support and try to implement from top to bottom. It is way easier to have success when everyone at all levels focuses on realizing the same goals, and one of the big reasons for OKR’s to exist is the creation of alignment throughout the organization. Pitch it as an experiment, don’t sell it as the next silver bullet that will solve all alignment, miscommunication and corporate politics problems, but try to approach it as a lightweight minimum effort tool that can be iteratively improved.

Keep the soul alive

If you want OKR’s to come alive, keep your results up to date and score them on a weekly basis, share them with the team. Take for instance the stakeholder review at the end of a sprint to look at the latest data, and most importantly: have a conversation around them. Discuss why certain results are positive, and why some are lagging behind. Think about the initiatives the team can undertake to get that number moving in the right direction. This is where the value lies in applying OKR’s, and what links the framework with Agility (adjusting your course based on feedback).

So are OKR’s worth it?

If you are in an organizational context where there is no shared vision on what measurable goals can be achieved, and/or there is no framework in place for letting people work on these goals in a meaningful way, then implementing OKR’s can be a very useful exercise. You might accidentally introduce more autonomy and focus as well! If your work feels very output focused, OKR’s might actually help you move away from being a feature factory towards delivering measurable value for customers and stakeholders.

*Highest Paid Persons Opinion

**If anything, read this post by Dan North. Clear and fair assessment of what OKR’s are and how they can be applied