Objectives and key results (OKRs) overview

About OKR objectives

The goal for the 'O' (or objective) in an OKR is to communicate what the desired outcome is in a concise manner so that it can be effectively shared and deeply understood with the least amount of information required. Think of the objective as an elevator pitch.

An OKR’s objective describes what we want to achieve, since the key results will articulate how we will measure success. The title (summary) and description used to define objectives are meant to cast a purpose and not necessarily outline the specifics of what we want to measure.

How to write a good objective definition

The objective definition is the rallying cry. The definition of success may change, but the overall direction should remain the same. The language used here will help us define success. When you write a good objective, anyone in the organization should understand how the objective:

• Aligns with higher-level objectives. Alignment is a bi-directional conversation between levels of the organization that challenges whether the strategic focus is right. OKRs are not meant to be a top-down cascade of orders. They are meant to provide visibility into the desired outcomes of the business and empower teams to decompose the best opportunities to move the needle.

  Aligning OKRs with the higher-level objectives in the organization is not a requirement. In fact, misalignment could be a necessary metric to highlight where the strategic direction is questioned or simply a symptom of domain-specific goals (like handling tech debt or reducing meeting hours).

• Communicates a goal without detailed explanation. Objectives should be clear, concise, and perpetuate a message. As you start to identify opportunities or solutions, quickly communicate why you are doing something by communicating the objective simply. Writing a concise objective that gets the message across is hard. Keep in mind that the people talking about the objective to explain why their work matters are typically not the ones who wrote the objective, but they need to be bought into the vision and feel enabled to share that vision with others.

• Presents a challenge that incites action. Language matters. When stating the objective, it should inspire ideas on how we might achieve the desired outcomes. As an example, saying you want to “increase monthly active users” may spark some ideas, but saying that you want to “make the product infectiously sticky” states a vision that can get us thinking about unique solutions. A goal to increase monthly active users might box us into technical solutions; when we talk about being “infectiously sticky”, we may consider how we might change the way users talk about or share our product. Objectives are more powerful when they articulate a change in behavior over a change in a specific metric.

Example

Maybe we want to move our business to the cloud over the next five years, but why do we want to do that? It may be easy to create an objective to “Move to the cloud by 2026”, but we can create a more powerful objective if we understand what change in behavior or impact to the business we’re trying to drive.

Change in behavior: Grow new and existing customers through better reliability, security, and an improved customer experience across our product suite.

Business impact: Improve the bottom line across the product suite without sacrificing quality.

When we say “Move to the cloud by 2026,” it may be challenging to immediately think of possible solutions and how to measure success, but when we focus on a change in behavior (like having more happy customers using our products) or an impact to the business, we’re immediately inspired with ideas on how we might achieve that – beyond moving to the cloud.

About key results

Key results outline how to measure success for the objective and should be results-driven, as opposed to a checklist of things to do. There is no guarantee that anything we do to move the needle will actually have an impact. For that reason, it’s best to focus on the desired outcome over what you believe you need to do in order to achieve that outcome. The key results help bridge the gap between the qualitative mission outlined in the objective and how success is defined as you execute against that mission.

To challenge whether you’re focused on an outcome over outputs or activities, it’s helpful to ask, “Why?” until you arrive at a measurable business impact or change in behavior.

Example

Imagine we have our “cloud transformation” objective with a key result that states, “Retire 100 on-premise servers by 2023”. Though this is a valid key result, if we ask why we’re focused on this measure, we might get a response like “to reduce maintenance costs of supporting on-premise infrastructure”. Though we may assume retiring servers and taking advantage of cloud architecture will reduce the cost of maintaining those servers, our key results should focus on the business outcome – reducing infrastructure maintenance costs. Retiring servers is the opportunity we’re investing in to move that needle.

A powerful key result focuses on what it means to be successful. Retiring servers doesn’t guarantee that we will see any positive outcome for the business. In this case, reducing maintenance costs is what truly represents success, regardless of whether retiring servers is the best opportunity to get there.

About aligning work

If objectives set the vision and key results define success, alignment with work is the critical intersection to understand if what you are doing is working.

There are a few general ways to align work, ranging from being more outcome-driven to more output-driven:

When you identify the best opportunities to achieve the outcome or simply align existing work with an OKR, you want the work to answer a few key questions:

• What are we doing and why?

• What do we plan to learn from what we’re doing, and by when?

• How will the outcome impact our next decision?

To answer these questions, it’s helpful to:

• Take a hypothesis-driven approach to our business cases. A hypothesis statement (if this… then this…) can help to quickly understand why you believe the work will have an impact and how you will know if you’re right.

• Identify assumptions to help us prioritize learnings. Assumptions tend to fit into one of two buckets - assumptions that make or break the idea or assumptions that can influence direction. We want to identify any core assumptions that if wrong, would scrap the whole idea. In most cases, identifying the wrong thing to build early on is more valuable than building the right thing.

Example

Now we have our objectives to improve the bottom line and focus on reliability, security, and customer experience. We also have a key result to reduce infrastructure maintenance costs.

Let’s say we found that our ops teams spend more time troubleshooting and resolving on-premise customer issues that would be negligible if they migrated to the cloud. Furthermore, these on-premise customers are mostly public sector, but they have security objections to the cloud. We might frame an opportunity like this:

Hypothesis: We believe that if we support FedRAMP compliance across our cloud products, then we will see more public sector customers migrate to the cloud reducing on-prem support costs.

Now we can outline assumptions we need to validate in order to build confidence that what we’re doing will in fact reduce on-prem support costs.

Assumptions:

• Removing the FedRAMP objection will be compelling enough to migrate public sector customers to the cloud
• FedRAMP compliance will drive enough customer migrations to substantially move the needle for on-prem support costs
• Moving these public sector customers to the cloud will not substantially increase cloud support costs

As we outline our assumptions, we can see that our first two assumptions are critical. In order for this initiative to be successful, we need to prove that customers do in fact need this and that enough customers need it to drive the outcome we want. Whether or not it increases cloud support costs may be informative, but not a deal-breaker.

The intersection of the OKR and the aligned work is what continuously reveals whether we’re building the right thing. Once we have that learning loop, we can focus on optimizing it by delivering the least amount of work to validate or invalidate our most important assumptions.