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 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.
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. 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. 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.ymlfile 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.
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 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.
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.
|9.5||Manager, Product||Principal Product Manager|
Senior Product Manager
Senior Manager (Sales)
|8||Manager (Demand Generation)||Enterprise & Customer Success|
|6||SMB/SDR Lead & Acceleration|
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.
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%.