Skip to content
Snippets Groups Projects
Commit b3cb5c9b authored by Ian Pedowitz's avatar Ian Pedowitz
Browse files

Updating Engineering/Product OKR process to be joint R&D OKR process

parent 994b467e
No related branches found
No related tags found
1 merge request!9128Updating Engineering/Product OKR process to be 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](/handbook/product/) and [Engineering](/handbook/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](/handbook/company/okrs/#okr-process-at-gitlab) the company uses. That process is driven largely off of the date of the [Key Review](/handbook/company/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](https://docs.google.com/document/d/1er_KodQAnxbvoy5ttyd_9A6XNlC9j-OvR85LYX6RbEI/edit) 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](/handbook/company/yearlies/) and [Fiscal year product investment themes](https://about.gitlab.com/direction/#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](/handbook/company/okrs/#executives-propose-okrs-for-their-functions) 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](/handbook/engineering/infrastructure/test-platform/quad-planning/)
- 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](/handbook/product/product-okrs/#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](#how-to-change-an-okr) at any point.
#### Example schedule for FY25-Q4
{{% note %}}
FY25-Q4 is a transition quarter from the previous schedule to a new schedule documented in [this MR](https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/8712)
{{% /note %}}
1. **2024-10-21**: CEO shares their OKRs with E-Group
1. **2024-10-25**: CPO + CTO aligned on top-level R&D OKRs (async)
1. **2024-10-28**: Eng + Product LT OKR kick-off (sync meeting) - in this meeting we will come to an agreement on top-level OKRs
1. **2024-10-28** - **2024-11-08**: Eng + Product LT iterate on team-level OKRs, below top-level OKRs (async)
1. **2024-11-01**: Share top-level OKRs with the Chief of Staff to the CEO and E-Group
1. **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**
1. **2024-11-15**: OKRs finalized and included in Key Review content (async)
1. **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](/handbook/company/okrs/#how-to-use-gitlab-for-okrs) up to date
- Team members who **own** specific OKRs will update [the score (% complete) in GitLab](/handbook/company/okrs/#scoring-okrs) 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](/handbook/company/key-review/) 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](/handbook/company/okrs/#scoring-okrs) 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](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/6895#note_2026599607) 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](/handbook/company/okrs/#making-changes-within-quarter). To make a change to an OKR:
1. OKR assignee review: The OKR assignee needs to review and agree to the proposed OKR change.
1. 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.
1. 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.
1. 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.
1. 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.
1. 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](/handbook/company/okrs/#how-to-write-okrs) section of the OKR handbook.
### Examples of good OKRs
Please refer to the company-wide guidance in the [Example OKRs](/handbook/company/okrs/#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](#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](#deciding-between-an-objective-and-key-result-in-gitlab).
1. Title: Avoid adding a "FYXX-QX" prefix as it's indicated by the milestone.
1. Description:
1. If a GitLab issue or epic exists, make sure to include a link to it.
1. Mention [how the OKR is scored](#scoring-guidelines).
1. All other fields including assignee and labels: follow the [company guidance](/handbook/company/okrs/#how-to-use-gitlab-for-okrs).
1. 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](https://gitlab.com/gitlab-com/gitlab-OKRs/-/issues/?state=all&milestone_title=FY24-Q1&label_name%5B%5D=Department%3A%3ACustomer%20Support)
1. Don't create department objectives and track on department KRs only. Recommend using a label to pull relevant KRs.
- Example: [VP Development label](https://gitlab.com/gitlab-com/gitlab-OKRs/-/issues/?state=all&milestone_title=FY24-Q1&label_name%5B%5D=vp-development)
1. 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.
......@@ -95,24 +95,31 @@ 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](https://www.whatmatters.com/get-started). The ["6 Principles of setting OKRs"](https://primalogik.com/blog/okr-examples-best-practices/#How-to-Set-OKRs) may also be helpful.
For information on getting started with OKRs and writing basic OKRs, consider reviewing the [OKRs 101 lessons on What Matters](https://www.whatmatters.com/get-started). The ["6 Principles of setting OKRs"](https://primalogik.com/blog/okr-examples-best-practices/#How-to-Set-OKRs) may also be helpful.
#### Example OKRs
Teams should limit the number of OKRs they commit to so they have reasonable bandwidth to deliver. When planning OKRs:
Product OKR example:
1. Consider non-OKR commitments. While OKRs are the big commitments that the team is making, they [do not supersede core team members responsibilities](#how-do-i-prioritize-okrs-in-light-of-other-priorities). This means retaining team capacity beyond OKRs for work that falls higher in a prioritization framework ([example from product](/handbook/product/product-processes/#prioritization-framework)), such as forced prioritization items with an SLA/SLO. Meeting SLOs is not an OKR, as [OKRs focus on what's different](#okrs-are-what-is-different).
1. Other than core team member responsibilities such as those outlined above, all other major commitments should be prioritized through OKRs and consider team bandwidth.
1. If a team gets a request for a major effort within the quarter, they can change the OKR by following the guidelines [how to change an OKR within the quarter](#making-changes-within-quarter)
1. Plan for [OKRs to be ambitious, but achievable](#criteria-for-key-results) within the team capacity that you have for OKRs. While OKRs are meant to be ambitious, [you should aim to complete them](#how-do-i-prioritize-okrs-in-light-of-other-priorities) and strive to hit the ambitious plan. We recognize that with ambitious planning some OKRs will not be completed, but it is striving and reporting on OKRs with the goal of hitting 100% that helps us accomplish strong results. We score individual OKRs as "on track" when they are at least 80% complete. In aggregate, we expect that the average completion score across OKRs is 70%.
1. [Review cascading OKRs](#cascading-okrs-and-how-to-align-division-okrs-to-the-company-okrs) first and allocate time for those. Cascading OKRs are those at the Company level that need your group's contributions to be achieved. You should prioritize these first.
1. It is OK to push back on OKRs. If you can't prioritize a cascading or shared OKR due to more important work, contact the owner of the OKR and make adjustments so that it is achievable without your team's contribution, or remove it. It is OK to do this, with clear communication and collaboration. It is not acceptable to simply ignore the cascading OKR or shared OKR without clear upfront communication and prioritize other work instead.
1. When writing OKRs, focus on outcomes, not tasks, and make key results measurable.
1. For any OKR with a dependency, make sure to get [commitment on the dependency](#dependency-commitments) with [shared objectives](#shared-objectives). If you don't get commitment in the shared objective, make changes as needed to keep to feasible OKRs.
**Objective**: Drive a meaningful impact on Usability (Bugs, Infradev, Security) in order to avoid losing users due to usability issues.
**KRs (Key Results):**
#### Example OKRs
- 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)
**Objective: Establish GitLab leadership in X area.**
Samples of well written KRs from GitLab team members:
- Avoid ❌ KR1: GitLab X becomes available in beta, including Y functionality in beta, with a path to general availability next quarter.
- Instead ✅ KR1: GitLab X reaches 100k paid MAU by end of quarter.
- Avoid ❌ KR2: Ship 10 components to support the use of X.
- Instead ✅ KR2: 30% of GitLab users are able to use X with the components built.
1. [Q2 product group KR experiment](https://gitlab.com/gitlab-com/Product/-/issues/2095). What makes these great is that they're succinct in scope and have clear metrics to measure success.
This aligns with a focus on outcomes and business results instead of KRs tracking tasks or launches.
External resources:
##### External resources
1. [Examples from whatmatters](https://www.whatmatters.com/get-examples).
......
---
title: Engineering OKRs
title: Joint R&D OKR Process
---
Here is the [standard, company-wide process for OKRs](/handbook/company/okrs/). Engineering has some small deviations from (and extensions to) this process.
## Historical OKRs
All of our [past OKRs are available internally](https://drive.google.com/drive/search?q=previous%20OKRs).
## Active OKRs FY24-Q2
The source of truth for GitLab OKRs and KRs is [GitLab](https://gitlab.com/gitlab-com/gitlab-OKRs/-/issues/?sort=due_date&state=opened&assignee_username%5B%5D=joergheilig&label_name%5B%5D=OKR&milestone_title=FY24-Q2&first_page_size=50). CTO objectives and KRs are aligned to company OKRs on [this page](/handbook/company/okrs/fy24-q2/).
1. CTO: [Continue to win against GitHub with AI in all we do](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2231)
1. **CTO KR**: [Enhanced Support offering ready for launch in Q3](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2429)
1. **CTO KR**: [Experimental launch of Workspaces feature used by 10 team members to develop GitLab features](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2430)
1. **CTO KR**: [Create a foundation in support of rapid experimentation](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2432)
1. **CTO KR**: [48 experimental, 16 beta, and 8 GA AI Assisted features delivered](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2433)
1. CTO: [Reducing churn and contraction](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2434)
1. **CTO KR**: [Achieve >99.95% availability consistently in Q2 for all GA services (primary, sidekiq, CI runners, and git access)](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2435)
1. **CTO KR**: [Implement changes to gitlab.com infrastructure to allow us to manage to RTO (2hrs) and RPO (1hr) in Q3](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2436)
1. **CTO KR**: [Triage small fixes from Support, Quality, Sales, UX, Infrastructure for every sprint (shared objective between the above, Development and Product)](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2438)
1. **CTO KR**: [Execute Pajamas Button Mass Migration for 560 Buttons](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2439)
1. CTO: [Make GitLab easier to do business with](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2440)
1. **CTO KR**: [Cloud Licensing is internally enforced pre-sales for every renewal and new deal with <50 exceptions/quarter approved by McB(shared objective between Support and Sales)](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2441)
1. **CTO KR**: [Reduce unplanned self-managed upgrade stops](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2442)
1. CTO: [Continue to build a diverse team of top talent that we retain and grow](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2443)
1. **CTO KR**: [Refine the Engineering promotion process for IC levels (Staff+) to include structured cross functional feedback and allow us to remove gearing ratios without sacrificing rigor](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2444)
1. **CTO KR**: [Team member check-ins completed with a growth plan in place with a focus on ensuring business continuity throughout FY'24](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2445)
1. **CTO KR**: [100% of Managers in Engineering complete the Neurodiversity short course in LevelUp](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2446)
1. CTO: [Engineering efficiency and foundations](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2448)
1. **CTO KR**: [Cells on track to launch in Q4 of FY'25](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2450)
1. **CTO KR**: [Overall hosting costs reduced by 5% from FY24Q1](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2452)
1. **CTO KR**: [Two horizontal foundational engineering efficiency initiatives funded and on track](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2453)
1. **CTO KR**: [Master pipeline stability >95% and Merge Request pipeline duration <60 mins](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2454)
1. **CTO KR**: [Make the Architecture Evolution Workflow so frictionless that it is used for 80% of new designs that take longer than 4 weeks to implement](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2455)
1. **CTO KR**: [Rewrite Engineering Principles handbook page to reflect the current needs of the engineering organization better](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/2456)
## OKRs that require Product to schedule work
We sometimes have Engineering OKRs that require assistance from Product to ensure the issues are scheduled in that quarter. An example would be work to burn down our [SUS backlog](/handbook/product/ux/performance-indicators/system-usability-scale/). As our quarters use calendar months, and our product development means we [release every month](/handbook/engineering/releases/#timelines), there is a disconnect that means we should start planning earlier. While the preference is for a portion of the issues to be in [validation phase 3](/handbook/product-development-flow/#validation-phase-3-design) and ready to be scheduled for the first milestone of a quarter (which starts just before the fiscal quarter), some items may roll over to the first milestone in the following quarter. OKR scoring takes this timeline disconnect into account. See the [Product OKR process](/handbook/product/product-okrs/) for more information.
As a result, Engineering will begin communicating with Product **6 weeks before the start of the quarter** regarding any possible upcoming OKRs that need scheduling assistance from PMs. The goal is at **4 weeks before the start of the quarter** Engineering will confirm alignment with Product on shared OKRs. See the [Product OKR timeline](/handbook/product/product-okrs/) for more details. There is no set number for joint OKRs, and should not be a large proportion of Engineering OKRs in any quarter.
As this is earlier than the typical company timeline for OKRs, the exact timeline may shift depending on the [company OKR timeline](/handbook/company/okrs/#okr-process-at-gitlab), and drafting should begin based on top business need including [top initiatives](/handbook/company/top-cross-functional-initiatives/), [3 year strategy](/handbook/company/strategy/#three-year-strategy), and especially [FY direction](https://about.gitlab.com/direction/).
## OKR Kickoff
This process should begin no later than two weeks before the end of the preceding quarter. And kickoff should happen on or before the first day of the new quarter.
If you need guidance on writing OKRs, please refer to the [fundamentals of OKR at GitLab](/handbook/company/okrs/#fundamentals-of-impactful-okrs), which includes OKR examples and additional resources.
1. OKR owners should author OKRs.
1. Get approval **prior to the first day of the quarter** from your manager.
- Use 1:1 with CTO to review
- For everyone else: Ask you manager to do an async review of your OKRs, or discuss in a 1:1.
1. Communicate dependencies to other divisions, departments, or teams. Encourage them to take on corollary OKRs.
## Scoring guidelines
We will use the following guidelines for consistency.
1. Progress percentage is automatically updated based on child objectives or KRs.
1. For manually updated percentages, ensure to include an explanation of how the percentage is calculated in the OKR description.
- The calculation can be simple "% of goal, 30 S2 bugs from <link>".
- Consider breaking down project or task KRs. For example, "10% gathering data, 20% analyzing data, 20% summary of data, 20% write proposal, 10% gather feedback, 20% decide and open epic with issues with work required".
1. For scoring KRs that apply to a **rate** (for instance, [MR rate](../metrics/#merge-request-rate)), we score them as follows:
- Take the initial rate before the quarter. For example, this is 10.
- Take the target rate at the end of the quarter. In this example, it is 17.
- Subtract initial rate and target rate to determine the target increase: 17 - 10 = 7.
- Each month, take that month's rate and calculate our progress towards the target independently. For example:
- Month 1: 12. The score is (12 - 10) / 7 = 2 / 7.
- Month 2: 13. The score is (13 - 10) / 7 = 3 / 7.
- Month 3: 15. The score is (15 - 10) / 7 = 5 / 7.
- Take the score for the month, divide it by three, and add it to the total score. In the above example:
- Month 1: 2 / 7 / 3 ~= 9.5%.
- Month 2: 3 / 7 / 3 ~= 14%. Added to the previous month, the score is now 23.5%.
- Month 3: 5 / 7 / 3 ~= 24%. Added to the previous months, the final score is 47.5%.
## Entering OKRs
For instructions, please refer to the ["How to use GitLab for OKRs" section on the OKR page](/handbook/company/okrs/#how-to-use-gitlab-for-okrs).
Some specific guidance:
1. [Decide on an objective or key result](#deciding-between-an-objective-and-key-result-in-gitlab).
1. Title: Avoid adding a "FYXX-QX" prefix as it's indicated by the milestone.
1. Description:
1. If a GitLab issue or epic exists, make sure to include a link to it.
1. Mention [how the OKR is scored](#scoring-guidelines).
1. All other fields including assignee and labels: follow the [company guidance](/handbook/company/okrs/#how-to-use-gitlab-for-okrs).
### 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.
### CTO OKR alignment and scoring
To ensure scoring is updated correctly, all OKRs that are CTO aligned should be children of the CTO-level OKRs.
The Department OKRs directly aligned to the CTO-level OKRs must be updated manually or automatically from its children.
If your department has OKRs that are aligned to *company OKRs* that are not CTO aligned, follow the guidelines in this section, then [CEO alignment](/handbook/company/okrs/#how-to-align-division-okrs-to-the-ceo-okrs).
Using a hypothetical example:
1. CTO Objective 1: Grow the team. == Objective
1. KR 1.1: Hit hiring target of 30 new hires. == Child objective
1. Development: Hire 15 new hires. == Child objective
1. Dev: Hire 5 new hires. == Key result
1. Ops: Hire 5 new hires. == Key result
1. Sec: Hire 5 new hires. == Key result
1. Support: Hire 5 new hires. == Key result
1. Infrastructure: Hire 10 new hires. == Key result
In this example, Infrastructure has 1 Director who wants to track hiring in their sub-department, so they create a separate GitLab objective with KRs for each manager.
However, the objective would not be a child of the Infrastructure "10 new hires" because they are only hiring 3 of the 10 roles. Without the other 7, it would not rollup the score correctly.
The description of the Infrastructure key result and the sub-department objective can have links to each other.
### Tracking joint OKRs
Joint OKRs across different divisions must be duplicated with one OKR item in each division. Each OKR should be aligned for scoring to each C-level (for example, one for CTO and one for CProdO for an Engineering-Product joint OKR). Titles can vary for joint OKRs, but otherwise, follow the duplicating guidance below.
For Engineering-Product joints:
1. Generally the Product OKR will be the SSoT with regular *detailed* progress reports.
1. Ensure the Eng OKR has the `vp-development` label if the VP of Development needs to track on it.
### Tracking department OKRs
If you would like a video walkthrough, team members can view [this private video](https://youtu.be/MkKRyuhDYtE).
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. Duplicate OKRs.
- If you duplicate a work item, copy the wording of the title exactly. In both, ensure the description has cross-links with an indication of which one is the [SSoT](../../values/#single-source-of-truth). When updating, change the % completed on both OKRs, with a status report on the SSoT.
- Example: See next section.
1. Track CTO aligned and non-CTO aligned OKRs separately, using assignee or label(s) to pull a list of all relevant objectives.
- Example: [FY24-Q1 Customer Support](https://gitlab.com/gitlab-com/gitlab-OKRs/-/issues/?state=all&milestone_title=FY24-Q1&label_name%5B%5D=Department%3A%3ACustomer%20Support)
1. Don't create department objectives and track on department KRs only. Recommend using a label to pull relevant KRs.
- Example: [VP Development label](https://gitlab.com/gitlab-com/gitlab-OKRs/-/issues/?state=all&milestone_title=FY24-Q1&label_name%5B%5D=vp-development)
1. 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.
#### Example: Duplicating OKR for tracking
Using the hypothetical example from the previous section, Development may want to track hiring at the department level.
If using the duplication method, the structure may look something like this:
1. CTO Objective 1: Grow the team. == Objective
1. KR 1.1: Hit hiring target of 30 new hires. == Child objective
1. Development: Hire 15 new hires. == Key result, Description links to Development 1.1 for progress updates
1. Support: Hire 5 new hires. == Key result
1. Infrastructure: Hire 10 new hires. == Key result
1. Development Objective 1: Grow the team. == Objective
1. KR 1.1: Hire 15 new hires. == Child objective, Description notes % also needs to be updated in CTO 1.1.1
1. Dev: Hire 5 new hires. == Key result
1. Ops: Hire 5 new hires. == Key result
1. Sec: Hire 5 new hires. == Key result
## OKR Status
- Update the OKR issue **whenever you have additional information** so that the status has the current state of the OKR.
- For direct reports of the CTO, expect to give an update in **each weekly 1:1**.
- For individuals that do a **monthly key review meeting**, expect to give an OKR update there.
At this time, there is no automatic scoring from GitLab issues. All OKRs need to be updated either manually or through rollup scoring.
## OKR Retrospection
This process should begin on the first day of the subsequent quarter, and complete no later than two weeks after.
1. After the end of each quarter, OKR owners should ensure their OKR/KR(s) progress is accurate before retrospection and closing.
1. Each OKR owner should add retrospection notes closing out their OKR/KR(s).
1. OKR owners should retrospect as comments following our retrospection [guidelines](../workflow/#retrospective) (good, bad, and try).
1. It's recommended that OKR owners document retrospection at the OKR (parent object) to optimize the number of retrospections/roll-ups.
1. OKR owners should review with their manager in the next 1:1 and they should discuss and close the OKR/KR(s) synchronously.
1. Managers can summarize their retrospections by closing each KR (child object) aligned to their OKR (parent object) and leaving a brief "Good/Bad/Try" in the Closing Note.
1. If retrospection notes for KR(s) assigned to your direct report(s) have not been populated, please `@` mention your direct report DRI and ensure retrospection is captured in that OKR object.
1. After the [OKR Restrospective Meeting](../#okr-retrospective-meeting), once all outstanding conversations have been documented & applicable action items assiged to DRI(s), the leaders of each departments will ensure closure of all department's OKR/KR(s).
### OKR Retrospective Meeting
The Chief Technology Officer and the leaders of each department meet synchonously on the second Tuesday in the month after each quarter ends to [discuss the OKRs from the previous quarter](https://drive.google.com/drive/search?q=Engineering%20OKR%20Retrospective). This is an opportunity to collaborate on cross-functional initiaties with the focus being the retrospective. Leaders will voice-over the good, bad and try items from the past quarter. The meeting will not cover the status and scores of the OKRs.
{{% include "includes/joint-r-d-okr-process.md" %}}
---
title: Product Division OKRs
title: Joint R&D OKR Process
---
{{% include "includes/product-handbook-links.md" %}}
## Product Division OKR Overview
For an overview of our overall approach to OKRs, as well as any company-wide OKR due dates, see [Objectives and Key Results (OKRs)](/handbook/company/okrs/).
### General timeline and process
![General timeline and process ](/handbook/product/product-processes/product-okrs/prod-okr-timeline.png)
### Guidance on timeline and process
This page provides an overview of the Product Division OKR workflow. All departments (product management, UX, etc.) collaborate by following this guidance. For clarifications on the OKR process, team members can post in Slack #product.
## Timeline and process for OKRs
The OKR process is designed to tie in to the overall [OKR process](/handbook/company/okrs/#okr-process-at-gitlab) the company uses. That process is driven largely off of the date of the [Key Review](/handbook/company/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 key review meeting, an [OKR progress document](https://docs.google.com/document/d/1er_KodQAnxbvoy5ttyd_9A6XNlC9j-OvR85LYX6RbEI/edit) kicks off the OKR drafting process:
- Program Management or their delegate creates an OKR progress Google document from the template which is used as a checklist for PLT. Relevant dates are updated in the template document.
- **4 weeks** prior to the key review meeting:
- Program Management shares the OKR progress document with Chief Product Officer
- Chief Product Officer drafts Product Division OKRs aligned to the [annual product investment themes](https://about.gitlab.com/direction/#fy23-product-investment-themes) and annual [Yearlies](/handbook/company/yearlies/) leveraging the [drafting issue](https://gitlab.com/gitlab-com/Product/-/blob/main/.gitlab/issue_templates/Product-Division-OKR-Drafting.md) and Google progress document.
- **3 weeks** prior to the key review meeting:
- Chief Product Officer shares proposed Product OKRs with Product Leadership Team
- Product Leadership team provides their feedback or any alternate OKRs in the progress document
- Program Management starts to put Product Division OKRs in GitLab based on the progress document
- **2 weeks** prior to the key review meeting:
- Program Management finalizes Product Division OKRs in GitLab and mentions `@gl-product-pm` (section, stage, and group product leads) and/or post in the #product Slack channel to finalize KR drafts with their respective [Product Quad](/handbook/engineering/infrastructure/test-platform/quad-planning/)
- Product leads have at least 2 weeks to review Chief Product Officer OKRs, propose changes, and plan any additional OKRs that cascade up to Chief Product Officer OKRs.
- Product leads from each section, stage, and group review Product Division OKRs and provide feedback directly in GitLab on changes that may be needed.
- Product leads plan and propose their respective section, stage and section OKRs following the guidance on [how to write OKRs](/handbook/product/product-okrs/#how-to-write-okrs).
- **1 weeks** prior to key review meeting:
- Product leaders at all levels (division, section, stage, group) discuss and finalize OKR changes needed to ensure alignment with the goal of finalizing OKRs before the key review meeting.
- At the end of the week, Product Division OKRs are reviewed by the Product Leadership Team and updated in GitLab to ensure that they reflect what the section/stage/group KRs show that can be delivered during this OKR cycle.
- **Ongoing** after the key review meeting:
- KR Owners update scores monthly
- KR Owners [propose changes to OKRs as needed](/handbook/product/product-okrs/#how-to-change-an-okr-within-the-quarter) at any point.
## Updating the Status and Progress of OKRs
### When to update the status of Product OKRs
1. For all Product team OKRs, the KR owners are responsible for keeping the status of their KRs in [GitLab](/handbook/company/okrs/#how-to-use-gitlab-for-okrs) up to date
- Team members who **own** specific OKRs will update [the score (% complete) in GitLab](/handbook/company/okrs/#scoring-okrs) monthly and ping any relevant stakeholders as needed. For example, since FY23-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](/handbook/company/key-review/) which typically happen around the 20th of each month.
2. **Owners** of KRs will get pinged with reminders update their KRs through Slack around the 5th of each month.
3. **Owners** of KRs will also get pinged in the [Product Key Review issue](https://gitlab.com/gitlab-com/Product/-/issues/2919) as needed to update the Product Key Review slides around the 18th of each month based on what is in GitLab.
#### How to report progress of Product OKRs
- Prior to the key review meeting, shared product KR owners should lead and align on a plan for the [Product Group](/handbook/product/product-processes/#quad--infra--security-product-group-dris) to accomplish their KRs.
- For guidance on how to structure and score OKRs, refer to the Scoring OKRs section on the GitLab OKRs page (/company/okrs/#scoring-okrs).
- 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.
### Sharing OKR completion at the end of the quarter
During the first two weeks after the key review meeting, every Product stage should complete an OKR retrospective leveraging the [Product OKR Retrospective template](https://gitlab.com/gitlab-com/Product/-/issues/new?issuable_template=Product-OKR-Retrospective). The retrospective DRI is the PM leading the stage. Beyond the stage members, the product and engineering lead of the section needs to be invited to the retrospective.
We recommend sharing the results of the retrospectives with `@gl-product-pm` and other relevant stakeholders.
### How to change an OKR
In certain circumstances, it is appropriate to [change an OKR once started](/handbook/company/okrs/#making-changes-within-quarter). 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 this will look in Product Key Review slides
- Product team OKR owners may leverage this [slide template](https://docs.google.com/presentation/d/1O5Kc1kpJJBm5aJFT24V05xuR3pHjCGzID-QkYcUSZ5k/edit#slide=id.geb1b1c60d1_1_4) if additional details are needed for their KRs
## How to write OKRs
Product groups should limit the number of OKRs they commit to so they have reasonable bandwidth to deliver. When planning OKRs:
1. Consider non-OKR commitments. While OKRs are the big commitments that the team is making, they [do not supersede core team members responsibilities](/handbook/company/okrs/#how-do-i-prioritize-okrs-in-light-of-other-priorities). For R&D, this means retaining team capacity beyond OKRs for work that falls higher in our [prioritization framework](/handbook/product/product-processes/#prioritization-framework), such as forced prioritization items with an SLA/SLO. Meeting SLOs is not an OKR, as [OKRs focus on what's different](/handbook/company/okrs/#okrs-are-what-is-different).
1. Other than core team member responsibilities such as those outlined above, all other major commitments should be prioritized through OKRs and consider team bandwidth.
2. If a team gets a request for a major effort within the quarter, they can change the OKR by following the guidelines above about [how to change an OKR within the quarter](#how-to-change-an-okr-within-the quarter)
2. Plan for [OKRs to be ambitious, but achievable](/handbook/company/okrs/#criteria-for-key-results) within the team capacity that you have for OKRs. While OKRs are meant to be ambitious, [you should aim to complete them](/handbook/company/okrs/#how-do-i-prioritize-okrs-in-light-of-other-priorities) and strive to hit the ambitious plan. We recognize that with ambitious planning some OKRs will not be completed, but it is striving and reporting on OKRs with the goal of hitting 100% that helps us accomplish strong results. We score individual OKRs as "on track" when they are at least 80% complete. In aggregate, we expect that the average completion score across OKRs is 70%.
3. [Review cascading OKRs](/handbook/company/okrs/#cascading-okrs-and-how-to-align-division-okrs-to-the-ceo-okrs) first and allocate time for those. Cascading OKRs are those at the CEO level or Product Division level that need your group's contributions to be achieved. You should prioritize these first.
4. It is OK to push back on OKRs. If you can't prioritize a cascading or shared OKR due to more important work, contact the owner of the OKR and make adjustments so that it is achievable without your team's contribution, or remove it. It is OK to do this, with clear communication and collaboration. It is not acceptable to simply ignore the cascading OKR or shared OKR without clear upfront communication and prioritize other work instead.
5. When writing OKRs, follow our company guidelines on [how to write OKRs](/handbook/company/okrs/#how-to-write-okrs). In particular, focus on outcomes, not tasks, and make key results measurable.
6. For any OKR with a dependency, make sure to get [commitment on the dependency](/handbook/company/okrs/#dependency-commitments) with [shared objectives](/handbook/company/okrs/#shared-objectives). If you don't get commitment in the shared objective, make changes as needed to keep to feasible OKRs.
### Examples of good OKRs
**Objective: Establish GitLab leadership in X area.**
- Avoid ❌ KR1: GitLab X becomes available in beta, including Y functionality in beta, with a path to general availability next quarter.
- Instead ✅ KR1: GitLab X reaches 100k paid MAU by end of quarter.
- Avoid ❌ KR2: Ship 10 components to support the use of X.
- Instead ✅ KR2: 30% of GitLab users are able to use X with the components built.
This aligns with a focus on outcomes and business results instead of KRs tracking tasks or launches.
### Organizing Product OKRs in GitLab
Product Objectives and Key Results are drafted and entered into GitLab by PLT as per (/handbook/product/product-okrs/#timeline-and-process-for-every-quarter). This includes all Chief Product Officer level OKRs that the Product Division 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 Q4FY24, we are using the following organizational structure to track our OKRs in GitLab:
- R&D's OKRs
- FY24Q4 Top Priority R&D OKRs _(entered by PLT)_
- Objective 1: [high priority item A]
- KR1…
- Objective 2: [high priority item B]
- KR1…
- Objective 3: [high priority item C]
- KR1…
- Objective 4: [high priority item D]
- KR1…
- FY24Q4 Other R&D OKRs _(entered by all stage/group leaders per area)_
- Monetization & Operations
- OKR1...
- Sec & Data Science
- OKR1...
- CI/CD, Core Platform, & SaaS
- OKR1...
- Dev & Analytics
- OKR1...
## Additional Resources
- [What Matters](https://www.whatmatters.com/)
- [How to use GitLab to track OKRs](/handbook/company/okrs/#how-to-use-gitlab-for-okrs).
## Timeline and process for previous quarters
For previous quarters, please see [previous quarter OKR timelines](/handbook/product/product-processes/product-okrs/previous-quarters/)
## How to contribute to this page
We encourage suggestions and improvements to the Product 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.
{{% include "includes/joint-r-d-okr-process.md" %}}
content/handbook/product/product-processes/product-okrs/prod-okr-timeline.png

41.3 KiB

0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment