General guidance to OKRs

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.
2. How to enter and organize OKRs in GitLab, on the OKRs in GitLab page.

Overview

OKRs are quarterly objectives that can help achieve KPIs.

We do not use it to give performance feedback or as a compensation review 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. 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.

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.
2. 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.
3. 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 across KRs. We score individual KRs to note our achievement against our stated goal. This is the scoring framework.

See also Tips for OKRs that are scoreable.

View page source - Edit this page - please contribute.