Joint R&D OKR Process

R&D OKR Overview

This page provides an overview of the joint R&D OKR workflow. All departments within R&D, which includes the Product and Engineering Divisions, collaborate by following this guidance. For clarifications on the OKR process, team members can post in Slack #product or #engineering-fyi.

Timeline and process for OKRs

The OKR process is designed to tie in to the overall OKR process the company uses. That process is driven largely off of the date of the Key Review meetings, so the Product process keys off of that date as well. Dates will not necessarily align with the start of a fiscal quarter as a result.

OKR Kick-off by Chief Product Officer

• 5 weeks prior to the start of the fiscal quarter, an OKR progress document kicks off the OKR drafting process:
  • Product Program Management or their delegate creates an OKR progress Google document from the template which is used as a checklist for the combined R&D Leadership Teams (PLT + CTO LT). Relevant dates are updated in the template document.
• 4 weeks prior to the start of the fiscal quarter:
  • Company-level OKRs will then be shared with all of GitLab in the #okrs channel.
  • Product Program Management shares the OKR progress document with the Chief Product Officer and Chief Technology Officer.
  • Chief Product Officer and Chief Technology Officer drafts R&D OKRs aligned to the Yearlies and Fiscal year product investment themes leveraging the Google progress document. This can be done async.
• 2-3 weeks prior to the start of the fiscal quarter:
  • Chief Product Officer and Chief Technology officer hold a sync 50m kickoff meeting and the outcome is agreement on top-level OKRs
  • Product Program Management puts R&D OKRs in GitLab based on the progress document
  • Executives finalize OKRs in an E-Group Weekly session (see the OKRs handbook section on this)
  • Product/Engineering LTs iterate on team-level OKRs below top-level OKRs (async)
• Start of the fiscal quarter
  • Chief Product Officer and Chief Technology officer share the top-level OKRs with the Chief of Staff to the CEO and E-Group
• 2 weeks prior to the key review meeting:
  • Chief Product Officer and Chief Technology officer review the proposed OKRs from teams and provide feedback (async)
  • Teams have a chance to iterate as needed until the Key Review deadline (one week prior to the Key Review)
  • Product Program Management finalizes R&D OKRs in GitLab and mentions @gl-product-pm (section, stage, and group product leads), @gitlab-com/engineering-division/cto-leadership, and/or post in the #product and #engineering-fyi Slack channels to finalize KR drafts with their respective Quad
  • Leads from each section, stage, and group review R&D OKRs and provide feedback directly in GitLab on changes that may be needed.
  • Leads plan and propose their respective section, stage and section OKRs following the guidance on how to write OKRs.
• 1 week prior to key review meeting:
  • OKRs finalized and included in Key Review content (async)
• Ongoing after the key review meeting:
  • KR Owners update scores monthly
  • KR Owners propose changes to OKRs as needed at any point.

Example schedule for FY25-Q4

1. 2024-10-21: CEO shares their OKRs with E-Group
2. 2024-10-25: CPO + CTO aligned on top-level R&D OKRs (async)
3. 2024-10-28: Eng + Product LT OKR kick-off (sync meeting) - in this meeting we will come to an agreement on top-level OKRs
4. 2024-10-28 - 2024-11-08: Eng + Product LT iterate on team-level OKRs, below top-level OKRs (async)
5. 2024-11-01: Share top-level OKRs with the Chief of Staff to the CEO and E-Group
6. 2024-11-08: CPO / CTO review the proposed OKRs from teams and provide feedback (async); teams have a chance to iterate as needed until the Key Review deadline, 2024-11-15
7. 2024-11-15: OKRs finalized and included in Key Review content (async)
8. 2024-11-22: Key Review (sync)

Updating the Status and Progress of OKRs

When to update the status of R&D OKRs

• For all R&D OKRs, the KR owners are responsible for keeping the status of their KRs in GitLab up to date
  • Team members who own specific OKRs will update the score (% complete) in GitLab monthly and ping any relevant stakeholders as needed. For example, since Q1 begins February 1, KR owners will provide score updates by February 15, March 15 and April 15. We follow this mid-month cycle to ensure there are accurate OKR status updates for Key Reviews which typically happen around the 20th of each month.
  • Update the OKR issue whenever you have additional information so that the status has the current state of the OKR.
• Owners of KRs will get pinged with reminders update their KRs through Slack around the 5th of each month.

How to report progress of R&D OKRs

• Prior to the key review meeting, shared R&D KR owners should lead and align on a plan for the R&D team to accomplish their KRs.
• For guidance on how to structure and score OKRs, refer to the Scoring OKRs section on the GitLab OKRs page.
• Before the next key review meeting, the OKR owner will do a final scoring of the OKRs. If the OKR shifted from the original OKR, always score the latest agreed to KRs that are still valid.

