Update OKR Process

Why is this change being made?

Updating the OKR process to reflect changes to Yearlies, review timeline in light of key review scope changes, and remove stale content.

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
  • The when to get approval handbook section explains the workflow in more detail
• For transparency, share this MR with the audience that will be impacted.
  • Team: For changes that affect your direct team, share in your group Slack channel
  • Department: If the update affects your department, share the MR in your department Slack channel
  • Division: If the update affects your division, share the MR in your division Slack channel
  • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
    • For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter

Commits

• Update OKR Process

---

content/handbook/company/okrs/_index.md

@@ -8,7 +8,7 @@ description: "OKRs stands for Objective-Key Results and are our quarterly object
 Our OKR process and timelines are public and listed on the pages below.
 
 - [FY25-Q2 Active](/handbook/company/okrs/fy25-q2/)
-- FY25-Q3 Future: to be shared
+- [FY25-Q3 Future](/handbook/company/okrs/fy25-q3/)
 - [Previous OKRs](#okr-archive)
 
 OKRs are internal-only in line with guidance from the [SAFE framework](/handbook/legal/safe-framework/).
@@ -17,7 +17,7 @@ OKRs are internal-only in line with guidance from the [SAFE framework](/handbook
 
 [OKRs](https://en.wikipedia.org/wiki/OKR) stand for Objectives and Key Results and are our quarterly objectives.
 OKRs are *how* to achieve the goal of the Key Performance Indicators [KPIs](/handbook/company/kpis/).
-They lay out our plan to execute our [strategy](/handbook/company/strategy/) and help make sure our goals and how to achieve them are clearly defined and aligned throughout the organization.
+They lay out our plan to execute our [Yearlies](/handbook/company/yearlies/), which in turn support our [strategy](/handbook/company/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.
 
@@ -39,10 +39,6 @@ The [E-Group](/handbook/company/structure/#e-group) does use it for their [Perfo
 
 The [Chief of Staff to the CEO](/job-families/chief-executive-officer/chief-of-staff/) initiates and guides the OKR process.
 
-Watch EVP, Engineering Eric Johnson discuss the power of OKRs from his perspective:
-
-{{< youtube "aT66up3SyVU" >}}
-
 ## 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).
@@ -61,7 +57,7 @@ Objectives should be:
 1. **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.
 1. **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.
-1. **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](https://www.britannica.com/topic/bystander-effect/Diffusion-of-responsibility).
+1. **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](https://www.britannica.com/topic/bystander-effect/Diffusion-of-responsibility).
 1. **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.
 1. **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.
 
@@ -152,21 +148,15 @@ OKRs do not replace or supersede core team member responsibilities or performanc
 
 ## Who sets OKRs?
 
-Generally, we do OKRs up to the team level.
-As a company, we don't do [individual OKRs](https://hrblog.spotify.com/2016/08/15/our-beliefs/), 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.
+Company-level [Yearlies] guide company-level Objectives and Key Results. At a minimum, each Function should inherit the company-level Yearlies for their Objectives and have 1-3 function level Key Results that supports company Objective and KR attainment each quarter.
 
-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?
+Individual functions and teams have discretion around how much they use OKRs beyond the Yearly cascade level.
 
 ## Alignment
 
-OKRs are our quarterly priorities that create progress for our [Yearlies](/handbook/company/yearlies/), which are our annual company goals. Since OKRs create progress for yearlies, OKRs are aligned to one of the yearlies.
+OKRs are our quarterly priorities that create progress toward our [Yearlies](/handbook/company/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](/handbook/company/strategy/#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.
+OKRs are directly aligned to yearlies and not directly aligned to one of the three pillars of the [three year strategy](/handbook/company/strategy/#three-year-strategy).
 
 ## Cadence
 
@@ -176,78 +166,76 @@ Since OKRs create progress for our [Yearlies](/handbook/company/yearlies/), by a
 
 ## OKR Process at GitLab
 
-The EBA to the CEO is responsible for scheduling and coordinating 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](/handbook/finance/#fiscal-year).
-
-Should you need to reschedule, please @ mention the EBA to the CEO in the `#eba-team` slack channel.
+The CoS to the CEO is coordinating the OKRs process detailed below. The EBA to the CFO schedules the [Key Review Meetings](/handbook/company/key-review/) that are forums for review.
 
 ### CEO initiates new quarter's OKRs
 
-**Six Mondays** before the start of the fiscal quarter, the CEO and Chief of Staff (CoS) to the CEO initiate the OKR process.
+**Three Mondays** before the start of the fiscal quarter, the CEO and Chief of Staff (CoS) to the CEO initiate the OKR process.
 
-The CoS to the CEO creates a Google Doc for E-Group alignment and shares initial suggestions with the CEO. The CEO and CoS to the CEO discuss and modify these initial suggestions. This document is shared with E-Group in the [E-Group Weekly](/handbook/company/e-group-weekly/) which is **five weeks** before the start of the coming quarter. E-Group is encouraged to offer feedback in the E-Group Weekly, directly within the Google Doc, or in meetings with the CEO or Office of the CEO.
+The CoS to the CEO creates a Google Doc for E-Group alignment and shares initial suggestions with the CEO. The CEO and CoS to the CEO discuss and modify these initial suggestions. This document is shared with E-Group in the [E-Group Weekly](/handbook/company/e-group-weekly/) which is **two weeks** before the start of the coming quarter. E-Group is encouraged to offer feedback in the E-Group Weekly, directly within the Google Doc, or in meetings with the CEO or Office of the CEO. **Unless there is a strong reason to adjust, CEO OKRs will directly reflect Yearly goals.**
 
-**Four Mondays** before the start of the quarter, the CoS to the CEO will share the company OKRs draft with E-Group.
+**Two Mondays** before the start of the quarter, the CoS to the CEO will share the company OKRs draft with E-Group. If there are no concerns voiced, it will then be shared with all of GitLab in the `#okrs` channel.
 
 Company OKRs may continue to be refined in the lead up to the coming quarter.
 
 ### Executives propose OKRs for their functions
 
-**Four Mondays** before the start of the fiscal quarter, in the days after the CEO shares OKRs with all of GitLab in the #okr channel, Executives propose OKRs for their functions in the OKR draft review meeting agenda. After this meeting, as OKRS are finalized, functional OKRs should be posted in GitLab. This should be noted through a Slack message in the #okrs channel. The CEO and Chief of Staff to the CEO should be @ mentioned. The CEO will confirm sign-off on objectives by commenting directly on them. While the CEO is the DRI, this responsibility may be delegated to the CoS to the CEO. The CoS to the CEO will also post company OKRs in GitLab.
-
-Each executive should aim for a maximum of 5 objectives. Each objective has between 0 and 3 key results. While OKRs are known for being ambitious or committed, we only have ambitious OKRs. When drafting the OKRs, executives should strive to have clear numerical targets. Teams within a function can have zero objectives and key results.
-
-Function objectives should cascade from one of the CEO's OKRs in GitLab.
-
-Executives should consider how their OKR efforts can have the greatest impact on the organization. Functions can have objectives under any of the three company 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 was 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 company OKR that appears to be most directly related to the function.
-
-When ready for review or when changes to objectives or KRs are made, relevant objectives and KR links from GitLab should be shared in the #okrs channel in Slack and at-mention the Chief of Staff to the CEO and CEO. The CEO is responsible for OKR approvals, but may delegate this responsibility to the CoS to the CEO.
+Function objectives should cascade from one of the Company OKRs in GitLab.
+Functions can plan and start working on their OKRs ahead of the alignment meeting.
 
-See [How to Use GitLab for OKRs](/#how-to-use-gitlab-for-okrs) for how to create and align OKRs to company OKRs using GitLab.
+**3-4 weeks after** the start of the fiscal quarter, about a week after Sales Leadership Quarterly Business Reviews, Executives propose OKRs for their functions in the [Key Review Meeting](/handbook/company/key-review/). After this meeting, as OKRS are finalized, functional OKRs should be posted in GitLab. This should be noted through a Slack message in the #okrs channel. The CEO and Chief of Staff to the CEO should be @ mentioned. The CEO will confirm sign-off on objectives by commenting directly on them. While the CEO is the DRI, this responsibility may be delegated to the CoS to the CEO. The CoS to the CEO will also post company OKRs in GitLab.
 
-### OKR Draft Review Meeting
+The exact timeline for the upcoming quarter will be [available in the handbook](/handbook/company/okrs/#most-recent-okrs).
 
-In 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:
+When ready for review or when changes to objectives or KRs are made, relevant objectives and KR links from GitLab should be shared in the `#okrs` channel in Slack and at-mention the CoS to the CEO, and CEO. The CEO is responsible for OKR approvals, but may delegate this responsibility to the CoS to the CEO.
 
-1. Function
-    1. Link to the objective in GitLab
-    1. Dependencies: call out any dependencies
-
-If additional action needs to be taken by the functional leader, the GitLab link should be re-shared in the #okrs channel in Slack when it's ready for final review.
+See [How to Use GitLab for OKRs](#how-to-use-gitlab-for-okrs) for how to create and align OKRs to company OKRs using GitLab.
 
 ### Cascade
 
-Now that Executive (function-level) OKRs are set
+Once 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.
+Executives shift their focus to finalizing OKRs within their team.
 
-This is also the opportunity to create team OKRs in GitLab and add them to the relevant CEO and executive OKR.
+This is also the opportunity to, if desired, create team OKRs in GitLab, and add them to the relevant CEO and executive OKR.
 
-Through the quarter, regular updates by the relevant DRI for Company KRs are expected ahead of [E-group monthly touchpoint meetings](../offsite/_index.md#monthly-touch-point-meetings). Exact dates for when updates are due are shared in the `#okrs` Slack channel with reminders set 7 days and 1 day before the due date.
+Once a quarter, the relevant DRI for Company KRs are expected to provide updates ahead of [E-group quarterly touchpoint meetings](../offsite/_index.md#quarterly-touchpoint-meetings).
+They may also be requested to provide updates on Company KRs async, typically once a month.
 
 ### Dependency Commitments
 
-Top level dependencies should be identified in the [OKR Draft Review Meeting](#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 doing work without first having input. This makes it difficult for teams to manage their own priorities and succeed in their own initiatives.
+Top level dependencies should be identified in the Key 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 doing 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](/handbook/values/#boring-solutions) is to create a sister KR for other departments that will need to be actively involved and link the KRs using the dependency function. 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 them.
 
 ### Documenting How to Achieve
 
-In FY21, we had quarterly How to Achieve Meetings in which senior team members shared their plans for achieving KRs. These meetings were often short and inefficient as much of the content could be covered during the planning process and reviewed async. We now have shorter OKR Review Meetings (50 minutes). In these E-Groups, team members should share their drafts in the agenda linked in the calendar invites. As functional OKRs are finalized, they should be entered in GitLab and the links should be shared in the #okrs channel (tag the CoS to the CEO and CEO for approval).
+[Key Review Meetings](handbook/company/key-review/) are the key forum to introducing new function OKRs and discussing progress and learnings since the previous quarter.
+
+Updates on OKRs should include:
 
-GitLab entries should include the following fields:
+1. Attainment against OKRs from the previous quarter, including:
+     1. Link to OKRs in GitLab
+     1. [DRI](/handbook/people-group/directly-responsible-individuals/)
+     1. Completion [score](#scoring-okrs)
+     1. Update summary
+     1. Learnings
+     1. Remaining dependencies to achievement
+     1. Next steps, if incomplete
 
-1. **Overview:** some additional background on what we are trying to accomplish and why it is important. This section should elaborate on KRs that are not fully descriptive and provide context for team members who might not otherwise understand the desired result.
-1. **DRI or Core Team**: document the [DRI](/handbook/people-group/directly-responsible-individuals/). Other key team members and their roles can also be captured in this section.
-1. **Action Items:** a list of 3-10 key action items for achieving the target. You can consider using checkboxes or a chart to help communicate progress.
-1. **Scoring**: your KR should be a statement that clearly indicates how you will score final achievement at the end of quarter. If it is, this section is not needed. When how the KR will be scored isn't immediately clear from the KR itself, details on how scoring will work should be documented according to [scoring guidelines](#scoring-okrs).
+1. Plans for OKRs for the current quarter, including:
+     1. Link to OKRs in GitLab
+     1. [DRI](/handbook/people-group/directly-responsible-individuals/)
+     1. Score (work may have already started in quarter)
+     1. Health status (at risk, needs attention, on track)
+     1. Status
+     1. Risks and dependencies
 
 ### The quarter begins
 
 The Chief of Staff to the CEO takes company OKRs and updates the OKR handbook page for the current quarter to be active. Each objective and KR should include the related GitLab link. The Office of the CEO should also create the handbook page for the following quarter and document the OKR process timeline.
 
-The CoS to the CEO shares the handbook update MR in the #okr channel in Slack and @ mentioned e-group. .
+The CoS to the CEO shares the handbook update MR in the #okr channel in Slack and notifies E-Group in an E-Group Weekly.
 
 ### Making changes within quarter
 
@@ -255,7 +243,7 @@ We value [iteration](/handbook/values/#iteration). We can change an objective or
 
 1. It becomes clear that the performance indicator does not provide the best measure for success
 1. A KR statement exists, but the target is a placeholder. For example, "Obtain $XM in bookings in Q1"
-1. A KR is related to achievement of a new initative, and it is agreed that we should pivot in terms of scope or focus as we learn more about what we want to achieve
+1. A KR is related to achievement of a new initiative, and it is agreed that we should pivot in terms of scope or focus as we learn more about what we want to achieve
 
 Please note that iteration **does not** mean [changing or lowering goal posts](https://about.gitlab.com/blog/2021/12/01/dont-confuse-these-twelve-shortcuts-with-iteration/), because it looks like we can't meet what were ambitious but agreed upon key results.
 
@@ -267,7 +255,7 @@ In the event that a functional objective that is captured in GitLab needs to be
 
 Top level Company KRs will appear in the handbook. OKRs have numbers attached to them for [ease of reference, not for ranking](/handbook/communication/#numbering-is-for-reference-not-as-a-signal). In order to maintain a [single source of truth](/handbook/product/ux/technical-writing/documentation/#documentation-is-the-single-source-of-truth-ssot) (SSoT), starting in FY24-Q1, we're putting functional objectives and KRs in GitLab and linking this to the handbook page. It also provides a SSoT for OKRs.
 
-Functional leaders are responsible for updating their objectives and KRs in GitLab before each [Key Review](key-review/#automated-kpi-slides).
+Functional leaders are responsible for updating their objectives and KRs in GitLab before each [Key Review](key-review/#automated-kpi-slides) and [Quarterly Touchpoint Meeting](/handbook/company/offsite/#quarterly-touchpoint-meetings).
 
 ## How to Use GitLab for OKRs
 
@@ -421,7 +409,12 @@ Watch this video for a demo on how to find the OKRs you're looking for:
 
 ## Maintaining the status of OKRs
 
-Teams should update the score for their key results in GitLab within the first five business days of every month and prior to the [Key Review](key-review/). If a key result is off track, it should be clear why. The owner should leave a comment with the most recent Health Status or there should be a link to an issue, an epic, or another source for details.
+Teams should update the score for their key results in GitLab regularly. KRs need to be updated a week before the [Key Review](key-review/), and a week before the [Quarterly Touch Point Meeting](/handbook/company/offsite/#quarterly-touchpoint-meetings). If a key result is off track, it should be clear why. The owner should leave a comment with the most recent Health Status or there should be a link to an issue, an epic, or another source for details.
+
+**If a function level OKR is meaningfully off track, it is the Exec Sponsor and DRI's joint obligation to proactively flag the issue. This may mean raising it outside of a Key Review or Monthly Touch Point Meeting.
+
+### Health Status
+
 When presenting the status of OKRs, we use the following terms to denote the status of a key result:
 
 1. On track - the DRI is confident the key result will be achieved.
@@ -430,13 +423,14 @@ When presenting the status of OKRs, we use the following terms to denote the sta
 
 An Objective/Key Results 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 objective owner will be responsible for designating a health status based on a roll up the health statuses of all relevant KRs.
 
-During Key Reviews, teams should include material that covers [key OKR progress details](key-review/#okr-slides) and links to relevant OKRs.
-Each KR should have a clear scoring
+Each KR should have a clear scoring.
 
 Company OKR progress that does not involve MPNI can be viewed [in the GitLab OKR project with the ~"Company OKR" label](https://gitlab.com/gitlab-com/gitlab-OKRs/-/issues/?sort=created_date&state=opened&label_name%5B%5D=Company%20OKR).
 
 ## Scoring OKRs
 
+OKRs and their scoring align with fiscal quarters.
+
 Since we set OKRs that are aspirational, we [don't expect 100% achievement](/handbook/company/okrs/#criteria-for-key-results) across KRs. We score individual KRs to note our achievement against our stated goal. This is the scoring framework.
 
 | Achievement against targets | Score |
@@ -445,7 +439,7 @@ Since we set OKRs that are aspirational, we [don't expect 100% achievement](/han
 | Off-target | 70 to 84% |
 | At risk | 0 to 69% |
 
-### Tips for goals that are scorable
+### Tips for goals 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.