Approach to OKRs at GitLab

An overview of how OKRs are done at GitLab.

This page generally covers OKRs at GitLab, including:

There is additional information on:

What OKRs are, and general guidance on how to forumlate them, on the general OKRs page.
How to enter and organize OKRs in GitLab, on the OKRs in GitLab page.

Overview

OKRs are quarterly objectives that help us achieve our KPIs, and yearlies.

We do not use it to give performance feedback or as a compensation review for team members.

The E-Group does use it for their Performance Enablement Reviews.

The Chief of Staff to the CEO initiates and guides the OKR process.

Most recent OKRs

Our OKR process and timelines are public and listed on the pages below.

OKRs are internal-only in line with guidance from the SAFE framework.

Company and function-level OKR expectations

Company-level Yearlies guide company-level Objectives and Key Results though company-level goals are revisited and set on a quarterly basis. At a minimum, each Function should inherit the company-level Objectives for their function-level Objectives and have 1-3 function level Key Results that supports company Objective and KR attainment each quarter.

Individual functions and teams have discretion around how much they use OKRs beyond the Yearly cascade level.

Cadence

OKRs are part of our company cadence.

Since OKRs create progress for our Yearlies, by achieving our quarterly priorities, we create progress for the rest of the items on the cadence page. By achieving our yearlies, we create progress to achieving our strategy. Achieving our strategy is key to realizing our vision, mission, and eventually purpose. In this way, OKRs are quarterly building blocks that create progress toward longer term goals.

Alignment

OKRs are our quarterly priorities that create progress toward our Yearlies, which are our annual company goals. Since OKRs create progress for yearlies, OKRs are aligned to one of the yearlies.

OKRs are directly aligned to yearlies and not directly aligned to one of the three pillars of the three year strategy.

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. 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 and directly responsible individual (DRI).

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 concept of Managerial Leverage outlined in his book High Output Management. 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. If your executive leader still feels that the OKR is more important, they will ask you to disagree and commit.

OKR Process at GitLab

The CoS to the CEO is coordinating the OKRs process detailed below. The EBA to the CEO assists in scheduling designated time during E-Group Weekly Meetings.

CEO initiates new quarter’s OKRs

In the first month of the fiscal quarter, the Chief of Staff (CoS) to the CEO initiates the OKR process. The CoS works with the CEO will propose big themes and priorities for next quarter. Yearlies are consulted in the drafting process. The CoS to the CEO creates a Google Doc for E-Group alignment. This document is shared with E-Group in an E-Group Weekly. E-Group is encouraged to offer feedback in the E-Group Weekly, directly within the Google Doc, or in meetings with the CEO or Office of the CEO.

In the second month of the fiscal quarter, E-Group will align on big themes and priorities. Before the end of the second month and before team planning is deeply underway, E-Group will lock in a single set of company-wide OKRs. After E-Group alignment, Company-level OKRs will then be shared with all of GitLab in the #okrs channel.

Executives propose OKRs for their functions

Function objectives should cascade from one of the Company OKRs in GitLab.

3-4 weeks before the start of the fiscal quarter, E-Group firms up KRs. 2-3 weeks before the start of the fiscal quarter, during a designated block of time in an E-Group Weekly, Executives propose OKRs for their functions. At a minimum, they should have 2-3 function KRs that cascade from each company-level objective. They may choose to have more OKRs for function management purposes and have discretion to what degree other goals are highlighted in this forum.

After this meeting, as OKRS are finalized, functional OKRs should be posted in GitLab. This should be noted through a Slack message in the #okrs channel. The CEO and Chief of Staff to the CEO should be @ mentioned. The CEO will confirm sign-off on objectives by commenting directly on them. While the CEO is the DRI, this responsibility may be delegated to the CoS to the CEO. The CoS to the CEO will also post company OKRs in GitLab.

The exact timeline for the upcoming quarter will be available in the handbook.

When ready for review or when changes to objectives or KRs are made, relevant objectives and KR links from GitLab should be shared in the #okrs channel in Slack and at-mention the CoS to the CEO, and CEO. The CEO is responsible for OKR approvals, but may delegate this responsibility to the CoS to the CEO.

See How to Use GitLab for OKRs for how to create and align OKRs to company OKRs using GitLab.

Cascade

Once Executive (function-level) OKRs are set (as set as things are at GitLab; everything is always in Draft!), Executives shift their focus to finalizing OKRs within their team.

This is also the opportunity to, if desired, create team OKRs in GitLab, and add them to the relevant CEO and executive OKR.

In advance of designated E-Group Weeklies, the relevant DRI for Company KRs are expected to provide updates.

Dependency Commitments

Top level dependencies should be identified in the draft review session that happens in the E-Group Weekly. Additional dependencies may be identified as OKRs cascade. We want to avoid situations where big asks are coming weeks into the quarter, or teams are being committed to doing work without first having input. This makes it difficult for teams to manage their own priorities and succeed in their own initiatives.

It is each team’s responsibility to proactively identify dependencies in which the team cannot reach success without meaningful engagement from another team. In these instances, it is important that all teams required to make a significant contribution sign off on the KR and agree on the level of support to be provided. A boring solution is to create a sister KR for other departments that will need to be actively involved and link the KRs using the dependency function. KRs with dependencies should not be considered final until other teams have confirmed support, but other teams should also respect department KRs as the top priorities for the overall business and do what they can to support them.

Documenting How to Achieve

A dedicated session during an E-Group Weekly is the key the forum for introducing new function OKRs. During the draft review meeting, each function should share:

KRs that related to company-OKRs, including:
1. CEO OKR that cascade from
2. Any risks or dependencies
(Optional) Functional level-OKRs that don’t directly cascade from company OKRs if they require cross-functional support to achieve or important for cross-functional awareness.

The quarter begins

The Chief of Staff to the CEO takes company OKRs and updates the OKR handbook page for the current quarter to be active. Each objective and KR should include the related GitLab link. The Office of the CEO should also create the handbook page for the following quarter and document the OKR process timeline.

The CoS to the CEO shares the handbook update MR in the #okr channel in Slack and notifies E-Group in an E-Group Weekly.

Reviewing progress within and after the quarter

We will review company-level OKR progress once a month in an E-Group Weekly. Updates should include:

Key Result
Link to OKRs in GitLab
DRI
Completion score
Update summary
Learnings
Remaining dependencies to achievement
Next steps, if incomplete

This is also a time to discuss function KPIs and functional level OKRs that E-Group feel should be highlighted with the broader team.

Two weeks after the end of the quarter, we’ll have an E-Group Weekly session that reviews company-level OKR and key metrics progress from the previous quarter.

Making changes within quarter

We value iteration. We can change an objective or KR if we find that in our pursuit of the initial KR we have not set the optimal goal. Here are a few examples of when this could happen:

It becomes clear that the performance indicator does not provide the best measure for success
A KR statement exists, but the target is a placeholder. For example, “Obtain $XM in bookings in Q1”
A KR is related to achievement of a new initiative, and it is agreed that we should pivot in terms of scope or focus as we learn more about what we want to achieve

Please note that iteration does not mean changing or lowering goal posts, because it looks like we can’t meet what were ambitious but agreed upon key results.

It is better to update an objective or KR than continue to work toward a goal that is not best aligned with desired business results. In instances where Company KRs are being updated in the spirit of iteration, flag the GitLab change in the #okrs Slack channel and tag the CEO and Chief of Staff to the CEO and the CEO for approval. Approval of the change indicates that the revised goal has been agreed upon. At this point, you can also update any associated issues and epics that exist.

In the event that a functional objective that is captured in GitLab needs to be updated, please note the change in the #okrs Slack channel and tag the CEO and Chief of Staff to the CEO for approval. Approval of the change indicates that the revised goal has been agreed upon.

Format of OKR on the Handbook Page

Top level Company KRs will appear in the handbook. OKRs have numbers attached to them for ease of reference, not for ranking. In order to maintain a single source of truth (SSoT), starting in FY24-Q1, we’re putting functional objectives and KRs in GitLab and linking this to the handbook page. It also provides a SSoT for OKRs.

Functional leaders are responsible for updating their objectives and KRs in GitLab before review meetings.

Maintaining the status of OKRs

Teams should update the score for their key results in GitLab regularly. Company-level KRs should to be updated in the first week of a new month. They will be reviewed in the following E-Group Weekly meeting. If a key result is off track, it should be clear why. The owner should leave a comment with the most recent Health Status or there should be a link to an issue, an epic, or another source for details.

**If a function level OKR is meaningfully off track, it is the Exec Sponsor and DRI’s joint obligation to proactively flag the issue. This may mean raising it outside of an E-Group Weekly.

Health Status

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

On track - the DRI is confident the key result will be achieved.
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.
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.

Company OKR progress that does not involve MPNI can be viewed in the GitLab OKR project with the ~“Company OKR” label.

Scoring OKRs

OKRs and their scoring align with fiscal quarters.

Since we set OKRs that are aspirational, we don’t expect 100% achievement 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%

Everyone can contribute

Everyone is welcome to a suggestion to improve any OKR. To update please make a merge request and post a link to the MR in the #okrs channel in Slack and at-mention the Chief of Staff to the CEO. If commenting on a functional objective or KR, comment directly on the OKR in GitLab.

View page source - Edit this page - please contribute.