Objectives and Key Results (OKRs)

Most recent OKRs

All our OKRs are public and listed on the pages below.

• FY24-Q3 Active
• FY24-Q4 Future
• Previous OKRs

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 KR, it may have not been 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 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 CEO OKRs draft with E-Group.

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

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 CEO 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 CEO 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 CEO 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, 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. If objective contains confidential information, the objective can be set to confidential by checking the box that states This objective is confidential and should only be visible to team members with at least Reporter access below where you entered the title of the objective. Use the SAFE framework to determine whether it needs to be confidential.
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. CEO 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.
   1. If objective contains confidential information, but objective has already been created, the objective can still be set to confidential by clicking the menu in the top right and selecting Turn on confidentiality.
6. 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 be confidential.
3. Enter a short but descriptive title for the key result then click Create key result
   1. If key result contains confidential information, the key result can be set to confidential by checking the box that states This key result is confidential and should only be visible to team members with at least Reporter access below where you entered the title of the key result.
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). CEO 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.
   1. If KR contains confidential information, but KR has already been created, the KR can still be set to confidential by clicking the menu in the top right and selecting Turn on confidentiality.
6. 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.
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 CEO OKRs

Cascading is the process by which top-level CEO OKRs cascade down from company-level to division, department, teams, and sometimes individual level. There are two methods to cascade:

1. Explicit Alignment - adopt a higher-level Key Result as an Objective.
2. Directional Alignment - Using objective from higher level of the organization in order to guide creation of your team’s objective(s), then cross-linking your team’s objective to the higher-level objective.

Through these two cascade methods, a lower level team can either inherit or create an Objective. However, in both cases, the lower level team creates Key Results for the new Objective at team’s level of organizational structure.

The following works for cascading any multi-level OKRs, not just CEO OKRs. CEO key results cascade down to relevant areas of the company in two ways:

1. CEO KR converted to a division or team-level objective with more specific child key results.
2. A portion or all of a CEO KR can be adopted as a KR at the division or team level if it’s specific to that area of the company.

Explicit Alignment

Although KRs are not meant to have children, the concept of Explicit Alignment means a Key Result of a higher level can be inherited as an Objective at a lower level.

In order to align division or team objectives to a CEO KR and have progress flow up to CEO KR automatically, the CEO 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 hierarchy will look like this:

1. CEO objective
   1. CEO KR (also an objective)
      1. team objective
         1. team KR

If input in this format, progress entered for team KRs will flow up to update CEO OKRs automatically.

As an example, a CEO objective in FY23-Q4 was to “Grow Careers” with KRs managed by the Workplace, Learning & Development, and DIB teams. So, the CEO KRs were the objectives for those respective teams. As they updated progress on their objectives, the results were measured on the CEO level as KRs, and combined to create progress and health status reports for the objective as a whole.

To ensure accurate reporting in a cascading OKR, the Chief of Staff Team to the CEO does the following:

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

Once CEO OKRs are created, other divisions and departments do the following for team OKRs that are aligned to CEO OKRs:

1. Click on the CEO 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 CEO KR.
3. Create team objectives or KRs as child objectives of the relevant CEO key result (CEO key result will be an objective in GitLab).
4. If the team objectives or KRs already exist, find the objective or key result for alignment by typing 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 your group key results embedded as children inside of the team objective.
6. Add DRIs as Assignees on each KR, and the group leader or department head as the Assignee of the team objective.

Until OKR work items can score to multiple parents, the team objective (that is a child of the CEO KR) may include key results that do not directly align to the CEO KR. If a team objective has multiple key results that align with multiple CEO KRs, make the team objective a child of the CEO objective instead.

A hypothetical example with various ways division OKRs can be children of the CEO OKRs:

CEO Objective: Retain and grow top talent

1. KR 1: Have 10% of managers enrolled in leadership program
   1. CRO Objective: Retain and grow top talent – Note that the KR 1 is directly aligned with CEO KR1 but the KRs are not aligned with CEO KR2 or KR3
      1. KR 1: Have 10% of managers enrolled in leadership program
      2. KR 2: Have 90% of managers complete neurodiversity training
   2. CMO KR 2: Have 10% of managers enrolled in leadership program; part of “CMO Objective: Retain and grow top talent” – may be duplicated for division to score separately
2. KR 2: Increase URG from 17% to 18%
3. KR 3: Increase female population from 31% to 33%
4. CTO Objective: Retain and grow top talent – multiple KRs here align with multiple CEO KRs, so is a child of CEO objective
   1. KR 1: Have 10% of managers enrolled in leadership program
   2. KR 2: Increase female population from 31% to 33%

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. Please ensure the OKR tied to the CEO KR is the single source of truth if you duplicate.

Directional Alignment

Division OKRs should align to a CEO KR when it contributes to the progress of that objective. If a division level OKR does not contribute to progress of a CEO KR but is still related, crosslink the CEO OKR and division OKR in the description of each OKR for visibility.

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.

CEO 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

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:

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:

• With Goals, FAST beats SMART
• Measure What Matters by John Doerr
• A Modern Guide to Lean OKRs

OKR Archive

• FY24-Q2
• FY24-Q1
• FY23-Q4
• FY23-Q3
• FY23-Q2
• FY23-Q1
• FY22-Q4
• FY22-Q3
• FY22-Q2
• FY22-Q1
• FY21-Q4
• FY21-Q3
• FY21-Q2
• FY21-Q1
• FY20-Q4
• FY20-Q3
• FY20-Q2
• FY20-Q1
• CY18-Q4
• CY18-Q3
• CY18-Q2
• CY18-Q1
• CY17-Q4
• CY17-Q3