We're an open organization and want to be transparent as we possibly can about our compensation principles and about paying local rates while not disclosing any uniquely identifying information or compensation about any individual. We've developed a compensation calculator that provides an estimate of market rates for various roles, across the globe.
This estimate includes People Operations' best judgement based on market data, feedback from current team members, and candidate data. If you have any data to demonstrate the compensation calculator is misaligned to market, please email brittany@ domain for review.
Compensation aims to be at or above market for your region, your job title, your seniority, and your experience.
We base compensation on current position, experience at GitLab, and performance, not on what we paid you last month.
When your position or title changes, we'll adjust your pay as soon as the change is made.
When your seniority or experience factor changes we'll change your pay in January.
Because your experience factor informs our pay, it should be as accurate a measurement of your individual experience level. We should not artificially manipulate the experience factor in order to achieve a desired compensation level.
If we change our standard compensation benchmark for a job family without change the requirements, we change the compensation both for existing Team Members and new hires. Sometimes benchmarks are raised along with changes or additions to the requirements, which may result in a review of Experience Factors. This review might happen at the time of the change or in our yearly cycle.
To determine your area, select the country you live in. This will filter out all areas outside of your country. Based on the remaining choices under "area," if you live within a commutable one hour and forty-five minutes of a city listed, you may use that as your location. If not, you will select "Everywhere else." If the only item listed for the country is "All," the country has the same location factor regardless of the city you live in. If applicable, a state or province might be listed instead of a city.
If your country is not listed, reach out to People Ops to gather relevant data.
We hire across the globe, but we're not location agnostic. Your timezone, the market rate in your region, and the vicinity to users, customers, and partners can all be factors. For example, we may favor one applicant over another because they live in a region with a lower market rate or because we need someone in that timezone. All things being equal, we will hire people in lower cost markets vs. higher cost markets.
As you can see from our contracts, compensation is typically set at a fixed monthly rate. People on quota (account executives, account managers, and sales leadership) have variable compensation that is about 50% of their On Target Earnings (OTE). Individual contributors in the sales organization have variable compensation that is purely based on commission. Solutions Architects currently have a lower variable component, we're not sure how this will evolve. All other people have fixed compensation (but we do have bonuses and incentives).
Compensation decisions around level and experience levels and for functions not in the calculator are taken by the compensation committee. This committee consists of the CFO, CEO, and Chief Culture Officer. When there is no time to coordinate with the committee, the CEO can make a decision and inform the committee. When the CEO is away (e.g. vacation), the two other members of the committee can make a decision and inform the committee. Whatever the decision is, the compensation committee should be cc-ed (or bcc-ed) on the final email so that the committee members can know that the loop was closed.
Employees of our Dutch entity (GitLab B.V.) will get their salary wired on the 25th of every month, and can see their pay slip in their personal portal on HR Savvy's system towards the end of the month.
Employees of our Dutch entity who are based in Belgium will get their salary wired around the last day of each month and will receive their pay slip in their personal portal on Boekfisk's system
Employees of our Dutch entity based in India that are employed through GitLab's co-employer Lyra will get their salary wired around the last day of the month. Lyra will send pay slips electronically but will be switching to a HR portal very soon so that pay slips and tax declaration forms can be accessed directly.
Employees of our US entity (GitLab Inc.) have payroll processed semi-monthly through ADP, and they can access their pay slips through the ADP portal.
Employees of our UK entity (GitLab Ltd) will get their salary wired on the last day of every month, and can see their pay slip via their personal portal on Vistra's system towards the end of the month.
Employees of CXC Australia will be paid at the end of each month and can view their pay slips on CXC's portal. Everyone is given a login by CXC as part of their onboarding.
Employees of CXC Canada are paid fortnightly and are required to submit timesheets to their managers and then CXC. Access is given to a the portal as explained in the point above.
Employees of SafeGuard are paid monthly and on the last day of the month (depending on the country). Payslips are provided electronically by SafeGuard.
Contractors to GitLab (either entity) should send their invoices for services rendered to email@example.com
For 'fixed fee' contracts, it is OK to send the invoice before the time period that it covers is over. For example, an invoice covering the period of March 1-31 can be sent around March 15.
All invoices are internally reviewed, approved, and then payment is processed. This is usually a fast process, but be aware that it can incur delays around vacations. In principal, payments go out once per week on Fridays.
An invoice template can be found as a Google sheet named "Invoice Template" (also listed on the finance page )
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.
People Operations will analyze the difference in exchange rates from January to July (or vice versa) and the effect this has on local purchasing power.
Only changes of +/- 5% will be processed in each review.
People Operations will confirm by letter of adjustment any increases or decreases to compensation as a result of this review.
Any significant increases or decreases will be reviewed on a case-by-case basis before any changes are made.
If an opt out agreement is signed, the team members will be excluded from any future Exchange Rate reviews. GitLab retains the right to revisit the opt-out status in the future.
Additionally, if a team member is impacted outside of this review period they should reach out to People Operations.
2019-01-01 Oanda Rates
Rate from USD
Rate to USD
Paying Local Rates
Why we pay local rates
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:
A concentration of team members in low-wage regions, since it is a better deal for them, while we want a geographically diverse team.
Team members in high-wage regions having less discretionary income than ones in low-wage countries with the same role.
Team members in low-wage regions being in golden handcuffs and sticking around because of the compensation even when they are unhappy. We believe that it is healthy for the company when unhappy people leave.
If we start paying everyone the highest wage our compensation costs would increase greatly, we can hire fewer people, and we would get less results.
If we start paying everyone the lowest wage we would not be able to attract and retain people in high-wage regions.
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.
Annual Compensation Review
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.
Annual Compensation Review Timeline
People Operations will review all benchmarks, rent indexes, and country factors associated with the Compensation Calculator and propose revised inputs to the Compensation Committee for approval/implementation.
2018 Deadline: November 15th - Done
People Operations will reach out the managers to obtain updated experience factors for each active team member.
People Operations will create a spreadsheet with all active team members listing the following information: employee number (for People Ops use only), name, title, and level.
Remember that this is also a good time to update your team’s position description if it does not reflect the role.
People Operations will calculate the amount of the increase for each team member and obtain approval from Finance for the total budget impact. Depending on budget constraints, the increases may be adjusted up or down. Before sending to Finance, update the exchange rates to the most recent date available.
2018 Deadline: December 17th
People Operations will generate a google sheet which will serve as a summary of increases for each department and share with all direct and indirect managers. This manager review will be the time for management to verify the compensation calculator inputs and adjust increases. While these adjustments are based on market data and experience factors, rather than performance, team members who are currently struggling to perform at their current level should have that communicated clearly and the manager should consider delaying the increase until performance reaches an commendable level.
2018 Deadline: December 21st
Managers will inform the team members of the increase.
2018 Deadline: December 31st
People Operations will stage the letters of adjustment, update BambooHR, and notify all payroll providers to be effective January 1st.
Exchange rate used for the 2018 annual compensation review is taken from Oanda on the date of 2018-11-30.
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, with the caveat that we adjust once a year in order to reduce the overhead of the adjustment process.
Cost of Living Adjustment
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 team member has not received a salary increase due to a promotion or an increase in experience factor since January 2018.
The team member was hired before October 1, 2018.
The team member's performance is at a commendable level as of November 2018.
Increases will be prorated based on hire date in 2018 as follows:
January 2018 and prior = 100%
February = 92%
March = 83%
April = 75%
May = 67%
June = 58%
July = 50%
August = 42%
September = 33%
October = not eligible
November = not eligible
December = not eligible
Annual Compensation Review and Cost of Living Adjustment
The Cost of Living Adjustment is not an additive to the Annual Compensation Review, but instead a supplement to, if necessary.
For example, if the Annual Compensation Review gave an output of a 1% increase, then the cost of living adjustment would be an additional 2% to equal 3%, taking proration into account.
If you have any questions on the breakdown of the increases in 2019, please reach out to People Ops.
Experience Factor Guidelines
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.
Use the role description, including any appropriate requirements or responsibilities, to help populate the responsibility line items in the worksheet. It is important to take all aspects of the position description into account when determining experience factor. If the position description isn't correct, use this as an opportunity to update it. Also be sure to update the soft skills section of the worksheet. The percentages are the same for each team member at GitLab, but level should be taken into account when evaluating experience.
It is a strongly recommended to complete this with the participation of your team member. There is a secondary input and formula for the team member to derive their own experience factor. This secondary input won't affect their compensation but will be used as a discussion point between the manager and the team member. At a minimum the manager should share the worksheet once the inputs are complete.
It is critical that all managers share the experience factors with the respective team member, including how they arrived at that factor. Team Members should understand where they stand in relation to the individual experience factors and weights that led to the final number.
If your manager has not yet discussed your experience factor with you, please reach out to your HR Business Partner in People Ops.
Once you have discussed the Experience Factor Worksheet and resulting final number with your team member, please add it to the file in BambooHR. This enables us to ensure that it is easy to find as a reference and discussion tool.
To add the file, login to BambooHR. Go to your team member's profile, and click on the documents tab. Upload the file to the "Experience Factor Worksheets" folder and select the option to share the file. Sharing the file will allow the team member to also view the worksheet.
The most recent feedback cycle can be a helpful tool when distinguishing the experience factor the team member is currently performing at.
Feedback reviews should not be about judging, but helping people. We do not want feedback reviews where people are holding back, so these metrics are different as experience factors are used within the compensation tool.
Use the following factors as a guideline for the inputs into the worksheet.
Learning the role
Growing in the role
Thriving in the role
Expert in the role
Explanation of Experience factors:
Learning the role (0.9-0.949): Recently promoted or new to the role. Needs a lot of guidance from the manager with the majority of tasks to understand requirements and deliverables expected.
Growing in the role (0.95-0.99): Understands most of what is expected for deliverables, but needs some guidance with tasks to drive projects to completion.
Thriving in the role (1.0-1.049): Understands all aspects of the role, needs limited guidance to drive advanced projects to completion.
Expert in the role (1.05-1.1): Understands all aspects of the role, with almost no guidance to drive projects of any complexity to completion. Once a team member becomes an expert within their current level, the next step may be promotion if a role at the next level is needed at the company.
Add the Manager Final Experience Factor Number to the "Manager Experience Factor Input 2018" on the Google Drive. Note: This doc is only viewable to managers who have a team member with a role in the compensation calculator.
If you have any questions around determining experience factors, please feel free to open an issue or email People Operations.
Experience Factors for Backend Engineer
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:
Does not yet meet expectations for the role (< 0.9). Engineers who do not currently meet the new expectations for one or more aspects of their current role may be assigned an experience factor below 0.9. This indicates that they have room to grow to meet the new requirements for the position. Their manager should work with them to prepare a clear coaching plan to help them grow as effectively as they can.
Meets expectations for the role (0.9). Engineers who satisfy each of the new expectations for their current role should at least receive an experience factor of 0.9.
Demonstrates strength in the role (1.0). Engineers who demonstrate strength above and beyond the basic expectations for the role could receive an experience factor of 1.0.
Demonstrates excellence in the role (1.1). Engineers who are exemplary in the responsibilities of their role may receive an experience factor of 1.1.
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, anyone on a quota, and executives is not set with the calculator.
The goals of the calculator are:
Calculate compensation for 200+ metro regions all over the world.
Based on a simple formula.
Based on market data.
That is as accurate as possible given the other constraints.
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 salary = SF benchmark x Location Factor x Level Factor x Experience Factor x Contract Type Factor
SF benchmark is the employee salary at an experience factor of 1.0 at or above market 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.yml file in this website's repo. The SF Benchmark is determined by using the Average of Comp Data Sources.
Location Factor is reviewed in two ways. The highest resulting value is stored in the location factor file. This double process is an iteration as we attempt gather additional resources to make our model increasingly driven by market data. People Operations will use their best judgement in determining the input per location based on our Compensation Principles.
A market analysis of compensation rates globally. People Operations will pull market rates in each Geo Area and compare the differential to SF.
Where we are not able to find the proper data to conduct the analysis, we will use the Numbeo rent index normalized to San Francisco, or in math terms, (.7 x (Rent Index/1.26) + 0.3).
Level Factor is 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 (0.8), Marketing Manager (1.0), Senior Marketing Manager (1.2).
Contract Type Factor distinguishes between employee (1) or contractor (1.17), which can be found on the contract_types.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.
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.
To ensure our location factor is reflective of the ability to commute between nearby cities, we incorporated Geographical Areas into the compensation calculator. This process is only used when we do not have the proper data to determine a location factor based on a market analysis alone.
To determine geographical areas, we looked at what the United Nations outlines globally. To determine the rent index for each country please see the following process per geographical area and country:
Research via an official website what appropriate regions are within the country/area. For example, in the United States there are four regions with nine subdivisions. In the United Kingdom, for compensation purposes, there are four different areas.
Pull all numbeo data for the region selected.
Determine any outliers for the region (on the high end). Make these separate geographical areas.
Define a commutable region for the area (1.75 hours through a google search looking at prime time commute hours).
From the remaining data points, select the highest to be used for everywhere else in the region. (Most of these data points should be very close.)
If there is a historic Numbeo number that is higher than the current Rent Index, use the historic number.
Determine if a minimum rent index should be used in the region. (This would normally occur if there is a large gap between remaining data points.)
If there is no data for a country, do not include in the comp calculator. If needed, we can review the compensation based on the region and other salary data.
If there is no data for a state/province within a country, assign the lowest value of the other states/provinces.
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.
GitLab will use market data from Advanced-HR 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 known 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.
Changing Benchmarks Based on Role Changes
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:
Production Engineer -> Site Reliability Engineer (SRE)