KPIs

What are KPIs

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.

KPI Index

Legend

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

GitLab’s North Star metric is run-rate revenue. In addition, there are other 10 other top KPIs.

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.

1. Revenue vs. plan (lagging)
2. R&D Overall MR Rate (leading)
3. Estimated Combined Monthly Active Users (CMAU) (leading)
4. Net New Business Pipeline Created ($s) 🐔 (leading)
5. Pipeline coverage start of quarter stage 3+ (leading)
6. Percent of Ramped Reps at or Above Quota (lagging)
7. Net Retention (lagging)
8. Gross Retention (lagging)
9. 12 Month Team Member Voluntary Retention (lagging)
10. Unique Wider Community Contributors per Month (lagging)

Office of the CEO KPIs

Sales KPIs

Sales KPIs are Not Public and documented in the Internal handbook.

Marketing KPIs

1. Net New Business Pipeline Created 🐔
2. Social Media Followers 🐔
3. New Unique Web Visitors (about.gitlab.com) 🐔
4. Total Web Sessions (about.gitlab.com) 🐔
5. New hire location factor - Marketing 🐔
6. Pipeline coverage 🐔
7. Lead follow-up response time 🐔
8. Qty. of Case Studies published per month 🐔
9. 50% or more SOV compared to most published competitor 🐔
10. Total number of MQLs by month 🔗
11. Product Downloads 🔗

Developer Relations Department KPIs

1. Unique Wider Community Contributors per Month (target: Above 170 contributors per month) 🐔
2. Wider Community merged MRs per release 🐔
3. Developer Relations Monthly Outreach 🐔
4. Active Community Members 🐔
5. GitLab for Education Quarterly Active Seats 🐔
6. MRARR (target: Identified in Tableau Chart) 🔗

People Group KPIs

People Success KPIs

1. Diversity - Women at GitLab 🐔
2. Diversity - Women in Management 🐔
3. Diversity - Women in Leadership Roles 🐔
4. Diversity - URG Ethnicity 🐔
5. Diversity - URG Ethnicity in Management 🐔
6. Diversity - URG Ethnicity in Leadership Roles 🐔
7. Percent of Population in NORAM 🐔
8. Discretionary Bonuses - Average 3 Month Rate 🐔
9. Onboarding Satisfaction (OSAT) - Average 3 Month Score (target: 4.5) 🐔
10. Team Member Turnover (Rolling 12 Months) 🔗
11. Turnover - Regrettable (Rolling 12 Months) 🔗
12. Pay Equality 🐔
13. Percent of team members outside compensation band 🐔

Finance KPIs

Finance Team KPIs - Reported in Key Review

1. Recurring revenue variance ex-JV 🐔
2. Expense variance excluding CR 🐔
3. Billing variance 🐔
4. Days to financial close 🐔
5. \% of journal entries automated 🐔
6. On-Boarding CSAT 🐔
7. Deliver Annualized Savings 🐔
8. Accounting Efficiency (FY23 Plan) 🐔
9. Data Monthly Active Users (FY23 Plan) (target: 1000) 🐔

Product KPIs

GitLab team members can access and update all Product performance indicators within the internal handbook via Okta > GitLab Internal Handbook

Engineering KPIs

1. Engineering Handbook MR Rate (target: Greater than 0.55 per person per month) 🐔
2. Engineering Team Member Retention (target: at or above 84%) 🔗
3. Engineering Vacancy Time to Fill (target: at or below 50 days) 🐔

Customer Support Department KPIs

1. Support Satisfaction (SSAT) (target: At or above 95%) 🐔
2. Manager to customer support rep ratio (target: The target for this metric is at or below 10:1) 🐔
3. Service Level Agreement (SLA) (target: At or above 95% to Priority Support SLAs) 🔗
4. Data Privacy Requests - Service Level Agreement (SLA) (target: At or above 95% SLAs) 🔗
5. Customer Support Margin (target: Headcount and non-headcount expenses to be at or below 10% of ARR) 🐔
6. Customer Wait Times (target: At or below 35%) 🐔
7. Support Handbook MR Rate (target: 0.5) 🐔
8. Support MR Rate (target: At or above 1 MRs per Month) 🐔
9. Support Team Member Retention (target: at or above 84%) 🔗
10. Support Average Age of Open Positions (target: at or below 50 days) 🐔

Development Department KPIs

1. Past Due InfraDev Issues (target: At or below 5 issues) 🐔
2. Past Due Security Issues (target: At or below 20 issues) 🐔
3. Open MR Review Time (OMRT) (target: At or below 21) 🐔
4. Development Team Member Retention (target: at or above 84%) 🔗
5. Development Average Age of Open Positions (target: at or below 50 days) 🐔

Infrastructure Department KPIs

1. GitLab.com Availability SLO (target: equal or greater than 99.80%) 🔗
2. Corrective Action SLO (target: below 0) 🔗
3. Master Pipeline Stability (target: Above 95%) 🔗
4. Merge request pipeline duration (target: Below 45 minutes) 🔗
5. S1 Open Customer Bug Age (OCBA) (target: Below 30 days) 🔗
6. S2 Open Customer Bug Age (OCBA) (target: Below 250) 🔗
7. Quality Team Member Retention (target: at or above 84%) 🔗
8. Infrastructure Team Member Retention (target: at or above 84%) 🔗

UX Department KPIs

1. Total open UX bug issues by severity (target: 0 S1/S2 issues behind the SLA due date; reduction in total volume over time) 🐔
2. Technical Writer MR Rate (target: 55 MRs per technical writer per month) 🐔
3. Average research projects per Product Designer (target: At or greater than 2 validation issues per Product Designer per quarter) 🐔
4. Product Design MR review volume (target: At or greater than 7 MR Reviews per Product Designer per month.) 🐔
5. UX Team Member Retention (target: at or above 84%) 🐔
6. UX Average Age of Open Positions (target: at or below 50 days) 🐔

Satisfaction

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:

• C = unused since customer is ambiguous (can mean product or support, not all users are customers)
• E = unused since employee is used by other companies but not by us
• I = Interviewee (would you recommend applying here)
• L = Leadership (as an executive with dedicated administrative support, how is your executive administrative support received)
• O = Onboarding (how was your onboarding experience)
• P = Product (would you recommend GitLab the product)
• S = Support (would you recommend our support followup)
• T = Team-members (would you recommend working here)

Retention

Since we track retention in a lot of ways, we should never refer to just “Retention” without indicating what kind of retention. We track:

• Net Retention
• Gross Retention
• User Retention
• Team Member Retention

Layers of KPIs

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.

Parts of a KPI

A KPI or metric consists of multiple things:

1. Definition: What is the data source? How is it calculated? What fields are included? What caveats are considered? Why is it chosen?
   • Note: Please see Infrastructure Hosting Cost per MAU as an example.
2. Target: What we strive to be above, e.g. ARR has a target
3. Cap: What we strive to be below, e.g. Turnover has a cap
4. Job family: link to job families with this as a performance indicator
5. Plan: what we have in our yearly plan
6. Commit: the most negative it will be
7. 50/50: the median estimate, 50% chance of being lower and higher
8. Best case: the most positive it will be
9. Forecast: what we use in our rolling 4 quarter forecast
10. Actual: what the number is

What is public?

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:

1. Live reported
2. Quarterly reported
3. Private