Objectives and Key Results (OKRs) | GitLab
- You are here:
- About GitLab
- Objectives and Key Results (OKRs)
Maintained by:
On this page
Most recent OKRs
All our OKRs are public and listed on the pages below.
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 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:
- 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 initiates and guides the OKR process.
Watch EVP, Engineering Eric Johnson discuss the power of OKRs from his perspective:
OKRs are stretch goals by default
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.
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 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.
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: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.
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 it’s 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 the 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 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.
Dogfood portfolio management’s strategic planning capabilities
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.
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, 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?
OKR Process at GitLab
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.
CEO initiates new quarter’s OKRs
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. While we focus on driving revenue, product enhancement and team objectives, many objectives will also support our strategy:
- Grow net ARR
- Popular next generation product
- Highly performant team
Initiating the OKR process is best done in two distinct MRs. The first accomplishes the following:
- create that quarter’s page in the handbook
- set the CEO’s objectives as H2 tags on the page
- skeleton the other parts of the OKR page
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.
Executives propose OKRs for their functions
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:
OKR Draft Review Meeting
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:
- Function
- Epic: link to the objective
- Dependencies: call out any dependencies
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.
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 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.
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 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 quarter begins
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.
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:
- It becomes clear that the performance indicator does not provide the best measure for success
- A KR statement exists, but the target is a placeholder. For example, “Obtain $XM in bookings in Q1”
- A KR is related to achievement of a new inititiave, and it is agreed that we should pivot in terms of scope or focus as we learn more about what we want to achieve
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.
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 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.
Format of Objectives and Key Results in Epics and Issues
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.
- [ISSUE] Title KR: Key result
- [ISSUE] Title KR: Key result
- [ISSUE] Title KR: Key result
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.
Example: Development’s approach to OKRs
Detailed instructions with links to templates
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.
The Tracking Issue
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 and . Instructions for creating the tracking issue:
- Create a tracking issue using the
engineering-okrtemplate (link) - Note: The
engineering-okrtemplate can be used by any department, simply remove the ~”Engineering Management” label - Note: you will need to add your own department (e.g. ~Development) and sub-deparment label (e.g. ~”Enablement Sub-department” )
- Update the title to the following format: FYYY-Q# Group Name OKRs (e.g. FY21-Q2 Growth Sub-department OKRs)
- As you create and following the instructions below, be sure to update the body of this tracking issue with the titles and links.
Objectives
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:
- Create an epic for each objective that you wish to create a key result
- Format the epic title to match the company OKR title
- Optional – add labels for your group or sub-department or department
- Add the newly created epic to your manager’s objective in the same category (e.g. Product, Team, Net ARR). This is so that all objective roll up to the CEO objective of the same category and everyone can see a cascading view of objectives
- Update the with the title and link of this newly created objective
Key Results
Each will contain one or more Key Result issues. Instructions:
- Create a new issue
- The title format is FYYY-QQ Group Name KR: Text (e.g. FY21-Q3 Protect Group KR: Protect our Code!)
- Add the following labels: ~OKR ~”Engineering Management” and the label for your department (e.g. ~”Development Department” and sub-department (e.g. ~”Dev Sub-department” )
- Add labels for your
group(e.g. ~group::compliance) - Assign to yourself (or appropriate person)
- Link to the appropriate Objective Epic
- Add the newly created Key Result , under the correct listing, in the
Maintaining the status of OKRs
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:
- On track – the DRI is confident the key result will be achieved.
- 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.
- 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.
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.
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, 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:
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 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. If commenting on a functional objective or KR, comment directly in the epic or issue.