Here is the standard, company-wide process for OKRs. Engineering has some small deviations from (and extensions to) this process.
All of our past OKRs are available to the public HERE.
The source of truth for GitLab OKRs and KRs is GitLab. CTO objectives and KRs are aligned to CEO OKRs on this page.
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. As our quarters use calendar months, and our product development means we release every month on the 22nd, 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 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 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 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 CEO OKR timeline, and drafting should begin based on top business need including top initiatives, 3 year strategy, and especially FY direction.
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, which includes OKR examples and additional resources.
We will use the following guidelines for consistency.
For instructions, please refer to the "How to use GitLab for OKRs" section on the OKR page.
Some specific guidance:
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.
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 CEO OKRs that are not CTO aligned, follow the guidelines in this section, then CEO alignment.
Using a hypothetical example:
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.
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:
vp-developmentlabel if the VP of Development needs to track on it.
If you would like a video walkthrough, team members can view this private video.
As GitLab objectives can only have one parent, there are various options to track OKR progress for a specific department, sub-department, or team:
gitlab-orgissue 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.
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:
At this time, there is no automatic scoring from GitLab issues. All OKRs need to be updated either manually or through rollup scoring.
This process should begin on the first day of the subsequent quarter, and complete no later than two weeks after.
@mention your direct report DRI and ensure retrospection is captured in that OKR object.
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. 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.