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:
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 acheive 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 acheived the result so there is no perception of "taking credit" for others' work.
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. The CEO has three objectives every quarter that map to our strategy sequence:
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 IACV 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.
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.
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 Meeting.
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 pics.
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-okrtemplate can be used by any department, simply remove the ~"Engineering Management" label
The 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:
Teams should update the Health Status of their KR issues and present them in their Key Meeting. 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 meetings, team's should include OKR slides that share status details and link to relevant epics and issues.
The final Key Meeting of the quarter should offer a clear scoring for each KR.
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.