Overview of Objectives and Key Results (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 Yearlies, which in turn support our strategy, and help make sure our top 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

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.

When planning OKRs, be sure to consider OKRs at GitLab.

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 responsibility.
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 KRs, you may be stretching beyond what is 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.

Teams should limit the number of OKRs they commit to so they have reasonable bandwidth to deliver. When planning OKRs:

1. Consider non-OKR commitments. While OKRs are the big commitments that the team is making, they do not supersede core team members responsibilities. This means retaining team capacity beyond OKRs for work that falls higher in a prioritization framework (example from product), such as forced prioritization items with an SLA/SLO. Meeting SLOs is not an OKR, as OKRs focus on what’s different.
   1. Other than core team member responsibilities such as those outlined above, all other major commitments should be prioritized through OKRs and consider team bandwidth.
   2. If a team gets a request for a major effort within the quarter, they can change the OKR by following the guidelines how to change an OKR within the quarter
2. Plan for OKRs to be ambitious, but achievable within the team capacity that you have for OKRs. While OKRs are meant to be ambitious, you should aim to complete them and strive to hit the ambitious plan. We recognize that with ambitious planning some OKRs will not be completed, but it is striving and reporting on OKRs with the goal of hitting 100% that helps us accomplish strong results. We score individual OKRs as “on track” when they are at least 80% complete. In aggregate, we expect that the average completion score across OKRs is 70%.
3. Review cascading OKRs first and allocate time for those. Cascading OKRs are those at the Company level that need your group’s contributions to be achieved. You should prioritize these first.
4. It is OK to push back on OKRs. If you can’t prioritize a cascading or shared OKR due to more important work, contact the owner of the OKR and make adjustments so that it is achievable without your team’s contribution, or remove it. It is OK to do this, with clear communication and collaboration. It is not acceptable to simply ignore the cascading OKR or shared OKR without clear upfront communication and prioritize other work instead.
5. When writing OKRs, focus on outcomes, not tasks, and make key results measurable.
6. For any OKR with a dependency, make sure to get commitment on the dependency with shared objectives. If you don’t get commitment in the shared objective, make changes as needed to keep to feasible OKRs.

Tips for OKRs that are scoreable

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:

Example OKRs

Objective: Establish GitLab leadership in X area.

• Avoid ❌ KR1: GitLab X becomes available in beta, including Y functionality in beta, with a path to general availability next quarter.
• Instead ✅ KR1: GitLab X reaches 100k paid MAU by end of quarter.
• Avoid ❌ KR2: Ship 10 components to support the use of X.
• Instead ✅ KR2: 30% of GitLab users are able to use X with the components built.

This aligns with a focus on outcomes and business results instead of KRs tracking tasks or launches.

External examples

1. Examples from whatmatters.

OKR resources

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