Every part of GitLab has Key Performance Indicators (KPIs) linked to the company OKRs. Avoid the term metric where we can be more explicit. Use KPI instead. A function's KPIs are owned by the respective member of e-group. A function may have many performance indicators (PIs) they track and not all of them will be KPIs. KPIs should be a subset of PIs and used to indicate the most important PIs to be surfaced to leadership.
The KPI definition should be in the most relevant part of the handbook which is organized by function and results. In the definition, it should mention what the canonical source is for this indicator. Where there are formulas, include those as well. Goals related to KPIs should co-exist with the definition. For example, "Wider community contributions per release" should be in the Developer Relations part of the handbook and "Average days to hire" should be in the Talent Acquisition part of the handbook.
The icons below are relevant for Phase 1 and can be assigned by anyone at GitLab.
📊 KPI is operational, public, and embedded in the GitLab Handbook next to the definition.
🔗 KPI is operational, links to another system because the KPI is internal or can't be embedded in the GitLab Handbook yet.
🔒 KPI is operational, links to a limited access system.
🚧 KPI is WIP: work in progress and estimated to be operational within a month. Should include a link to an issue.
🐔 KPI is unlikely to be operationalized in the near term.
GitLab KPIs are duplicates of goals of the reports further down this page. GitLab KPIs are the 10 most important indicators of company performance, and the most important KPI is Net ARR. We review these at each quarterly meeting of the Board of Directors. These KPIs are determined by a combination of their stand alone importance to the company and the amount of management focus devoted to improving the metric.
Sales KPIs are Not Public and documented in the Internal handbook.
GitLab team members can access and update all Product performance indicators within the internal handbook via Okta > GitLab Internal Handbook
We do satisfaction scope on a scale of 1 to 5 how satisfied people are with the experience. We don’t use NPS since that cuts off certain scores and we want to preserve fidelity. We have the following abbreviation letter before SAT, please don’t use SAT without letter before to specify it:
Since we track retention in a lot of ways, we should never refer to just "Retention" without indicating what kind of retention. We track:
We have KPIs at many different layers.
KPIs can only exist at the Company (e.g. GitLab) layer if it exists at the functional layer. In other words, GitLab KPIs are duplicates of KPIs of the executives. Not all functional KPIs are GitLab KPIs but all GitLab KPIs are functional KPIs.
As GitLab grows, this will also be true throughout the layers. Not all departmental KPIs will be functional KPIs but all functional KPIs will be department KPIs. This will cascade throughout the organization, as all job families will have performance indicators associated with them.
The KPI Index captures the company, functional, and departmental KPIs since these are the three highest layers.
The only exception to this is where the filter on a KPI may change. For example, the GitLab KPI may be "Hires vs Plan" but the Engineering KPI may be "Engineering Hires vs Plan". The logic is the same, but the filter changes.
A KPI or metric consists of multiple things:
In the doc 'GitLab Metrics at IPO' are the KPIs that we may share publicly. All KPIs have a public definition, goal, and job family links. The actual performance and various estimates can be:
