OKR: An Executive's Handbook for Objective and Key Results

Chapter 1: About OKR

This chapter is designed as an introduction. If you’ve done a bit of reading or spoken to a few people, it’ll probably sound familiar. For that reason, I’ve kept it short. The following chapters will focus more on the how and the why that are important at an executive level.

What Is OKR?

As mentioned, OKR stands for objective and key results.

The framework aims to efficiently and clearly track business objectives and their outcomes. It sits above projects and to-do lists.

An OKR is constructed with a clearly defined qualitative goal—the objective—and specific quantitative measures that denote the achievement of that goal—the key results. In the framework, each objective must have one or more key results. Success is therefore measurable and concrete.

A Brief History

The OKR framework was originally proposed and implemented by Andy Grove at Intel in the mid-1970s. It was built on top of a theory known as management by objectives, or MBO, by Peter Drucker. Eventually, in 1983, the definition was documented in Grove’s book High Output Management. In addition, Grove taught the concept to employees at Intel, who then spread the influence of the framework as they moved to other companies.

Notably, John Doerr is credited with popularizing the framework beyond Intel. Doerr—who was taught by Grove—introduced the concept to Google while working at the venture capital firm Kleiner Perkins. The firm invested in Google in 1999, and Google took up OKR in their workplace. Since then, it has spread to companies such as LinkedIn, Adobe, and Netflix, among countless others.

Chapter 2: Implementing OKR

While OKR is a relatively simple concept to understand, it’s not necessarily straightforward to implement. Success requires a few key rules and a company-wide cultural outlook.

This chapter addresses these key points by explaining how to write a good OKR before discussing how to instill a strong OKR culture.

How to Write a Good OKR

OKRs are best when they follow a consistent structure. Luckily, as a framework, that structure is well defined.

As it says, each OKR consists of one objective and one or more measurable key results. Therefore, you can write it with the following structure:

I/We will [complete objective] as measured by [these key results].

When writing an OKR, it’s important to keep in mind that the objective should be qualitative, while the results should be quantitative.

How you measure each key result depends on what it is and the context. The results must be numerical, as quantitative data—for example, a dollar value, the number of items, or a percentage.

How Many OKRs Should Each Team or Person Have?

As with everything OKR, there’s no hard and fast rule about the number of OKRs per team/person. Experiment within your organization and teams. It’s another example of the Goldilocks principle in action.

With that said, a good rule of thumb is to start with two or three objectives, each with three to five key results. This allows enough ambition and specificity over a quarterly period.

From there, individuals and teams can adjust to a cadence that suits them.

Example OKRs

Depending on your field of work, quantitative results may seem simple or difficult. I’m sure there are some of you out there thinking along the lines of, “How do I measure the impact of a call to a client where I didn’t sell anything but I fostered a positive relationship?”

As with everything, it’s easiest to understand if you have some examples to refer to.

Example 1: Software Release

We’ll successfully release version 1 of our software platform as measured by (1) achieving an initial 5,000 trial users, (2) having over 50% of the trial users convert into paid users, and (3) getting over four stars on three review websites.

By splitting that up, we can better see what’s going on:

• Objective (remember this is qualitative): Successfully release version 1 of our software platform

• Key results (and these are quantitative): 

  1. Achieving an initial 5,000 trial users

  2. Having over 50% of the trial users convert into paid users

  3. Getting over four stars on three review websites

Example 2: User Input

We’ll meaningfully integrate users into our development process by (1) performing 10 face-to-face test and interview sessions with users about new features, (2) conducting 50 phone interviews with users of the platform, (3) getting 100 exit surveys from users who have left the platform, and (4) beta testing 10 new features with real users of the platform.

As I’ve mentioned many times, the OKRs above are ambitious. It’s unlikely that they’ll be achieved in a quarterly time frame. However, by setting them ambitiously, everyone in the organization has something positive and united to work toward.

