Objectives and Key Results (OKRs)

OKRs stands for Objective-Key Results and are our quarterly objectives. OKRs are how to achieve the goal of the Key Performance Indicators KPIs.

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.

What are OKRs?

OKRs stand for Objectives and Key Results and are our quarterly objectives. OKRs are how to achieve the goal of the Key Performance Indicators KPIs. They lay out our plan to execute our strategy and help make sure our 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

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.

Watch EVP, Engineering Eric Johnson discuss the power of OKRs from his perspective:

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.

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
    2. Establish differences between GitLab Inc. and competitors
    3. Be recognized as an industry leader in a category
  2. 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.
  3. 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.
  4. 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.
  5. 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 responsbility.
  6. 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.
  7. 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, 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.
  2. 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.
  3. 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.
  4. Clear, Responsible Party - one single person or team responsible for Key Result.
  5. 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.
  6. Time Bound - has a due date. At GitLab, unless otherwise stated, this is within the quarter.
  7. 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.
  8. 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.
  9. 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.
  10. Few Words and Ubiquitous Language - As defined in Handbook.

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. The “6 Principles of setting OKRs” may also be helpful.

Example OKRs

Product OKR example:

Objective: Drive a meaningful impact on Usability (Bugs, Infradev, Security) in order to avoid losing users due to usability issues. KRs (Key Results):

  • group::threat insights: Meet SLAs for all P1 and P2 bugs affecting usability
  • group::code review: Reduce mean-time-to-close of S1 + S2 bugs by 50%
  • group::editor: Complete 10 usability issues related to our primary categories (Web IDE, Snippets, Wiki)

Samples of well written KRs from GitLab team members:

  1. Q2 product group KR experiment. What makes these great is that they’re succinct in scope and have clear metrics to measure success.

External resources:

  1. Examples from whatmatters.

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).

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.

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.

Who sets OKRs?

Generally, we do OKRs up to the team level. As a company, we don’t do individual OKRs, but some functions may. For example, in the Engineering Division Staff-level (and above) individual contributors have OKRs. However, it is not required of Staff Product Designers at this time. Also, individual contributors in the Engineering Division who are not required to do OKRs are welcome to do them with their manager. It’s a useful way to prepare for a managerial career or to align one’s activities with the broader goals of the company.

An individual might also have OKRs if they represent a unique team. For example, individual SDRs don’t have OKRs, but the SDR team does. If Legal is one person but represents a unique function, Legal has OKRs. Part of the individual performance review is the answer to: how much did this person contribute to the team objectives?

Alignment

OKRs are our quarterly priorities that create progress for 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. However, since the yearlies are aligned to one of the strategic pillars, OKRs are indirectly aligned to one of the strategic pillars.

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.

OKR Process at GitLab

The EBA to the CEO is responsible for scheduling and coordinating the OKRs process detailed below. Scheduling should be completed at least 30 days in advance of the beginning of the OKR process, which begins 5 weeks before the start of the fiscal quarter.

Should you need to reschedule, please @ mention the EBA to the CEO in the #eba-team slack channel.

CEO initiates new quarter’s OKRs

Six Mondays before the start of the fiscal quarter, the CEO and Chief of Staff (CoS) to the CEO initiate the OKR process.

The CoS to the CEO creates a Google Doc for E-Group alignment and shares initial suggestions with the CEO. The CEO and CoS to the CEO discuss and modify these initial suggestions. This document is shared with E-Group in the E-Group Weekly which is five weeks before the start of the coming quarter. E-Group is encouraged to offer feedback in the E-Group Weekly, directly within the Google Doc, or in meetings with the CEO or CoST.

Four Mondays before the start of the quarter, the CoS to the CEO will share the company OKRs draft with E-Group.

Company OKRs may continue to be refined in the lead up to the coming quarter.

Executives propose OKRs for their functions

Four Mondays before the start of the fiscal quarter, in the days after the CEO shares OKRs with all of GitLab in the #okr channel, Executives propose OKRs for their functions in the OKR draft review meeting agenda. 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.

