OKRs
Copied verbatim from (only becuase it's awesome reference): https://handbook.gitlab.com/handbook/company/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 strategy and help make sure our 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.
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:
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.
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.
Aspirational - Ambitious 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.
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.
Example OKRs
Product OKR example:
Objective: Drive a meaningful impact on Usability (Bugs, Infradev, Security) in order to avoid losing users due to usability issues. KRs (Key Results):
group::threat insights: Meet SLAs for all P1 and P2 bugs affecting usability
group::code review: Reduce mean-time-to-close of S1 + S2 bugs by 50%
group::editor: Complete 10 usability issues related to our primary categories (Web IDE, Snippets, Wiki)
Samples of well written KRs from GitLab team members:
Q2 product group KR experiment. What makes these great is that they’re succinct in scope and have clear metrics to measure success.
External resources:
Measuring Brand New Initiatives
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 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-1s, 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 its 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 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 one direction together. You should aim to complete them 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.
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, but 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?
Alignment
OKRs are our quarterly priorities that create progress for our Yearlies, which are our annual company goals. Since OKRs create progress for yearlies, OKRs are aligned to one of the yearlies.
OKRs are directly aligned to yearlies and not directly aligned to one of the three pillars of the three year strategy. However, since the yearlies are aligned to one of the strategic pillars, OKRs are indirectly aligned to one of the strategic pillars.
Cadence
OKRs are part of our company cadence.
Since OKRs create progress for our Yearlies, by achieving our quarterly priorities, we create progress for the rest of the items on the cadence page. By achieving our yearlies, we create progress to achieving our strategy. Achieving our strategy is key to realizing our vision, mission, and eventually purpose. In this way, OKRs are quarterly building blocks that create progress toward longer term goals.
Last updated