Objectives and key results

Many companies that are practicing DevOps are using objectives and key results (OKRs)—among them Google, Microsoft, Twitter, and Uber.

OKR is a flexible framework for companies to define and track objectives and their outcomes.

The OKR method dates back to the 1970s when Andrew Grove, the father of OKRs, introduced the method to Intel. The method was called iMBO, which stands for Intel Management by Objectives. He described the method in his book High Output Management (Grove, A. S. (1983)).

In 1999, John Doerr introduced OKR to Google. He had worked for Intel when Andrew Grove introduced iMBO there. OKR quickly became a central part of Google's culture. John Doerr published his book Measure What Matters (Doerr, J. (2018)), which made OKR famous. If you want to learn more about OKR, I highly recommend reading this book.

What are OKRs?

OKR is a framework that helps organizations to achieve a high alignment on strategic goals while keeping a maximum level of autonomy for teams and individuals. Objectives are qualitative goals that give direction and inspire and motivate people. Each objective is associated with unambiguously measurable quantitative metrics—the key results. The key results should focus on outcomes and not on activities, as illustrated in the following table:

Table 1.2 – Characteristics of OKRs

OKRs should in no way be associated with the performance management system of the company or bonuses for its employees! The goal is not to achieve a 100% success rate for OKRs—this would mean the OKRs are not aggressive enough.

OKRs are written in the following format:

We will [objective]

As measured by [set of key results]

It is important that OKRs focus on outcomes and not on activities. A good example is an objective that was set by Google's chief executive officer (CEO) Sundar Pichai in 2008 when Google launched their Chrome browser. This was the OKR:

We will build the best browser

As measured by 20 million users by the end of 2008

The goal was bold for a new browser and Google failed to achieve this in 2008, getting fewer than 10 million users. In 2009, the key result was increased to 50 million users, and again, Google failed to achieve this, with about 37 million users. But instead of giving up, the key result was again increased in 2010—this time, to 100 million users! And this time, Google overachieved their goal, with 111 million users!

How do OKRs work?

For OKRs to work, a company needs a good vision and mission that defines the WHY: Why are we working for this company? The vision is then broken down into mid-term goals (called MOALS). The MOALS themselves are also OKRs. They are broken down into OKRs for an OKR cycle, typically between 3 to 4 months. In OKR planning and alignment, OKRs are broken down in the organization so that every individual and every team has its own OKRs that contribute to the bigger goal. The OKRs are then continuously monitored, normally on a weekly basis. At the end of the OKR cycle, the OKRs are reviewed, and the achievements (hopefully) celebrated. With the learning from the cycle, the MOALS get updated and a new cycle begins, (see Figure 1.6).

Figure 1.6 – The OKR cycle

OKR in theory is simple, but implementing it is not. Writing good OKRs is especially hard and needs a lot of practice. There are also strong dependencies on the corporate culture and existing metrics and key performance indicators (KPIs) that are measured.

OKRs and DevOps

Once implemented correctly, OKRs can give you the ability to have a strong alignment between your teams by preserving their autonomy to decide on their own what they are building, and not only on how they build it, (see Figure 1.7). This is important when we talk about experimentation in Chapter 19, Experimentation and A/B Testing with GitHub. Your teams can define their own experiments and measure the output. Based on this, they decide which code stays in the projects and which doesn't.

Figure 1.7 – OKRs help to achieve autonomy and alignment

Let's now look at an example.

Your company's vision is to be the market leader in online visual project management tools. Your product has a current market share of 12%. The company MOAL is the following:

We will build the best visual project management tool

As measured by a 75% market share by the end of 2025

Your product is built by two teams: one team focuses on the core of the product and builds the visuals for project management. They focus on the existing customers and building a product that the customers love. They agree on the following OKR:

We will build the visual project management tool that is loved by our customers

As measured by an NPS of higher than 9

The NPS is currently at 7.9, so the team must figure out on their own what they can do to delight the customers. After a few interviews with some customers, they formulate the hypothesis that all the project management tools are based on older project management techniques and are too complicated in a more agile-oriented project world. They decide to conduct an experiment with part of the customers, with a completely new concept on how to visualize the project to confirm or diminish the hypothesis.

The second team is the shared services team. They focus on user management, enterprise integration, and billing. The product needs more new users to achieve the MOAL, not only to make the current ones happy. So, the focus in this OKR cycle is on bringing new customers to the product, as illustrated here:

We will build a project management tool that is easy to use for new customers

As measured by a 20% increased monthly new registered users

Currently, newly registered users have flattened, so the intent is to start growing again. The team looks at the numbers and finds that a lot of new customers quit the registration process on the details page, where they must enter their address and banking details. They have the hypothesis that more customers would try the product and hopefully stay on the platform if the registration process were easier. They decide to conduct an experiment and reduce registration to the minimum that is required for authentication. They grant new users a 30-day free trial and request payment details after that period.

I will explain in Chapter 18, Lean Product Development and Lean Startup, and Chapter 19, Experimentation and A/B Testing with GitHub, how hypothesis-driven development and experimentation work. This is independent of OKR, but both work very well together.

If you are interested in real-world OKRs, GitLab share their OKRs publicly (https://about.gitlab.com/company/okrs/). They also share their entire process and how they link OKRs to epics and issues.

OKRs are not a prerequisite for DevOps. But as with agile practices, they are just a natural match. If you are not working in an agile way and start with DevOps, your way of working will become agile anyway, and you can benefit from frameworks such as Scrum to not invent the wheel again. And the same is true for OKRs: they come naturally when you scale DevOps in big organizations and you want to provide teams with great autonomy by maintaining an alignment to global goals.