I’ll touch more on these examples in Chapter 4, linking them directly to value stream management on Plutora, which, as a software platform, truly facilitates OKR.

Instilling an OKR Culture

It’s hard to put it more succinctly than the following quote from John Doerr:

[H]ealthy OKR culture [requires] intellectual honesty, a disregard for self-interest, [and a] deep allegiance to the team.

John Doerr in Measure What Matters

The following rules for success help to flesh out what that means in practice. It’s also vital to decouple rewards from performance, as I describe below.

Rules for Success: The PACT Approach

To successfully implement OKR, it’s crucial to have the right organizational culture. The following rules help to ensure your organization has just that. They can be remembered easily with an acronym that I like to use, PACT, which stands for public, ambitious, complex, and time frame:

1. Be public. Both objectives and their results should be public across the organization. As a result, employees and teams assist each other. Meanwhile, results are still measurable. It also helps to prevent overlap of work.

2. Be ambitious. Goals should be relatively hard to achieve. By ensuring ambition, you and your employees are aiming to always improve the business. There’s a balance to be found here. If you’re always reaching or exceeding the goals, they’re not ambitious enough, but if you never reach any of them, they’re too ambitious. Somewhere around an average of 60 to 80% achievement is a good ballpark.

3. Be reasonably complex by nature. Objectives aren’t to-dos. They should be complex enough to support a large volume of related work. This ties in with the time frame and ambitious nature.

4. Have a long enough time frame. This varies from team to team, person to person, and company to company. OKRs need to sit above the fluctuation of day-to-day business. Therefore, they can’t have time frames that are too short. A good rule of thumb to start with is to aim for approximately quarterly results and then adjust to suit your business.

By following the four rules in the PACT approach, you’ll be able to support objectives with business initiatives that fit into the wider company strategy.

Decoupling Rewards and Performance

In addition to the four rules above, it’s important to stress that OKRs must not be tied to performance results. That means don’t reward compensation or promotion by OKR achievement.

The reason for this decoupling is simple. OKRs are intended as a set of ambitious goals that may or may not be achieved. Therefore, employees should not be punished for aiming high.

Chapter 3: Why Is OKR so Popular

Most people credit the popularity of OKR to John Doerr and Google. However, if it didn’t work, it wouldn’t be popular. Thus, the reason OKR is so widespread is that it fits the modern work environment. It’s a round peg in a round hole.

This chapter looks at why so many companies, especially in the tech sphere, have implemented OKR.

Why Google (And Others) Use OKR

The growth of OKR from Intel to Google and then onto the countless large and small companies today is nothing short of phenomenal. OKRs can be successfully implemented in a company with under five employees, all the way up to companies with tens or hundreds of thousands of employees across the globe. That alone is one of the main reasons why it’s so widely used. However, that’s not all there is to it.

As I said earlier, the framework is a round peg in a round hole. The benefits of OKR almost perfectly align with modern company goals and the mindset of modern employees. This creates strong alignment in the organization.

Commonly cited benefits include the following:

• Accountability: Clearly set and measurable goals enable improved accountability from everyone in the organization.

• Agility: Shorter cycles (quarterly vs. the usual yearly) allow employees, teams, and companies to better adapt.

• Ambition: Decoupling rewards allows employees and teams to implement blue-sky, moonshot, and style goals and thinking.

• Autonomy: Goals are set by individuals and teams. This allows work to progress openly and independently to a common company growth.

• Cooperation: Openness and transparency foster cooperation, as does ambition.

• Engagement: The onus to set goals is on the individual or team, so they’re more engaged with the outcome.

• Efficiency: OKRs are easy to set with fewer goals and measurable outcomes, enabling efficiency gains.

• Focus: Reducing the number of goals and sharing them transparently across the organization prevent double work and foster team focus on a common set of initiatives.

Alongside these are the cultural improvements that coincide with OKR use. Through OKR, work becomes less prescriptive, so employees and teams feel more involved. The benefits above also breed feelings of success and unity.

