Throughout the year, the compensation and benefits team will need action from leadership and individual contributors. Below is a summary of the major events that will be coming up and affect everyone at GitLab. For more detailed information on the issues the compensation and benefits team is working on, please see the compensation issue tracker.
Summary of Events for FY 2020:
|Feb 2019||Audit CY 2018 Annual Compensation Review|
|Mar 2019||Select a Compensation Consultant|
|Apr 2019||Build Business Case for Engagement with Compensation Consultant and obtain Board Approval|
|Split Compensation and Benefits to its own team within the People Group|
|May 2019||Phase 1 of Compensation Consultant|
|Canada CXC Medical Allowance and PEO Medical Review Completed|
|Jun 2019||Phase 1 of Compensation Consultant|
|Benefits Survey Released|
|Tuition Reimbursement limit increased to 20k USD per year|
|Jul 2019||Phase 2 of Compensation Consultant|
|Benefits Survey Results Analyzed|
|Aug 2019||Phase 2 of Compensation Consultant|
|Sep 2019||Phase 3 of Compensation Consultant|
|Implement a Compensation System|
|Alignment of Titles in BambooHR|
|Oct 2019||Update Benefits Guiding Principles in Practice|
|Nov 2019||Compa Ratio Reviews|
|Dec 2019||Annual Comp Review Inputs Evaluated/Proposed to Compensation Group|
|Location Factor Review|
|Jan 2020||Annual Comp Review changes finalized for 2020-02-01 effective date|
|Manager Review (Compaas) January 8th through January 22nd|
|Manager Review (Google Spreadsheets) January 10th through January 24th|
We want our compensation to be at a level where we can recruit and retain people who meet our requirements. Our requirements for most of our job-families are at or above the average in the market. Therefore, we can expect to be at or above the 50th percentile of the survey data gathered from providers like Comptryx and Radford. Please do not use the term market rate since this can mean either competitive rate or survey data. Also see our SF benchmark.
Competitive rates for roles vary depending on regions and countries. We pay a competitive rate instead of paying the same wage for the same role in different regions. Paying the same wage in different regions would lead to:
For more context please also see our blog post about paying local rates.
We hire the best candidate for each role regardless of location, cost, or other factors. During the sourcing we do optimize what potential candidates we approach in order to bring more diversity (both geographically and people from underrepresented backgrounds) to our team.
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 a locally competitive rate.
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 competitive rate). 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 competitive 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.
Please refer to the code of conduct to review the relocation process.
We also wrote a blog post about paying local rates.
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 directors or above and anyone on a quota 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
compensation@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.
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 Compensation 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.
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 Compensation team will add an entry for each type listed within the job family. For example:
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 Compensation team is pinged on the merge request for a compensation review to start the process. The Compensation 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 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 the the compensation group after approval from the People Operations 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 compensation 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 Compensation 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.
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 compensation@domain.
The Compa Group 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 team members 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 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.
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.
The Annual Compensation Review process is currently undergoing iteration and the most up to date timeline can be reviewed in the Compensation & Benefits Schedule.
During the fourth quarter of each year, the Compensation & Benefits team will conduct a compensation review to ensure all team members are paid based on survey data in the compensation calculator. This is not a Cost of Living Adjustment, but instead a review of market changes. Location Factor and Compa Ratio 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, compa ratios 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.
View the enlarged version of the process
As part of the new Annual Compensation Review, managers will review, approve, and where necessary update the proposed salary increases to ensure that we are paying each team member to market. Please verify the compensation calculator inputs (compa group, level, title) are accurate.
It is very important that GitLab team-members understand their compa group and how it impact their salary.
While some GitLab team-members may not receive an increase due to already being at the right competitive rate for their Comp Group, 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 email compensation@ domain with the reasoning and cc your People Business Partner. 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. 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 a commendable level.
Compaas is GitLab's compensation platform where managers can login, review, change, and submit their proposed increases during Annual Compensation Review. January 2020 is the first annual compensation review using Compaas. In the past all compensation reviews have been managed in Google Spreadsheets, which is not a scalable solution. As we go through the first Manager Review in Compaas, please post your feedback in the following issue so we can iterate on the process for the next compensation review.
Individual Contributors and Managers:
The following departments will be administered through Compaas. Compaas will open to managers January 8th by the end of business Pacific Time. The cycle will close for all slate owners and approvers on January 22nd by the end of business Pacific Time.
The following Departments will be administered through Google Spreadsheets since the roles in Marketing and Sales listed are not within the compensation calculator. Managers and Indirect Managers will receive a spreadsheet to review on January 10th by 12 pm Eastern Time. All spreadsheets must be finalized on January 24th by 12 pm Eastern Time.
All directors, senior directors, and distinguished engineers will be reviewed separately in google sheets since we are changing the variable plan from 10% to 15% for directors in FY 2021. For more information on how directors will be converted over time, please review director compensation The budgetary pool will not be broken down by Division but instead as one director pool. Managers and Indirect Managers will receive a spreadsheet to review on January 10th by 12 pm Eastern Time. All spreadsheets must be finalized on January 24th by 12 pm Eastern Time. All manager input will be reviewed and approved by the compensation group before the FY 2021 compensation is finalized.
All executive and fellow compensation will be reviewed in google spreadsheets by the compensation group and, if required per role, the board.
Process for slate owners:
Process for approvers:
If you have direct reports eligible for compensation review and are in a department which is being administered through google spreadsheets you will receive an email from the compensation team with a link to this handbook section as well as your slate. If you have any indirect reports you will have two tabs that need attention: "Slate" and "Approver".
If anything on your spreadsheet is not working, has incorrect information, or a formula breaks please email compensation@ and we can review/adjust.
$ Input from Leader. This is where you as the manager can enter in the dollar amount in discretionary funds (if applicable). Please enter a value (even if $0) so your manager can see your slate has been completed. You may also want to notify your manager that your slate is ready to go.
Discretionary Approved by Comp Group, you can see the final OTE for your team member along with the dollar increase as well and percent increase in order to communicate to your direct reports. Please do not communicate any compensation numbers until you have received confirmation from the compensation team that all budgets have been approved.
$ Input from Leader. This is where you as the manager can enter in the dollar amount in discretionary funds (if applicable).
$ Input from Manager) and if you agree, enter the same value into Column U. Please enter a value (even if $0), so your manager knows your slates have been reviewed. You may also want to notify your manager that your slate and approver tab is ready to go.
Approved by Leader (or Comp Group). Please enter a number, even if it is 0. Once this number is populated, all slate and approver spreadsheets will be able to see the final result.
All increases for Annual Compensation Review will be finalized by Feb 1st. FY 2021 compensation will be uploaded into BambooHR no later than Feb 4th for payroll to make changes in all subsequent systems. The compensation team will turn off the ability to see compensation in BambooHR using Employee or Contractor Self Service from Jan 27th until Feb 13th so managers have the ability to communicate any increases to their team before the 13th.
Sample communication: "The manager review process for annual compensation review is complete. Based on your compa group evaluation of x, you are receiving an increase of x%."
If your direct report has any questions on the calculation of their increase please feel free to have them reach out to the compensation team.
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. Note: If the team member is on a variable + base plan and is not at the desired split for their role, the entire cost of living adjustment will be added to the base or variable compensation to get closer to the desired split. If the team member is at the desired split for the role, then the increase is equally divided among base and variable. This goal to get to the standard split is also applicable to any compensation adjustments that may occur outside of COLA.
For team members hired between November 1st and January 31st, participating only in the annual compensation review may mean their compensation is not reassessed for up to 15 months. GitLab has incorporated a catch up review conducted in August for anyone hired in November, December, or January of the previous year. For example, any new hires in Nov 2019 - Jan 2020 would be reviewed in August 2020.
During the annual compensation review, the budget for these team members is separated out to be used in August. If anyone would fall out of the compensation range, the team member would be adjusted immediately, but this would be deducted from the budget used in August.
No cost of living adjustments would be made at this time. This review will only take into account a compa group alignment (if any). Team members should not expect an increase, but instead understand that their comp is being reviewed to ensure alignment to market.
All changes will follow the same process as the annual compensation review timeline with an effective date of September 1st.
The compensation calculator is updated in January and July with the proper exchange rate, keeping compensation levels in line with local purchasing power.
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.
2020-01-01 Oanda Rates
|Currency||Rate from USD||Rate to USD|
Beginning in FY 2021, Directors will be brought into the compensation calculator by benchmarking off of Total Target Cash (TTC).
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 15% bonus of current base salary (increased from 10% beginning in FY 2021). 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.
To transition Directors who are on a 10% bonus plan, the following conditions will be taken into account during Annual Compensation Review:
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.