On this page, we explain the different factors that make up our Compensation Calculator and its alignment to GitLab's values and Compensation Principles.
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 embedded in every job family page but we also have a calculator that lets you select the job family.
Your compensation = SF benchmark x Location Factor x Level Factor x Compa Ratio 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.
See the calculator in action on each job description, or at its home page.
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.
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.
If you are an internal GitLab team member or external to GitLab:
If you prefer to remain anonymous:
SF benchmark is the employee 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. The SF benchmark used in each position is available in the job_families.yml file in this website's repo.
Benchmarks are determined based on the following types: Individual Contributor (IC), Manager, Director, Senior Director. The next iteration to our job families is to have the entire career progression and calculator in one place. Please see the following issue for more information on the progress. In the job_families.yml file 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:
job_families.yml file and assign to the executive of the group for approval.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 People Ops Analyst 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 Analyst 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.
As a second iteration, GitLab will review whether or not we should generate our own job codes.
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 location factors are stored in the data file on GitLab. 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:
Not all levels of each job follow this same nomenclature. A summary of the naming of levels per role can be found in role_levels.yml.
GitLab job grades aid in mapping a role for internal equity with respect to cash and equity. For example, you can see the grade for each role level and the stock options in their respective yml file. 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 |
|---|---|---|
| 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/Demand Generation:
| Grade | Management | Individual Contributor |
|---|---|---|
| 12 | VP | |
| 11 | Senior Director | |
| 10 | Director | |
| 9.5 | ||
| 9 | Manager (Sales) | |
| 8 | Manager (Demand Generation) | Enterprise & Customer Success |
| 7 | Mid Market | |
| 6 | SMB/SDR Lead & Acceleration | |
| 5 | Analyst/ SDR |
We have renamed experience factor to Compa Ratios.
As part of the first iteration towards this change, the Annual Compensation Review will still use the output of the what was previously the experience factor worksheet, but completing the worksheet itself will be optional and will generate a range instead of specific number. For example, the output would be a compa group of growing in the role, instead of an experience factor of 0.97.
In FY 2021 We will develop and release a new tool to assess compa group.
The Compa Ratio is the range spread of the base salary calculator. Specifically, the compa ratio has a 30% spread (+/- 15% from the median). It is common to see range spreads up to 50%.
If you have any questions around Compa Ratios or determining Compa Groups, please feel free to open an issue or email total-rewards@domain.
The Compa Group is determined by the direct manager for each team member, and reviewed by all indirect managers. This is officially done (and entered into BambooHR) once per year: during the Annual Compensation Review for current team members and during the offer stage for candidates. We do not typically do off-cycle compa group increases. However, this does not mean that compa groups should only be discussed annually. There should be an ongoing conversation with the team members to ensure they understand the path forward for growth and development.
This factor does not directly reflect years of work experience, but instead, demonstrated ability to drive projects and deliverables from the position description to completion within GitLab. It also does not reflect the performance of the team member in comparison to their peers. You may have a lot of top performers in your team but they won’t all necessarily have the same Compa Group. The goal of narrowing Compa Groups from Compa Ratios, as it relates to compensation, is to ensure they are accurate to work toward getting to the right salary.
If a manager is new to the team member, and has not had time to assess the Compa Group, collaboration with previous managers or colleagues is encouraged as a strong data point when assessing.
Compa Ratios are broken down into the following four Compa Groups:
Breakdown of the Compa Group mathematically:
| Compa Group | Compa Ratio Range |
|---|---|
| Learning the role | 0.85-0.924 |
| Growing in the role | 0.925-0.999 |
| Thriving in the role | 1.0-1.074 |
| Expert in the role | 1.075-1.15 |
It is important to note that deriving an compa group based on the current compensation calculator is not advised. Compa groups should be based on the knowledge, skills, and ability in the current role. Second, the output of the compensation calculator may change due to the review of all inputs. We want each team member's pay to be an accurate reflection of their market, with the caveat that we adjust once a year in order to reduce the overhead of the adjustment process.
The following is a suggested communication strategy for managers when evaluating the Compa Group of their direct report/s.
Contract Factor distinguishes between employee (1) or contractor (1.17), which can be found on the contract_factors.yml file. 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.