Chapter 4: OKR for Operations

With the scene set for what OKR is, how to implement it, and why it’s so popular at an overview, this chapter drills in a bit further, looking at the shift in operational thinking OKR can accommodate and examples from Plutora.

Moving From Project Management Thinking to Outcomes Thinking

Before diving into this, let me briefly define what I mean by project management thinking and outcomes thinking.

Project Management Thinking

Project management thinking is the concept of considering units of work as individual and distinct projects. That is, you have a development project to make a UI for your platform and another project to sell the platform to new clients. In project management thinking, these are two distinct sets of activity with numerous timelines and goals. They might have dependencies on one another, but in essence, they’re separate. Success in one or both of the projects also doesn’t guarantee organizational benefits. For example, you may sell to more customers while getting a bad reputation due to a UI mismatch. However, since they’re separate, there’s no way to effectively see (and fix) the mismatch problem.

Outcomes Thinking

Outcomes thinking looks at progress from the other direction. In the above example, the intended outcome of both projects is to increase the number of users on the platform. The UI project helps this by improving user satisfaction, and the sales project does this by introducing new customers to the platform. In outcomes thinking, they can still be distinct undertakings, but they’re inextricably linked. One doesn’t happen without the other, and both teams are united toward a common goal, which is to the benefit of the organization and the customers. Outcomes have a business goal, rather than a project goal. They’re generally measurable and cover multiple projects.

Using OKR to Facilitate the Transition

I’m sure you’ve already noticed some commonality in the language between outcomes thinking and the OKR descriptions in the previous chapters. And why wouldn’t there be? Results are very similar to outcomes.

Thus, using OKR to facilitate a transition to outcomes thinking is a natural step. The following tips will help to expedite the change and reap the benefits.

1. When getting employees to define their OKRs, make sure they’re business related. That is, the key results should measure something meaningful to the business, rather than something internal to a project.

2. Construct your teams so that they’re product oriented rather than project specific. In this way, they’ll be more cross disciplined and aim for objectives rather than projects, almost by default.

3. Return to the OKRs often. This ensures everyone stays focused on what they set out to achieve and aren’t sidetracked by project-specific details.

Example on Plutora

Why am I writing an executive OKR handbook on the Plutora blog? Plutora is a perfect example of where a software platform enables OKR practice. This is best illustrated through the release management process and value stream management.

Looking back at the two examples from Chapter 2, we can see they both fit within value stream management.

The first example, about software release, had the following three key results:

1. Achieving an initial 5,000 trial users

2. Having over 50% of the trial users convert into paid users

3. Getting over four stars on three review websites

Plutora’s dashboards allow you to make graphs that visualize the three metrics (or any others you choose to use). These are business intelligence metrics that occur in the release and monitor phases of value stream management. The platform will record these numbers automatically and make them visible and easily digestible across the organization. That is, the release value streams dashboard displays and tracks specific OKRs.

The second example, about user input, occurs on the other half of the value stream management cycle: from ideation through to building and testing. The key results were as follows:

1. Performing 10 face-to-face test and interview sessions with users about new features

2. Conducting 50 phone interviews with users of the platform

3. Getting 100 exit surveys from users who have left the platform

4. Beta testing 10 new features with real users of the platform

This side relies more on Plutora’s analytics capability. With the analytics visualizations, you can see which features have been released, who they’re released to, and information about the testing and feedback. Similarly, you can tie in results from specific questions in exit surveys.

Summing Up

While OKR is a relatively simple topic to understand, it’s much more nuanced from an executive perspective. As a result, I split the post into a series of chapters that addressed different aspects of the executive perspective. These should help you to not only understand the concept of OKR, but also to get a good idea of how to implement it in your organization. Doing so may require a shift in culture and a shift from project management thinking to objectives thinking, but software platforms, such as Plutora‘s, can help to facilitate these shifts and integrate OKR in business and development operations.