Scoring guidelines

To score KRs about improving from a baseline metric to a new target metric, score based on progress from baseline to target metric. For example, if baseline metric is 10, new target metric is 15, then the target improvement is 15-10 = 5. Every month calculate the improvement from baseline and divide it vs. the total target improvement (e.g. 15-10 or 5).

Sharing OKR completion at the end of the quarter

After the key review meeting, we encourage stage leaders to ensure that their teams have updated their OKRs. Please use your judgement when summarizing. Writing the end of quarter summary in a way that accurately shows team performance and is relevant, understandable, and readable by cross-functional stakeholders, and tag those stakeholders in the update.

This update from the Fulfillment team is a good example of this type of update.

How to change an OKR

In certain circumstances, it is appropriate to change an OKR once started. To make a change to an OKR:

1. OKR assignee review: The OKR assignee needs to review and agree to the proposed OKR change.
2. Tradeoffs review and communication: OKR assignee should ensure that the right tradeoffs are made to make the OKR feasible before the next key review meeting.
   1. If another OKR needs to be deprioritized this should be clearly outlined as part of the OKR change.
   2. If an OKR that needs to be deprioritized is a shared OKR, or a dependency for another team’s work, the other teams and stakeholders must be informed of the change and their feedback considered.
3. Inform manager: As part of making the OKR change, the assignee should inform their manager and impacted stakeholders, including any owner of an objective that this OKR rolls up to and owners of OKRs below the one being changed.
4. Track the change and update the OKR: Once the manager and impacted stakeholders acknowledge the change, the assignee should:
   1. Update the description of the parent objective to add a summary of the change and link to the rationale. This helps keep track of OKR changes.
   2. Update the actual OKR in the GitLab OKR tracker to reflect the latest agreed to OKR.

How to write OKRs

Please refer to the company-wide guidance in the How to Write OKRs section of the OKR handbook.

Examples of good OKRs

Please refer to the company-wide guidance in the Example OKRs section of the OKR handbook.

Organizing R&D OKRs in GitLab

R&D Objectives and Key Results are drafted and entered into GitLab as per Timeline and process for OKRs. This includes all Chief Product Officer and Chief Technology Officer level OKRs that R&D is tracking and reporting on. The R&D org as a whole encompasses many stages, groups, and teams. As a result, it can be challenging to track all OKRs in one place. As of FY25-Q4, we are using the following organizational structure to track our OKRs in GitLab:

• R&D OKRs (based on the Yearlies, combined top priority items across Dev, PM, UX, and QA) - assignees are the Chief Product Officer and Chief Technology Officer
  • Objective/Yearly 1: [high priority item A]
    • KR1…
    • KR2…
  • Objective/Yearly 2: [high priority item B]
    • KR1…
    • KR2…
  • Objective/Yearly 3: [high priority item C]
    • KR1…
    • KR2…

Some specific guidance:

1. Decide on an objective or key result.
2. Title: Avoid adding a “FYXX-QX” prefix as it’s indicated by the milestone.
3. Description:
   1. If a GitLab issue or epic exists, make sure to include a link to it.
   2. Mention how the OKR is scored.
4. All other fields including assignee and labels: follow the company guidance.
5. If an O/KR are specific to one team it should still be prioritized across the overall set of priorities. This can be indicated using labels to differentiate.

Deciding between an objective and key result in GitLab

Create a new or “child” objective if the OKR will be broken down further and will be scored based on its children (see next section). If there will be no children, create a key result.

If you’re unsure, we recommend creating a child objective. If an objective or key result needs to be changed to the other type, you will need to re-create it and delete the “old” work item.

This allows for a joint R&D rollup/scoring to take place while also allowing OKRs specific to a given Division to be tracked as well.

Tracking department OKRs

As GitLab objectives can only have one parent, there are various options to track OKR progress for a specific department, sub-department, or team:

1. Track R&D aligned and non-R&D aligned OKRs separately, using assignee or label(s) to pull a list of all relevant objectives.
   • Example: FY24-Q1 Customer Support
2. Don’t create department objectives and track on department KRs only. Recommend using a label to pull relevant KRs.
   • Example: VP Development label
3. Track only in linked epic or issue.
   • It is common that work is tracked in a gitlab-org issue or epic. While the OKR % needs to be updated in the OKR project, overview and all status updates could reside in the linked issue or epic.

How to contribute to this page

We encourage suggestions and improvements to the R&D OKR process so please feel free to raise an MR to this page. To keep us all aligned, as the process touches all teams across the company.