Each executive should aim for a maximum of 5 objectives. Each objective has between 0 and 3 key results. While OKRs are known for being ambitious or committed, we only have ambitious OKRs. When drafting the OKRs, executives should strive to have clear numerical targets. Teams within a function can have zero objectives and key results.

Function objectives should cascade from one of the CEO’s OKRs in GitLab.

Executives should consider how their OKR efforts can have the greatest impact on the organization. Functions can have objectives under any of the three company OKRs. For example, the People Team could have an objective under the CEO’s Net ARR OKR if it identified that a specific enablement activity was key to driving sales or the Sales Team could have an objective under the CEO’s Great Teams OKR if it were focused on improving team diversity. Functions should not be pigeonholed into the company OKR that appears to be most directly related to the function.

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 Chief of Staff 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.

OKR Draft Review Meeting

In the week that begins three Mondays before the start of the fiscal quarter, there is an OKR Draft Review Meeting for the e-group. This meeting is an opportunity for executives to get feedback from one another and highlight any dependencies on other functions to one another. The agenda for this meeting is structured as follows:

  1. Function
    1. Link to the objective in GitLab
    2. Dependencies: call out any dependencies

If additional action needs to be taken by the functional leader, the GitLab link should be re-shared in the #okrs channel in Slack when it’s ready for final review.

Cascade!

Now that 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 to their team.

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

Through the quarter, regular updates by the relevant DRI for Company KRs are expected ahead of E-group monthly touchpoint meetings. Exact dates for when updates are due are shared in the #okrs Slack channel with reminders set 7 days and 1 day before the due date.

Dependency Commitments

Top level dependencies should be identified in the OKR Draft Review Meeting, but it is likely that additional dependencies will 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

In FY21, we had quarterly How to Achieve Meetings in which senior team members shared their plans for achieving KRs. These meetings were often short and inefficient as much of the content could be covered during the planning process and reviewed async. We now have shorter OKR Review Meetings (50 minutes). In these E-Groups, team members should share their drafts in the agenda linked in the calendar invites. As functional OKRs are finalized, they should be entered in GitLab and the links should be shared in the #okrs channel (tag the CoS to the CEO and CEO for approval).

GitLab entries should include the following fields:

  1. Overview: some additional background on what we are trying to accomplish and why it is important. This section should elaborate on KRs that are not fully descriptive and provide context for team members who might not otherwise understand the desired result.
  2. DRI or Core Team: document the DRI. Other key team members and their roles can also be captured in this section.
  3. Action Items: a list of 3-10 key action items for achieving the target. You can consider using checkboxes or a chart to help communicate progress.
  4. Scoring: your KR should be a statement that clearly indicates how you will score final achievement at the end of quarter. If it is, this section is not needed. When how the KR will be scored isn’t immediately clear from the KR itself, details on how scoring will work should be documented according to scoring guidelines.

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 CoST for 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 @ mentioned e-group. .

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:

  1. It becomes clear that the performance indicator does not provide the best measure for success
  2. A KR statement exists, but the target is a placeholder. For example, “Obtain $XM in bookings in Q1”
  3. A KR is related to achievement of a new initative, 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 each Key Review.

How to Use GitLab for OKRs

Watch this video for a demo on how to use GitLab for OKR management:

Creating Objectives

