Remove OKR process from the Public Handbook Pages

description: "An overview of how OKRs may be done."

---

The OKRs set of pages provide general guidance for the teams who wish to use OKRs.

See also:

1. What OKRs are, and general guidance on how to formulate them, on [the general OKRs page](okrs-basics.md).

1. How to enter and organize OKRs in GitLab, on [the OKRs in GitLab page](okrs-in-gitlab.md).

## Overview

[OKRs](okrs-basics.md) are quarterly objectives that can help achieve [KPIs](../kpis.md).

We do not use it to [give performance feedback](/handbook/people-group/360-feedback/) or as a [compensation review](/handbook/total-rewards/compensation/) for team members.

## OKRs are what is different

The OKRs are what we are focusing on this quarter specifically. Our most important work are things that happen every quarter.

Things that happen every quarter are measured with [Key Performance Indicators](/handbook/company/kpis/).

Part of the OKRs will be or cause changes in KPIs.

### Measuring Brand New Initiatives

Some KRs will measure new approaches or processes in a quarter. When this happens, it can be difficult to determine what is ambitious and achievable because we lack experience with this kind of measurement. For these first iterations, we prefer to set goals that seem ambitious and expect a normal distribution of high, medium, and low achievement across teams with this KR.

### Shared Objectives

If there is something important that requires two (or more) parts of our organization, all leaders involved should share the same or similar objective. They should have deconflicted key results so they can still achieve things within their sphere of control. This is in keeping with our concepts of [collaboration](/handbook/values/#collaboration) and [directly responsible individual (DRI)](/handbook/people-group/directly-responsible-individuals/#what-is-a-directly-responsible-individual).

### Pass-thru Key Results

It's acceptable for managers and reports to have an identical key result. For instance, something really important might need to happen at the executive level, but it's a manager or IC several layers apart who is doing the actual execution. Every person in that line of reporting should have the same key result.

While it can feel like double-counting, it is consistent with [Andy Grove's](https://en.wikipedia.org/wiki/Andrew_Grove) concept of Managerial Leverage outlined in his book [High Output Management](https://www.amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884). This ensures that conversations happen in the relevant 1-1s, that everyone knows the latest status, and that the person executing does not accidentally get re-tasked. Please remember to recognize the person that achieved the result so there is no perception of "taking credit" for others' work.

### Target Dates in Key Results

Just because quarters are a useful timeframe for objectives, does not mean that key results should default to being due on the last day of the quarter. This could lead to unnecessary delays. Consider putting specific target dates into the key result phrase to indicate when it is needed by.

You should decide your scoring methodology ahead of time. You might score an OKR as 0% if it misses its target date. Or, if it's less time sensitive, you might penalize it 10% for each week it's delayed.

### How do I prioritize OKRs in light of other priorities?

OKRs do not replace or supersede core team member responsibilities or performance indicators. OKRs are additive and are essentially a high signal request from your leadership team to prioritize the work. They typically are used to help galvanize the entire company or a set of teams to rapidly move in one direction together. You should aim to complete them unless you have higher priority work that is surfaced and agreed to by leadership.  When surfacing tradeoffs, team members should not factor in how an unmet OKR may impact your executive leadership bonus in their prioritization. They should instead focus on GitLab priorities.

## Maintaining the status of OKRs

Teams should update the score for their key results in GitLab regularly.

### Health Status

When presenting the status of OKRs, we use the following terms to denote the status of a key result:

1. On track - the DRI is confident the key result will be achieved.

1. Needs attention - the DRI believes there is some risk the key result will be achieved. Elevated attention is required in order for the key result to be achieved.

1. At risk - the DRI does not expect the key result will be achieved. Urgent action is required in order for the key result to be achieved.

An Objective/Key Results health status should be maintained as the SSOT on the status. This is something that should be able to be referenced at any point in order to get a clear view of progress against the objective. The objective owner will be responsible for designating a health status based on a roll up the health statuses of all relevant KRs.

Each KR should have a clear scoring.

## Scoring OKRs

OKRs and their scoring align with fiscal quarters.

Since we set OKRs that are aspirational, we [don't expect 100% achievement](okrs-basics.md#criteria-for-key-results) across KRs. We score individual KRs to note our achievement against our stated goal. This is the scoring framework.

| Achievement against targets | Score |

| ------ | ------ |

| On-target | 85 to 100% |

| Off-target | 70 to 84% |

| At risk | 0 to 69% |

See also [Tips for OKRs that are scoreable](okrs-basics.md#tips-for-okrs-that-are-scoreable).

For more information on how objectives are set and managed in GitLab today please review the internal [GitLab Operating Model](https://internal.gitlab.com/handbook/company/gitlab-operating-model/) Handbook page.

---

title: "Overview of Objectives and Key Results (OKRs)"

description: "General information on OKRs, criteria, and guidance on how to write them."

weight: 1

---

## What are OKRs?

[OKRs](https://en.wikipedia.org/wiki/OKR) stand for Objectives and Key Results and are our quarterly objectives.

OKRs are *how* to achieve the goal of the Key Performance Indicators [KPIs](/handbook/company/kpis/).

They lay out our plan to execute our goals, which in turn support our strategy, and help make sure our top goals and how to achieve them are clearly defined and aligned throughout the organization.

**Objectives** are an aspirational goal to be achieved. They define *what* we're aiming to do, and they show how individual, team, or department work impacts the overall direction of GitLab by connecting work to overall company strategy.

**Key Results** are measures of progress against aligned objectives. They capture *how* we measure success in obtaining the objective. By achieving a Key Result (outcome), we create progress for the linked objective.

You can use the phrase "We will achieve a certain OBJECTIVE as measured by the following KEY RESULTS…" to know if your OKR makes sense.

The OKR methodology was pioneered by Andy Grove at Intel and has since helped align and transform companies around the world.

OKRs have four superpowers:

- Focus

- Alignment

- Tracking

- Stretch

## Fundamentals of Impactful OKRs

When writing objectives and key results focus on what you want to accomplish (the objective) and how you will measure the success (the key result).

To learn about the industry best practices for OKRs, how setting the right goals can mean the difference between success and failure, and how we can use OKRs to hold our leaders and ourselves accountable, watch [John Doerr's Ted Talk](https://www.youtube.com/watch?v=L4N1q4RNi9I).

When planning OKRs, be sure to consider [OKRs at GitLab](/handbook/company/okrs/).

### Criteria for Objectives

Objectives should be:

1. **Ambitious** - More than just "business as usual" or incremental change, an objective describes an aspirational yet attainable transformation, growth, improvement that significantly improves the current situation. A few examples:

    1. Introduce disruptive innovations

    1. Establish differences between GitLab Inc. and competitors

    1. Be recognized as an industry leader in a category

1. **Meaningful** - A top priority that advances GitLab's strategy and greater mission; provides direction to departments, teams, and individuals about where we are going and how we are getting there.

1. **Inspirational** - By providing an aspirational yet meaningful target, empower teams to reprioritize work to focus on what makes the most progress against an objective; to accomplish this, objective should also be easy to remember.

1. **Align Teams & Individuals** - Need to be broad enough to be relevant to at least more than one department, team, or individual one level down, but also specific enough that the objective can be measurable by up to three key results; if associated Key Results are satisfied, Objective should be achieved.

    1. For example, a product-related OKR at CEO level such as increase users by 100% would have the Product leader as the DRI but every other function would also need to contribute to achieve that KR.

1. **Clear, Responsible Party** - While aspirational objectives will often require collaboration and teamwork, they should have one DRI responsible for ensuring the completion the objective. This prevents [diffusion of responsibility](https://www.britannica.com/topic/bystander-effect/Diffusion-of-responsibility).

1. **Focused** - A person or team should have no more than 3 Objectives in order to focus on only the highest priority items; this also provides clarity on **what we will not do** in order to remain focused.

1. **Transparent** - Allow individuals, teams, and departments to see how their work contributes to the overall goals of GitLab. By sharing OKRs, individual, team, and departments are able to spell out their priorities and avoid having others disrupt focus with non-priority items.

### Criteria for Key Results

Key Results should be:

1. **Iterative** - Aligned with our core value of [iteration](/handbook/values/#iteration), a Key Result should focus on number of iterations or steps on the way to an outcome instead of just the outcome. Deliver x iterations instead of deliver y functionality.

    1. For example, if we need to create a certain number of experimental and beta features to ultimately get to 1 GA feature, break the KR down into iterative pieces such as deliver 16 experimental features, 2 beta features, and 1 GA feature to highlight the iterations required to get to the end result, instead of only focusing on the end result.

1. **Aspirational** - Ambitious but realistic stretch goals; if it feels uncomfortable, it's a good KR.

    1. If you achieve less than 70% of your KRs, you may be stretching beyond what is achievable. If you are regularly achieving 100% of your KRs, your goals may not be ambitious enough.

1. **Linked** - Be aligned to an Objective and be relevant to teams one level down; this alignment also allows KRs to easily roll down to become objectives one level down.

    1. KRs should not be too specific that the KR needs to be rolled more than one level down.

1. **Clear, Responsible Party** - one single person or team responsible for Key Result.

1. **Influenceable** - the Key Result owner (department, team, or individual) should be able to impact Key Result through the owner's actions.

    1. **Example**: an individual KR to change company-wide net retention is too broad; there are too many other conflating factors for an individual to determine impact. However, net retention could be appropriate KR for an entire department.

1. **Time Bound** - has a due date. At GitLab, unless otherwise stated, this is within the quarter.

1. **Measurable** - As Key Results provide the milestones for how we'll complete objective, KR should be either a *qualitative* (i.e. completed Y/N or number of steps of project completed) or *quantitative* (increased a metric by x) measure that can prove we accomplished the Key Result. *Quantifying Key Results strongly preferred.*

1. **Mutually Exclusive** - Measure one component of progress for an objective without overlapping with progress represented by other Key Results. Progress for one Key Result shouldn't count towards another Key Result.

    1. **Example**: A Key Result for number of transactions and a Key Result for average dollar amount of transactions are an example of mutually exclusive Key Results: one KR measures *volume* while the other Key Result measures *quality* of volume. On the other hand, a Key Result for total number of transactions and a Key Result for number of transactions from North America is an example of an overlap: progress gets 'double-counted' for both Key Result.

1. **Collectively Exhaustive** - Key Results should fully account for what's required to achieve an objective. If all Key Results are achieved, then, by default, the Objective must also be achieved.

1. **Few Words and Ubiquitous Language** - [As defined in Handbook](/handbook/communication/#mecefu-terms).

*You can score your OKRs against these criteria to determine whether your OKRs are effective.*

## How to Write OKRs

The following formula can be used to write objectives:

Verb + What you want to do + In order to/for/so that (what you hope to achieve or rationale for objective).

**Objective Example**: Increase awareness of company in the market in order to increase sales.

- *Clear goal including rationale for pursuing that goal*

The following formula can be used to write Key Results:

Verb + what you're going to measure + from "x to y".

**Key Result Example**: 100% of employees certified on OKR expectations and process.

For information on getting started with OKRs and writing basic OKRs, consider reviewing the [OKRs 101 lessons on What Matters](https://www.whatmatters.com/okrs-explained). The ["6 Principles of setting OKRs"](https://primalogik.com/blog/okr-examples-best-practices/#How-to-Set-OKRs) may also be helpful.

Teams should limit the number of OKRs they commit to so they have reasonable bandwidth to deliver. When planning OKRs:

1. Consider non-OKR commitments. While OKRs are the big commitments that the team is making, they [do not supersede core team members responsibilities](_index.md#how-do-i-prioritize-okrs-in-light-of-other-priorities). This means retaining team capacity beyond OKRs for work that falls higher in a prioritization framework ([example from product](/handbook/product/product-processes/#prioritization-framework)), such as forced prioritization items with an SLA/SLO. Meeting SLOs is not an OKR, as [OKRs focus on what's different](_index.md#okrs-are-what-is-different).

   1. Other than core team member responsibilities such as those outlined above, all other major commitments should be prioritized through OKRs and consider team bandwidth.

   1. If a team gets a request for a major effort within the quarter, they can change the OKR.

1. Plan for [OKRs to be ambitious, but achievable](#criteria-for-key-results) within the team capacity that you have for OKRs. While OKRs are meant to be ambitious, [you should aim to complete them](_index.md#how-do-i-prioritize-okrs-in-light-of-other-priorities) and strive to hit the ambitious plan. We recognize that with ambitious planning some OKRs will not be completed, but it is striving and reporting on OKRs with the goal of hitting 100% that helps us accomplish strong results. We score individual OKRs as "on track" when they are at least 80% complete. In aggregate, we expect that the average completion score across OKRs is 70%.

1. It is OK to push back on OKRs. If you can't prioritize a cascading or shared OKR due to more important work, contact the owner of the OKR and make adjustments so that it is achievable without your team's contribution, or remove it. It is OK to do this, with clear communication and collaboration. It is not acceptable to simply ignore the cascading OKR or shared OKR without clear upfront communication and prioritize other work instead.

1. When writing OKRs, focus on outcomes, not tasks, and make key results measurable.

1. For any OKR with a dependency, make sure to get commitment on the dependency with [shared objectives](_index.md#shared-objectives). If you don't get commitment in the shared objective, make changes as needed to keep to feasible OKRs.

## Tips for OKRs that are scoreable

Your KRs should be statements that clearly indicate how you will score. For example, in FY21-Q4, the marketing team set a target of completing 5 experiments. It completed 4 out of the 5, but only one of these appeared to be successful. The marketing team initially saw this as a failure. Instead, it showed notable progress. 80% of experiments were completed. This was the stated KR goal.

We should aspire to set quantitative goals in which scoring is straightforward as a % of attainment (for example, X% of target ARR or logos). In rare instances, quantitative KRs are not possible or appropriate. For example, launching a new compensation program is hard to score without scoring guidelines. Does not launching = 0% attainment and launching = 100% attainment? What about hitting milestones in between? In these cases, note in the issue or epic how you plan to grade the KR at the end of quarter. In our compensation example, this could mean putting together a scoring guide such as this:

| Milestone | Score |

| ------ | ------ |

| Complete compensation analysis | 20% |

| Present plan to E-Group for feedback | 40% |

| Get sign-off from Finance | 60% |

| Complete comp refresh for all team members | 100% |

Please update scores in addition to status in Key Result Meetings.

Watch this video for a demo on how to updated progress in OKR management:

{{< youtube "kHkk-U22DBo" >}}

### Example OKRs

**Objective: Establish GitLab leadership in X area.**

- Avoid ❌ KR1: GitLab X becomes available in beta, including Y functionality in beta, with a path to general availability next quarter.

- Instead ✅ KR1: GitLab X reaches 100k paid MAU by end of quarter.

- Avoid ❌ KR2: Ship 10 components to support the use of X.

- Instead ✅ KR2: 30% of GitLab users are able to use X with the components built.

This aligns with a focus on outcomes and business results instead of KRs tracking tasks or launches.

### External examples

1. [Examples from whatmatters](https://www.whatmatters.com/get-examples).

## OKR resources

- [With Goals, FAST beats SMART](https://sloanreview.mit.edu/article/with-goals-fast-beats-smart/)

- [Measure What Matters by John Doerr](https://www.whatmatters.com)

- [A Modern Guide to Lean OKRs](https://obvious.com/ideas/a-modern-guide-to-lean-okrs-part-i/)

- [John Doerr: Why the secret to success is setting the right goals](https://www.youtube.com/watch?v=L4N1q4RNi9I) (5 min video)

- [David Skok: SaaS Metrics 2.0 – A Guide to Measuring and Improving what Matters](https://www.forentrepreneurs.com/saas-metrics-2/)

- [Benefits of OKRs](https://www.whatmatters.com/faqs/benefits-of-okrs)

- [GitLab - How to write OKRs](/handbook/company/okrs/okrs-basics/#how-to-write-okrs)

- [Ally for OKRs - Overview for Product](https://www.youtube.com/watch?v=hP9yk_PSj2k&feature=youtu.be) (10 min video)

#### Deeper dive