Intempt's Employee Handbook

Objectives and Key Results (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 them are clearly defined and aligned throughout the organization.

Objectives are aspirational goals 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

We do not use it to give performance feedback or as a compensation review for team members.

Criteria for Objectives

Objectives should be:

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:

Introduce disruptive innovations

Establish differences between GitLab Inc. and competitors

Be recognized as an industry leader in a category

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.

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.

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.

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.

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 responsbility.

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.

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:

Aspirational - Aggressive but realistic stretch goals; if it feels uncomfortable, it's a good KR.

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.

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.

KRs should not be too specific that the KR needs to be rolled more than one level down.

Clear, Responsible Party - one single person or team responsible for Key Result.

Influenceable - the Key Result owner (department, team, or individual) should be able to impact Key Result through the owner's actions.

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.

Time Bound - has a due date. At GitLab, unless otherwise stated, this is within the quarter.

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.

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.

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.

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.

⁠

@2023 Intempt

⁠

Terms of Service⁠

⁠

GrowthOS

⁠

Documentation⁠

⁠

API Reference⁠

⁠

Resources

⁠

Templates⁠

⁠

Vault⁠

⁠

Company

⁠

About us⁠

⁠

Demo⁠

⁠

Why Intempt⁠

⁠

Jobs at Intempt⁠

⁠

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.