The objectives for the quarter are defined in the OKR section of the handbook. To add new objectives in GitLab, follow the steps below:

  1. In the GitLab OKRs project, navigate to OKRs by selecting Issues on the left sidebar.
  2. In the top right corner of the Issues screen, select the down arrow next to New issue in the top right corner and then select New objective from the menu. Next, select the New objective button to create an Objective.
  3. Enter a short but descriptive title for the objective then click Create objective.
    1. When referring to a division, use the division name, not the e-group leader’s position. For example, use “Marketing OKRs” (not “CMO OKRs”).
  4. Select the objective from the list to open in an editable view and add more details:
    1. Identify the owner for the objective and assign them.
      1. Ensure that only one DRI is assigned to the objective. If there is a case of multi-ownership, it’s likely that the OKR/KR can be simplified or broken down further.
    2. Identify the quarter for the objective and set the corresponding milestone.
    3. Add labels so objective is searchable/filterable:
      1. Add OKR label.
      2. Add division label to assign to the relevant division (i.e. Sales, Product, etc).
        1. Company OKRs are designated with a division::CEO scoped label.
      3. Only Product & Engineering cascade OKRs below division level, so for Product & Engineering OKRs, in addition to division labels, follow stage labels to add the Section/Stage/Group scoped labels to assign the OKR to the relevant parts of Product Hierarchy.
      4. Each part of hierarchy should have a label. For example, an OKR for a group would have a division label, a section label, a stage label, and a group label.
  5. Review the objective against the SAFE Framework to ensure it is information that can be shared. Review to ensure that the objective should not be limited access. If the information is limited access, use code name if relevant or link to a supporting issue that is limited access.

Creating Key Results

Each Objective will contain one or more sub-objectives or key results. Sub-objectives are only used to cascade OKR down a level in organizational structure while Key Results are the measure which helps us understand if we’ve met our objective and can be cascaded down a level of organization structure to become an objective one level down. Key Results must be created as part of an Objective and cannot be created independent of an Objective since Key Results should be linked to an Objective.

Since Key Results are the measure that helps us understand if we’ve met our Objective, Key Results are aligned to the same, single layer of the organizational structure as their parent Objective and not a Key Result for multiple layers of organizational structure. However, Key Results can be cascaded down from this single organizational structure layer by becoming Objectives in the next organizational level down - see Cascading OKRs.

To add new key results in GitLab, follow the steps below:

  1. Navigate to the the objective that you want to add a child key result to by opening the GitLab OKRs project, selecting Issues on the left sidebar, then clicking on the target objective.
  2. Add new key result by clicking Add in the Child objectives and key results section of an objective and then select New key result. Use the SAFE framework to determine whether it needs to have limited access.
  3. Enter a short but descriptive title for the key result then click Create key result.
    1. When referring to a division, use the division name, not the e-group leader’s position. For example, use “Marketing KR” (not “CMO KR”).
  4. Select the key result from the list in the Child objectives and key results section to open in an editable view and add more details:
    1. Identify the owner for the key result and assign them.
      1. Ensure that only one DRI is assigned to the KR. If there is a case of multi-ownership, it’s likely that the OKR/KR can be simplified or broken down further.
    2. Identify the quarter for the key result and set the start date as the first date of that quarter and set the due date to the last day of that quarter.
    3. Add labels so that KR is searchable/filterable:
      1. Add OKR label.
      2. Add division label to assign to the relevant division (i.e. Sales, Product, etc). Company OKRs are designated with a division::CEO scoped label.
      3. Only Product & Engineering cascade OKRs below division level. For Product & Engineering OKRs, in addition to division labels, follow stage labels to add the Section/Stage/Group scoped labels to assign the OKR to the relevant parts of Product Hierarchy.
      4. Each part of hierarchy should have a label. For example, an OKR for a group would have a division label, a section label, a stage label, and a group label.
  5. Review the key result against the SAFE Framework to ensure it is information that can be shared. Review to ensure that information should not be limited access. If the information is limited access, use code name if relevant or link to a supporting issue that is limited access.
  6. Optionally, turn on check-in reminders.
  7. The key result now appears in the Child objectives and key results section of the corresponding parent objective.

Watch this video for a demo on how to create objectives and key results:

Cascading OKRs and how to Align Division OKRs to the company OKRs

Cascading is the process by which top-level company OKRs cascade down from company-level to division, department, team, and sometimes individual level. The OKRs that are directly aligned with Company KRs should be tied to the Company KRs in such a way as to allow scoring.

At GitLab, we typically create OKRs at each level where some OKRs align with the levels above, but not all.

