All our OKRs are public and listed on the pages below.
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:
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:
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.
Objectives should be:
Key Results should be:
You can score your OKRs against these criteria to determine whether your OKRs are effective.
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.
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.
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):
Samples of well written KRs from GitLab team members:
External resources:
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.
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).
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.
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.
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.
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. They are expected to be completed 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.
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?
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.
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.
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.
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.
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 3 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.
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:
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.
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.
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.
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:
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. .
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:
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.
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.
Watch this video for a demo on how to use GitLab for OKR management:
The objectives for the quarter are defined in the OKR section of the handbook. To add new objectives in GitLab, follow the steps below:
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.OKR label.Turn on confidentiality.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:
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.OKR label.division::CEO scoped label.Turn on confidentiality.Watch this video for a demo on how to create objectives and key results:
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:
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 net new Key Results for the new Objective at team's level of organizational structure.
Once division OKRs have been added to GitLab, they can then be aligned to relevant CEO OKRs. Division OKRs should align to a CEO objective when it contributes to the progress of that objective. If a division level OKR does not contribute to progress of CEO objective but is still related, crosslink the CEO OKR and division OKR in the description of each OKR for visibility.
Follow the steps below to align division OKRs to the CEO Objectives:
When a division level OKR is the child of a CEO Key Result, follow the explicit alignment process.
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.
Steps when a CEO KR is a “parent” of a division Objective:
Now progress for the CEO KR will be measured in the division’s parent objective and ladder up the CEO objective.
Watch this video for a demo on how to find the OKRs you're looking for:
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:
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.
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 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.