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 that are clearly defined and aligned throughout the organization. The Objectives help us understand what we're aiming to do, and the Key Results help paint the picture of how we'll measure success of the 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 initiates and guides the OKR process.
Watch EVP, Engineering Eric Johnson discuss the power of OKRs from his perspective:
OKRs should be ambitious but achievable. 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.
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 initiatives 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:1's, 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 it's 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 the 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.
OKRs are like Portfolio Management so we are dogfooding those features to track our OKR progress over the course of a quarter. Work happens in GitLab, so we use GitLab to manage tracking the progress of that work. We use epics to track objectives, and issues to track key results. With health statuses, each of the CEO OKRs maps to an epic, and the progress of all cascading OKRs can be seen at-a-glance.
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, 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?
The EBA to the CEO is responsible for scheduling and coordination of 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.
Five Mondays before the start of the fiscal quarter, the CEO and Chief of Staff initiate the OKR process.
Initiating the OKR process is best done in two distinct MRs. The first accomplishes the following:
In a subsequent MR, the CEO proposes one to three Key Results for the quarter for each of those objectives. At least one KR should loosely map to each executive, though this is not explicitly stated. The CEO shares this MR in the #e-group channel in Slack and discusses it in each of his 1:1s with his direct reports in the next week.
The following week, four Mondays before the start of the fiscal quarter, Executives propose OKRs for their functions via epics (for objectives) and issues (for KRs) through a Slack message in #okrs channel. The CEO and Chief of Staff should be at-mentioned. The CEO will confirm sign-off on objectives through commenting directly in them. While the CEO is the DRI, this responsibility may be the delegated to the CoS.
Each executive should aim for a maximum of 3 objectives, however, in Q4 each executive can have a maximum of 4 OKRs because we are preparing for the next year. Each objective has between 1 and 3 key results; if you have less, you list less. While OKRs are known for being ambitious or committed, we only have ambitious OKRs. When drafting the OKRs, executives should strive to target actual numbers versus percentages. In advance of the first day of the new quarter, all percentages should be replaced with actual numbers.
Function epics should cascade from one of the CEO's OKR EPICs.
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 were 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 issues are made, epics and issues should be shared in the #okrs channel in Slack and at-mention the Chief of Staff and CEO. The CEO is responsible for OKR approvals, but may delegate this responsibility to the CoS.
How objectives cascade from CEO KRs in the handbook to functional Objectives and KRs in Epics and Issues:
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 epic or issue 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 Executive OKRs in GitLab (epics and issues) and add them to the relevant CEO OKR Epics.
Notes for Pass-thru KRs: To avoid duplicate issues for the same KR due to the fact that an Issue can only inherit from a single Epic, make the KR issue a child of the Objective epic at the lowest level in the organization structure. The upper level Objective epics all refer to the single KR issue but not in the inheritance hierarchy.
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 do 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. 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.
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. While we no longer have these meetings, plans for achieving KR targets should still be clearly documented within KR issues. An issue should include the following fields:
The Chief of Staff updates the OKR page for the current quarter to be active. CEO OKRs may be included in the next formal or informal Board meeting.
We value iteration. We can change an objective or KR if we find that in our pursuit of the initial KR we have not set the optimal goal. Here are a few examples of when this could happen:
It 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, post an MR in the #okrs Slack channel and tag the CEO and Chief of Staff for approval. Approval of the MR indicates that the revised goal has been agreed upon. At this point, you can also update the issue or epic to reflect changes.
In the event that a functional Objective that is captured in an epic or a functional KR that is capured in an issue needs to be updated, please note the change in the #okrs Slack channel and tag the CEO and Chief of Staff 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 Q4 FY21, we're putting functional objectives and KRs in epics and issues that should link to the CEO KR epics that are linked on the handbook page. We made this change, because the handbook and epics were not being consistently updated, so there often wasn't a single source of truth. We were also struggling with merge conflicts as regular changes were being made to the handbook page.
Functional leaders are responsible for updating the their objectives and KRs in their epics and issues before each Key Review.
Each functional epic should appear under the relevant CEO epic. Naming conventions are captured in the chart below.
This is the format for OKRs added as issues and epics.
1. [EPIC] Title: Objective as a sentence.
In other words, all OKR-related epics should follow the naming convention of "Title: Objective as a sentence". The CEO Epic will include the Fiscal Quarter in it. Cascading epics should not.
Although the steps in this example reference the Development department these steps can be used by any department within GitLab. You may simply need to change the labels associated with the links used in the example below.
For Development we use the Development Department Issue Board to track OKRs, organized by each sub-department. Each group creates their own tracking issue with the description of the issue linking out to Objectives and Key Results. Instructions for creating the tracking issue:
engineering-okr template (link)engineering-okr template can be used by any department, simply remove the ~"Engineering Management" labelThe objectives for the quarter are defined in the OKR section of the handbook. In your Tracking Issue you will need to create an epic for each objective with the proper title formatting. There are currently no templates for these epics. Steps to create an objective epic:
Each Objective will contain one or more Key Result issues. Instructions:
group (e.g. ~group::compliance)Teams should update the Health Status of their KR issues and present them in their Key Review. When presenting the status of OKRs, we use the following terms to denote the status of a key result:
A Key Results issue's 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 issue's parent epic will roll up the health statuses of all relevant issues.
During Key Reviews, teams should include material that covers key OKR progress details and links to relevant epics and issues.
The first Key Review of the following quarter should offer a clear scoring for each KR.
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, launch 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.
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. If commenting on a functional objective or KR, comment directly in the epic or issue.
