Below are the current exchange rates that should be used for converting amounts found in the handbook or for the compensation calculator.
People Operations will update the exchange rates at six-month intervals using Oanda effective January 1 and July 1. Updated currency conversion amounts are then entered into BambooHR.
If you are paid in your local currency
The compensation calculator is updated in January and July with the proper exchange rate, keeping compensation levels in line with local purchasing power.
If you are not paid in your local currency
There are a number of reasons why team members may not be paid in local currency. For example, GitLab's bank might not support the currency or there may be a strong economic reason for the team member to choose a different currency. The currencies that GitLab can pay in are published on the contracts page.
2018-07-01 Oanda Rates
|Currency||Rate from USD||Rate to USD|
Market rates for roles are different for different regions and countries. We pay market rates instead of paying the same wage for the same role in different regions. Paying the same wage in different regions would lead to:
Our compensation calculator was updated in January 2018 to align closer to market rates. We believe you should be adequately compensated for not only your skill and experience levels, but also relative to the standard market salary for your position in your geographical area. We accomplish this by factoring in the employee salary at the 50th percentile for your job role in San Francisco along with the Rent Index of your metro area.
This approach should ensure that your compensation level always feels appropriate no matter where you're living, but we also recognize that simply factoring geographical location into our calculations at face value may prove problematic in very low-income areas. We've implemented a number of checks to ensure that we're being responsible and fair with how we compensate GitLabbers in these areas:
Different than business travel, vacation, or visiting a relative for a few weeks, relocation means that you will establish yourself in a new location outside of your current metro area. If you are ending your current residential living arrangement, spending more than six months in one location as part of an extensive period of travel and/or will have your mail delivered to an address in a different city please contact us.
As stated in the code of conduct section of the handbook, you should first obtain written agreement (from your manager) when planning a relocation. It is the company's discretion to offer you a contract in your new location. At the time of the location update, we will take into consideration your new metro region when making a salary offer for continued employment.
At the onset, this practice sounds harsh when moving to a lower paid region. One might argue that it seems unfair for the organization to pay someone less for the same work in the same role, regardless of where they go. However, if you look at it from another angle for a minute and compare this practice to what most companies do, it should make more sense. For example, say you work for a company with physical locations and say they haven't accepted that remote work is as productive as coming into the office yet. If you wanted to pack up and move to a location where they did not have a physical site, you would have no alternative but to resign and seek new employment in your new location. You would find quickly that companies in the area pay at local employment market rates.
Now, let's say the company did have a site in your new location and they offered the flexibility to transfer. If they did not have a similar position open, you would have to either apply for a different open position in the same company or resign and apply externally (back to the realization that other companies will pay at local market rates). If you were lucky enough that they did have a similar role in the new location, a transfer would come with a pay rate based on the local market to ensure equity across all incumbents (people in the job) by location.
Adjusting pay according to the local market in all cases is fair to everyone. We can't remain consistent if we make exceptions to the policy and allow someone to make greater than local market rate for the same work others in that region are doing (or will be hired to do). We realize we might lose a few good people over this pay policy, but being fair to all team members is not negotiable. It is a value we stand behind and take very seriously.
During the fourth quarter of each year, People Operations will conduct a compensation review to ensure all team members are paid based on market data in the compensation calculator. This is not a Cost of Living Adjustment, but instead a review of the market changes. Rent Index and Experience Factor will continue to be a part of the compensation calculator equation. The annual compensation review is not directly linked to performance reviews nor the ability to be promoted. The increase percentage may vary for each person. For instance, experience factors are reviewed as part of a compensation adjustment or promotion, which GitLab encourages to happen independently from this review. If a team member was recently adjusted, the annual adjustment might yield no additional salary during the annual compensation review. This review acts as a sweep for each team member’s compensation to be evaluated at least once per year.
As part of the new Annual Compensation Review, managers will review/approve the proposed salary increases to ensure that we are paying each team member to market. Please verify the compensation calculator inputs (experience factor, level, title) are accurate.
If you did not conduct an experience factor review with your direct report, please advise People Operations and follow the guidelines from the handbook. It is very important to you use the Experience Factor Worksheet to determine the correct final Experience Factor and to have discussions with your direct reports. It is very important that GitLabbers understand their experience factor.
While some GitLabbers may not receive an increase due to already being at the right market rate for their Experience Factors, Level, Role, and Location there are other circumstances where an increase should be avoided. If there are any reasons as to why the team member should not receive the proposed increase to be aligned with their experience and market in our calculator, please ping brittany@ domain or barbie@ domain in the manager worksheet and add your comments in the “reasoning” cell. This could be due to a current performance issue, pending termination, etc. If you would like to delay the increase, please outline a proposed plan of action and deadline.
Additionally, it is important to note that deriving an experience factor based on the current compensation calculator is not advised. Experience factors 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.
For positions in the compensation calculator, each eligible team member will receive at least a prorated 3% increase in base salary as a Cost of Living Adjustment.
The experience factor is determined by the direct manager for each team member, and reviewed by all indirect managers. This should be done at least once per year for current employees and during the offer stage for candidates. 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. The goal of quantifying experience factors, as it relates to compensation, is to ensure they are accurate to work toward getting to the right salary. Experience Factors should also be used in coaching and developing team members.
If a manager is new to the team member, and has not had time to assess the experience factor, collaboration with previous managers or colleagues to determine the person’s skills is encouraged. This can serve as a strong data point when assessing experience factors.
Determining Experience Factor:
|Learning the role||0.9-0.949|
|Growing in the role||0.95-0.99|
|Thriving in the role||1.0-1.049|
|Expert in the role||1.05-1.1|
Explanation of Experience factors:
For additional guidance on how to determine an experience factor, please see the Experience Factor Training on the Google Drive.
If you have any questions around determining experience factors, please feel free to open an issue or email People Operations.
Because of the role change from Developer -> Backend Engineer, the experience factor range for existing Backend Engineers is a little different. Instead of the definitions above, Backend Engineers are assessed based on how well they fulfill the requirements for their position:
As a natural extension of the Compensation Principles outlined above, and our commitment to transparency, sharing, efficiency, directness, and boring solutions (amongst other values), we developed a Compensation Calculator that we are rolling out for those roles in which we have the most contributors, and thus for whom the question about "what is fair compensation" comes up most frequently. The compensation of directors and executives is not set with the calculator.
The goals of the calculator are:
As with all things at GitLab, the compensation calculator is a constant work in progress. Please send an email to
peopleops@ company domain if/when you find a big difference between what the calculator suggests vs. what market data indicates. Please make sure to include all relevant links and data.
Your compensation =
SF benchmark x
(0.7 x (max (0.2, Rent Index + Hot Market Adjustment) / 1.26) + 0.30) x
Level Factor x
Experience Factor x
Contract Type Factor x
SF benchmarkis the employee salary at an experience factor of 1.0 at the 50th percentile for the role in San Francisco, which we determine using various sources of market data including AdvancedHr, LinkedIn, Glassdoor, Paysa, Payscale and Comptryx. The SF benchmark used in each position is available in the
roles.ymlfile in this website's repo. The SF Benchmark is determined by using the Median of Comp Data Sources.
Rent Indexis taken from Numbeo, which expresses the ratio of cost of rent in many metro areas to the average cost of rent in New York City (i.e. Rent Index in New York = 1.00). By dividing by 1.26, we normalize the rent index to San Francisco. A minimum rent index of 0.2 has been instituted so no one is paid less than 41% of San Francisco's market. We multiply the Rent Index by 0.7 and then add 0.3, so the sum would equal 1, i.e. in San Francisco you make San Francisco's benchmark. In addition, we added the full list of rent indices used is stored in the
Hot Market Adjustmentis an adjustment to any US based metro area to recognize that "hot markets" tend to have a Rent Index that is trailing (i.e. lower than) what one would expect based on compensation rates in the area. It is currently based on the US Census Bureau's top 15 of fastest growing cities larger than 50,000 residents. We found that hot markets are represented by high growth in the top 15 cities with the largest numeric increase as well as the top 15 fastest growing cities and towns. We speculate that in the short term the existing housing supply in the core of the metro area is not flexible, so growth shows up in the suburbs as well as population increase. We add a factor of 0.1 for every suburb mentioned in the list for a given metro area. We decided on using a constant factor instead of (for example) the actual rate of growth of the city since we are trying to capture the truly top hot markets while not overrepresenting the accuracy of the approach. We look at how many times a city is mentioned in each list and take the larger of the two numbers. For example, if Dallas, TX (or its suburb) is mentioned three times in the fastest growing list and only twice in the numeric increase list, we would add a factor of 0.3.
Level Factoris currently defined as junior (0.8), intermediate (1.0), senior (1.2), staff (1.4), or manager (1.4). Marketing specific level factors are Associate and BDR/SDR (0.8), Marketing Manager and Senior BDR/Senior SDR (1.0), Senior Marketing Manager and Lead BDR/Lead SDR (1.2).
Experience Factorfalls between 0.9 - 1.1
Country Factoris a ratio of the comp calc to market data; it is not a bottom up assertion of cost to employer. This can be a different factor in each country; see below for further explanation. The full list of country factors is stored in the
Contract Type Factordistinguishes between employee (1) or contractor (1.17), which can be found on the
contract_types.ymlfile. 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.
See the calculator in action for example for the Developer role, on the Backend Engineer job description.
To convert USD to local currency, we use the January 1 and July 1 Oanda exchange rates.
The compensation calculator is a tool to assist People Operations 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.
In developing the compensation formula above, we looked at the compensation of our team members which had been set in the past (without the formula), and found out that there was a statistically significant correlation between compensation and the factors that are now in the formula. We purposefully chose to look for correlations with metrics that are probably causal and definitely relevant in people's lives (the rent!). This also has the advantage of letting us work with data that is readily available publicly, as opposed to trying to scour the web for market compensation rates for all roles in all locations. Perhaps surprisingly, there was a stronger correlation between compensation and rent index than with the more general cost of living index available through Numbeo (or the cost of living with rent index, for that matter); and so we moved ahead with the Rent Index. The goal of the calculator is not to compensate people for their cost of living, the goal is to offer market rate compensation, and rent is a better indicator of that than cost of living.
As we gathered feedback from the compensation calculator, we realized in some cities that are not major metro areas, the calculator would come in low. To broaden our rent index data points, we incorporated Geographical Areas into the compensation calculator.
To determine geographical areas, we looked at what the United Nations outlines globally. To determine the rent indexes for each country please see the following process per geographical area and country:
Note: The Compensation Calculator lists out metro areas or states for user interface clarity, but the process above is followed for each region, not per state.
This list will be expanded as we gain more experience with the calculator.
All country factors can be seen in our repository.
Process for Determining Country Factor:
Comptryx Benchmarkdivided by
Compensation Calculator Modelfor each position in the country. Note: If no data is available from Comptryx, we use Payscale data instead but add an additional factor of 0.15 to the multiplier. This is based on a comparison between Comptryx and Payscale data for locations where both are available.
GitLab will use market data from Advanced-HR, specific to a Post Series C company, in order to generate offers and conduct a market review for Director level and above. Where market data is not available in the candidate or team member’s location, the People Operations Analyst will provide the Compensation Committee with an output using the location differential in the compensation calculator.
In addition to base compensation, Directors who are not already enrolled in the Sales Compensation Plan or other performance incentive plan are eligible for a 10% bonus of current base salary. The bonus will be paid out semi-annually solely based on Company performance against Plan targets, approved by the Board of Directors. The Director bonus will be pro rated for those team members who start after Jan 1st, or are promoted after July 1st. In addition, the team member must be actively employed by GitLab at the time of payout.
When pulling market data from Advanced-HR, the People Operations Analyst will provide the 50th percentile (or average if not available), in base pay and total target pay. Other data sources such as LinkedIn, Glassdoor, or Payscale may be used when market data is not available to cross check the compensation calculator output.
When hiring for a Director level or above position, the recruiters should tag the People Ops Analyst early on in the process to provide the relevant data.
GitLab reserves the right to change or discontinue the bonus program at any time. All bonus payouts are discretionary and require the achieving of specific company results that will be communicated each year.
Whenever a new role is established, a new benchmark must also be determined. The People Ops Analyst is pinged on the merge request for a compensation review to start the process. The People Ops Analyst should ensure that they 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 job in order to identify the external market rate for each benchmark positions. Sources like Comptryx, Payscale, Paysa, LinkedIn and Glassdoor are some of the sources used to determine salary benchmarks. 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. A review of the Median against the average will be reviewed to ensure there is no large discrepancy with the proposed benchmark. What is the Mean - The mean is the same thing as the average. It is the result of dividing the sum of two or more values by the number of values. So (a+b+c)/3= the mean or average. What is the Median - The median, otherwise knows as the midpoint, is a very common term used in compensation and preferred to the mean. In its simplest terms, the median is the middle value of a series of values laid out in numerical order. It's the middle point of the data set. Half of the values will be less than the median, and half will be higher than the median. To review the Compensation Benchmark process please refer to the New Roles Creation.
Sometimes the requirements of a role 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 rate has not necessarily changed. This means that everyone on that benchmark does not get an automatic raise at the next compensation adjustment period.
However, we want everyone who works at GitLab prior to a role requirement change to the have the same opportunity as new hires. So what we do is dial down everyone's experience factor as they transition from the old role to the new one and ensure that their salary remains the same. They and their manager can then immediately begin technical and career development using the new role requirements. The manager can request an experience factor adjustment at the next opportunity. 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 recent or ongoing examples are: