On this page, we explain the different factors that make up our Compensation Calculator and its alignment to GitLab's values and Compensation Principles.
For any questions relating to the compensation calculator, reach out to Total Rewards.
As a natural extension of the Compensation Principles outlined above and our commitment to transparency, sharing, efficiency, directness, and boring solutions (see our values) we developed a Compensation Calculator. The compensation of executives and anyone on a quota is not set with the calculator. We use a Compensation Calculator because it help us align compensation to our values:
The goals of the calculator are:
The calculator is available to internal team members using the following link.
You can use the calculator to determine the overall Total Rewards Package Offered by GitLab (Cash + Equity + Benefits). You can also use the following spreadsheet by making a copy and adding in your specific information to calculate the GitLab Total Rewards annual amount.
Your compensation = SF benchmark x Location Factor x Level Factor x Contract Factor x Exchange Rate
The calculator will output the amount as base + variable = total target cash (TTC)
Your options can be found on stock options and benefits can be found on relevant entity specific benefits pages.
The compensation calculator is updated in January and July with the proper exchange rate, keeping compensation levels in line with local purchasing power.
The compensation calculator is a tool to assist the Total Rewards team in determining a compensation package for new and existing team members. The results of the calculator are not binding. Written correspondence through a contract or letter of adjustment specify all official compensation changes. We reserve the right to change the calculator at any point in time.
As with all things at GitLab, the compensation calculator is a constant work in progress. There are a few options for reporting a discrepancy if you find the calculator isn't outputting data that is true to market.
If you are an internal GitLab team member or external to GitLab:
If you prefer to remain anonymous:
Previously, our compensation calculator and processes (percentage changes from compensation review, relocations, currency fluctuations, etc.) produced numbers that were exact, sometimes down to the dollar and cents. To make the numbers more digestible, we are implementing a practice to round up compensation in the local currency to the nearest hundredth. This rounding practice applies to future compensation changes from July 2020 onwards.
SF benchmark is the team member compensation at a compa ratio of 1.0 at or above market for the role in San Francisco, which we determine using various sources of survey data: Radford, Comptryx, AdvancedHR. We only use crowd sourced data (Paysa, Payscale, etc) when no survey data is available.
Benchmarks are determined based on the following types: Individual Contributor (IC), Manager, Director, Senior Director. The Total Rewards team will add an entry for each type listed within the job family. For example:
ic_ttc:
compensation: 100000
percentage_variable: 0
from_base: true
manager_ttc:
compensation: 140000
percentage_variable: 0
from_base: true
director_ttc:
compensation: 180000
percentage_variable: 0.15
from_base: true
senior_director_ttc:
compensation: 220000
percentage_variable: 0.15
from_base: true
Note: Where there is no variable component offered (ICs and Managers) GitLab runs the benchmark evaluation off of base salary only. Where there is a variable component offered, GitLab runs the benchmark evaluation off of Total Target Case (TTC).
Benchmarks are evaluated annually as part of the Annual Compensation Review process. Benchmarks can also be adjusted as needed throughout the year.
To analyze benchmarks:
Whenever a new role is established, a new benchmark must also be determined. The Total Rewards team is pinged on the merge request for a compensation review to start the process. The Total Rewards team should ensure that the request is not for a role that already exists and has a benchmark.
Compensation Benchmarking is the process of using internal job descriptions to match salary survey jobs in order to identify the external survey data for each benchmark positions. Compensation data can fluctuate from very high salary data to very low salary data for roles that have the same or similar job titles. Example would be Field Marketing Manager. A Field Marketing Manager at GitLab or another SaaS or Technology company salary benchmarks would and can be included with Field Marketing Manager for other Non Technology companies, as an example RedBull. Though they have the same "title" the role, scope and salaries for these roles are very different. Based on these variants in comp data we will look at the relevant comp data for each role and use the median for the benchmark.
Each new job family will be assigned a job code and evaluated through the same process as for existing role.
To review the Compensation Benchmark process please refer to the New Roles Creation.
As stated in competitive rate we want to recruit and retain people who meet our requirements. If more than 20% of the people do not accept our offers stating compensation as a reason this is an indication we're not offering a competitive rate. In this case the Total Rewards team can review the compensation. During this review, we do not look to target at a certain percentile, but instead look at market rates and declined candidate offers when adjusting. A business case should be presented to the compensation group after approval from the Total Rewards team in a google sheet with market data, candidate expectations, an impact to the current team; and in a google doc outlining the problem statement, likely cause, what the department has already tried, and an overall proposal which clarifies the budgetary impact.
If we change our SF benchmark for a job family without changing the requirements, we change the compensation both for existing team members and new hires. If the SF benchmark is changed together with the requirements this review might happen at the time of the change or in our yearly cycle.
Sometimes the requirements of a job family change. Usually this means the requirements become more restrictive as the complexity of our project and services demands more–or more specific–experience. This is different from a market adjustment because the market has not necessarily changed. This means that everyone on that benchmark does not get an automatic raise.
However, we want everyone who works at GitLab prior to a role requirement change to the have the same opportunity as new hires. They and their manager can then immediately begin technical and career development using the new role requirements. Promotions against this new criteria can also be requested on their own cadence.
It's not necessary, but it's easier for the organization to digest a benchmark change resulting from changes in a job's requirements if the name of the role changes as well. Two examples are:
To automate the process of pulling survey data from Comptryx and Radford to review benchmarks, GitLab has mapped each job title with a corresponding job code. As a first iteration GitLab will use the job codes Radford has outlined. Each job family and level must have a unique job code. The following structure is used:
For example: Backend Engineer = 5163 Senior Backend Engineer = 5164 Distribution Engineer = 5163A Senior Distribution Engineer = 5164A
All current job codes can be found by the Total Rewards team in the "Job Codes" google sheet on the Final Job Code Tab.
Location Factor is calculated using multiple data sources to conduct a market analysis of compensation rates globally: Economic Research Institute (ERI), Numbeo, Comptryx, Radford, Robert Half, and Dice. This is not a cost of living analysis, but instead a cost of market evaluation compared to San Francisco. The Total Rewards team will use their best judgement in determining the input per location based on our Compensation Principles.
The location factor depends on your geographical area. To determine geographical areas as it relates to compensation, we looked at what the United Nations outlines globally.
To determine your area:
GitLab will gather and analyze the data for each location factor annually as part of annual compensation review. We will also iterate on location factors as needed throughout the year.
(.7 x (Rent Index/1.26) + 0.3).
Level Factor is currently defined as:
The nomenclature can be adjusted for each job family to ensure the appropriate level to select is clear.
GitLab job grades aid in mapping a role for internal equity with respect to cash and equity. For example, if there is a stock option update, this mapping can act as a reference to update the compensation calculator for the various roles to ensure alignment. Job Grades can also provide an alternative path to finding the current number of options offered without having to fill out the compensation calculator.
Professional/Technology:
| Grade | Management | Individual Contributor |
|---|---|---|
| 15 | CEO | |
| 14 | EVP/CXO | |
| 12 | VP | Fellow |
| 11 | Senior Director | |
| 10 | Director | Distinguished |
| 9.5 | Manager, Product | Principal Product Manager |
| 9 | Senior Manager | Principal Senior Product Manager |
| 8 | Manager | Staff Product Manager Consultant |
| 7 | Senior | |
| 6 | Intermediate | |
| 5 | Junior | |
| 4 | Intern |
Sales/Sales Development:
| Grade | Management | Individual Contributor |
|---|---|---|
| 15 | CEO | |
| 14 | EVP/CXO | |
| 12 | VP | |
| 11 | Senior Director | |
| 10 | Director | |
| 9.5 | ||
| 9 | Manager (Sales) Senior Manager (Sales) |
|
| 8 | Manager (Demand Generation) | Enterprise & Customer Success |
| 7 | Mid Market | |
| 6 | SMB/SDR Lead & Acceleration | |
| 5 | Analyst/ SDR |
Contract Factor distinguishes between employee (1) or contractor (1.17). A contractor may bear the costs of their own health insurance, social security taxes and so forth, leading to a 17% higher compensation for the contractor. Visit our contracts page to learn more about the different types of contracts we offer.
Compa Ratio is a term used internally in the Total Rewards team to evaluate Pay Equality.
The Compa Ratio where within the range spread a team member falls in the calculator. Specifically, the GitLab compensation calculator has a 40% spread (+/- 20% from the median). It is common to see range spreads up to 50%.
