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](/handbook/company/okrs/fy25-q2/)
+- [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/).
@@ -174,21 +174,22 @@ The CoS to the CEO is coordinating the OKRs process detailed below. The EBA to t
 
 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.**
 
-**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 #okr channel.
+**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
 
+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.
+
 **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.
 
 The exact timeline for the upcoming quarter will be [available in the handbook](/handbook/company/okrs/#most-recent-okrs).
 
-Function objectives should cascade from one of the CEO's OKRs in GitLab.
-
-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.
+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.
 
-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.
+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
 
@@ -199,6 +200,7 @@ Executives shift their focus to finalizing OKRs within their team.
 This is also the opportunity to, if desired, create team OKRs in GitLab, and add them to the relevant CEO and executive OKR.
 
 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
 
@@ -407,9 +409,9 @@ 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 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.
+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 DRIs joint obligation to proactively flag the issue. This may mean raising it outside of a Key Review or Monthly Touch Point Meeting.
+**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
 
@@ -427,6 +429,8 @@ Company OKR progress that does not involve MPNI can be viewed [in the GitLab OKR
 
 ## 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 |