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 Community 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.
📊 indicates that the KPI is operational and is embedded in the handbook next to the definition and shown publicly (can be Sisense or another system).
🔗 indicates that the KPI is operational and there is a link from the handbook to Sisense, GitLab, Bitergia, Grafana, or another system. This may be because the KPI cannot be public or because it isn't possible to embed it yet.
🚧 indicates that the KPI is in a
WIP: work in progress status estimated to be shipped in any system within the month. When using this indicator, an issue should also be linked from this page.
🐔 indicates that the 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.
We share a spreadsheet with investors called "GitLab Metrics." The GitLab Metrics Sheet should be a subset of the KPIs listed on this page. Alternatively, the sheet may show variations or subsets of one of those KPIs, such as showing all licensed users and then licensed users by product.
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 an various estimates can be: