OKRs

OKR introduction

To track & achieve our goals, we use OKRs (objectives and key results) as our primary framework.

Hint

We’re defining, and tracking our OKRs in GitLab via issues / work items.

Roadmap

Because GitLab isn’t optimal to view all OKRs, we’ve built our own web-based Roadmap.

Note

The deployment, and all documentation for the Roadmap can be found in the GitLab roadmap project.

OKR guidelines

When defining OKRs, the following principles apply:

1. Organisation level

   OKRs are defined at the organisation level.

   They must contribute to the organisation strategy, ensuring vertical alignment across all teams.
2. Transparency

   Our OKRs are transparent, and visible to every member of the organisation.

   This fosters accountability, cross-functional awareness, and collaborative problem-solving.
3. Quarterly

   OKRs are reviewed formally at the end of each quarter.

   Scoring is used to facilitate learning and calibration, not as a performance evaluation instrument.
4. Ownership

   Every OKR must have a single designated owner.

   One individual is accountable for driving progress, removing impediments, and reporting on status.
5. Qualitative and ambitious

   Objectives must be qualitative, ambitious, and clearly articulate the desired outcome.

   They describe what we want to achieve, not how we intend to achieve it.
6. Three to five key results

   Each objective should be supported by three to five key results.

   Key results must be quantitative, time-bound and independently verifiable (see 🎯 Zen #4).
7. Outcomes and impacts

   Key results measure outcomes and impacts – not activities, or output.

   ❌ “Launch feature X” is a deliverable; ✅ “Increase customer retention by N%” is a key result.
8. Attainability

   A key result should feel achievable at roughly 70% confidence at the time of definition.

   If attainment feels certain, the ambition is insufficient; if it feels unrealistic, it risks disengagement.