Based on the current methodology and feature set in the product, there are two ways to align OKRs to company OKRs:

  1. Add relevant OKRs as related items. Most of the time, this is what teams use.
  2. Have all relevant OKRs as children of a Company KR.

The second method should be used only if all relevant OKRs can be added as children, because Progress is automatically scored based on the children if any exist.

In the future, when manual scoring is available, a mix of the two methods can be used for a single KR.

If an OKR is related, but does not score towards the Company KR, edit the description to add a note.

Creating company OKRs

To allow for division, department, or team objectives to be added as child objectives or KRs, the Company key results should be created as an objective, not as a key result, as GitLab functionality doesn’t allow for a KR to have child OKRs.

The Chief of Staff Team to the CEO does the following:

  1. Create the Company objective.
  2. Create the Company key results as child objectives of the Company objective.

Once company OKRs are created, other divisions and departments following one of the two methods for team OKRs that score towards company OKRs.

Typically at GitLab, divisions create OKRs to automatically have progress score towards division objectives. To indicate that a division KR should also show progress of a Company KR, add the division KR as a related item of the Company KR following these instructions:

  1. Click on the relevant Company KR to add related items.
  2. Click Add in the Linked items section.
  3. Click inside of the following item(s) text field.
  4. Find (enter text to filter) and select 1 or more objective(s) or KR(s) that should score to the Company KR.
  5. Click Add to add the selected OKR(s).

Do this for all OKRs that contribute to company OKRs. However, be careful not to link an OKR to multiple Company KRs.

When this method is used, the Chief of Staff Team to the CEO will update the score manually based on the scoring of all related items.

A hypothetical example where division KRs score directly to division objectives, and should also progress a Company KR:

  1. Company Objective: Retain and grow top talent – automatically scores from KRs including KR1
    1. KR 1: Have 10% of managers enrolled in leadership program – manually scored based on related items
      1. Related: Sales OKR: Have 10% of managers enrolled in leadership program – child of and automatically scores to CRO Objective
      2. Related: Marketing OKR: Have 10% of managers enrolled in leadership program – child of and automatically scores to CMO Objective
Method 2: Add all OKRs as children of Company KR

This method should only be used if all OKRs that will score towards the Company KR can be children of the KR, because the Company KR progress is automatically scored based on its children. The hierarchy looks similar to this:

  1. Company objective
    1. Company KR (a GitLab objective)
      1. Division objective
        1. Division KR
        2. Division KR

To add the division OKRs as children of the relevant Company KR:

  1. Click on the Company KR you want to be the new parent for an objective/key result.
  2. Click Add in the Child objectives and key results section of the Company KR.
  3. Create team objective or KR as a child objective of the relevant Company KR (Company KR will be a GitLab objective).
  4. If the team objectives or KRs already exist, find the objective or key result for alignment by typing the name of the OKR in the search bar that appears in the Child objectives and key results section. See documentation to add a child objective.
  5. If applicable, add the team key results as children inside of the team objective.
  6. Ensure they have an assignee, labels, etc. following guidelines on Creating Key Results.

A hypothetical example where division OKRs score directly to a company OKR:

  1. Company Objective: Retain and grow top talent – automatically scores from KRs including KR1
    1. KR 1: Have 10% of managers enrolled in leadership program – automatically scores from child OKRs
      1. CRO OKR: Have 10% of managers enrolled in leadership program
      2. CMO OKR: Have 10% of managers enrolled in leadership program
      3. etc. (all divisions participating should be added)

Note: Using this method, if you need to track the team objective or KRs separately, you can take a look at Engineering’s guidance on tracking department OKRs. If you need the team objective or KRs to score to another parent objective, duplicating the OKR is currently the only way to do so.

Search and Filter OKRs

  1. You can use the List view to filter by the assignee or by your team using labels. For example:
    1. This view shows all engineering division OKRs. Division::engineering label can be swapped out for any other division/stage/section/group scoped label.
    2. This view shows all OKRs assigned to @sytses
  2. You can bookmark or share the URL for future reference.

Watch this video for a demo on how to find the OKRs you’re looking for:

Maintaining the status of OKRs

Teams should update score for their key results in GitLab within the first five business days of every month and present the most recent update in the Key Review that immediately follows the update. 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. 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.

During Key Reviews, teams should include material that covers key OKR progress details and links to relevant OKRs.

The first Key Review of the following quarter should offer a clear scoring for each KR.

Company OKR progress will be shared in the first week of the month in the following slack channels: #ceo; #okrs; #e-group; #whats-happening-at-gitlab.

Scoring OKRs

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%

Tips for goals that are scorable

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:

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.

OKR resources:

OKR Archive


Calendar Year 2017 Q3 OKRs
View GitLabs Objective-Key Results for quarter 3 2017. Learn more here!
Calendar Year 2017 Q4 OKRs
View GitLabs Objective-Key Results for quarter 4 2017. Learn more here!
Calendar Year 2018 Q1 OKRs
View GitLabs Objective-Key Results for quarter 1 2018. Learn more here!
Calendar Year 2018 Q2 OKRs
View GitLabs Objective-Key Results for quarter 2 2018. Learn more here!
Calendar Year 2018 Q3 OKRs
View GitLabs Objective-Key Results for quarter 3 2018. Learn more here!
Calendar Year 2018 Q4 OKRs
View GitLabs Objective-Key Results for quarter 4 2018. Learn more here!
FY20-Q1 OKRs
View GitLabs Objective-Key Results for FY20 Q1. Learn more here!
FY20-Q2 OKRs
View GitLabs Objective-Key Results for FY20 Q2. Learn more here!
FY20-Q3 OKRs
View GitLabs Objective-Key Results for FY20 Q3. Learn more here!
FY20-Q4 OKRs
View GitLabs Objective-Key Results for FY20 Q4. Learn more here!
FY21-Q1 OKRs
View GitLabs Objective-Key Results for FY21 Q1. Learn more here!
FY21-Q2 OKRs
View GitLabs Objective-Key Results for FY21 Q2. Learn more here!
FY21-Q3 OKRs
View GitLabs Objective-Key Results for FY21 Q3. Learn more here!
FY21-Q4 OKRs
View GitLabs Objective-Key Results for FY21 Q4. Learn more here!
FY22-Q1 OKRs
View GitLabs Objective-Key Results for FY22 Q1. Learn more here!
FY22-Q2 OKRs
View GitLabs Objective-Key Results for FY22 Q2. Learn more here!
FY22-Q3 OKRs
View GitLabs Objective-Key Results for FY22 Q3. Learn more here!
FY22-Q4 OKRs
View GitLabs Objective-Key Results for FY22 Q4. Learn more here!
FY23-Q1 OKRs
View GitLabs Objective-Key Results for FY23 Q1. Learn more here!
FY23-Q2 OKRs
View GitLabs Objective-Key Results for FY23 Q2. Learn more here!
FY23-Q3 OKRs
View GitLabs Objective-Key Results for FY23 Q3. Learn more here!
FY23-Q4 OKRs
View GitLabs Objective-Key Results for FY23 Q4. Learn more here!
FY24-Q1 OKRs
View GitLabs Objective-Key Results for FY24 Q1. Learn more here!
FY24-Q2 OKRs
View GitLabs Objective-Key Results for FY24 Q2. Learn more here!
FY24-Q3 OKRs
View GitLabs Objective-Key Results for FY24 Q3. Learn more here!
FY24-Q4 OKRs
View GitLabs Objective-Key Results for FY24 Q4. Learn more here!
FY25-Q1 OKRs
View GitLabs Objective-Key Results for FY25 Q1. Learn more here!
FY25-Q2 OKRs
View GitLabs Objective-Key Results for FY25 Q2. Learn more here!
Last modified February 21, 2024: Add division naming guidance (272a20a7)