Just to be clear: the calculator takes Level, Experience, and Location into account. If the candidate and recruiter arrive at different numbers while typing into the calculator, then there is apparently miscommunication about one or more of those factors. But being asked to agree to something that is lower than what comes out of the calculator is just not something we do at GitLab. If it came across that way then something got lost in the communication.
Matt, since I deal with the comp calculator every now and then, if you'd like to provide more specifics of your situation, can you please email me on ernst@gitlab.com ?
I want to second this, we should never ask people to agree to something below the calculator. But of course the applicant and the interviewer might disagree about the appropriate title and experience factor for a candidate.
We have to decline 200 applicants a week at GitLab. We realize that interviewing is very stressful. We send a survey afterwards to get a net promoter score. The current average is 4.2 out of 5 for people that did not sign with us. Most applicants don't fill out the survey, we're not sure how that influences results.
You are saying most people don't do the survey and I think also most would think it matters how they rate the company for their own future prospects. 4.2 is actually pretty low considering this.
If you're actually calculating an NPS, the non-respondents should be considered detractors for a more accurate rating. Happy to talk more if you're interested (have done a lot of this as a user researcher).
Your calculator would probably need to be updated? I just tried it out and the difference between the locations Mumbai and Bangalore, the latter is close to 2.5x less than Mumbai (0.08 vs 0.20).
Your data-source for this is very clearly wrong.. any income/cost-of-living report for India will show that the cost of living is the same for these 2 cities.
amyjess, thanks for pointing out the CBSA; I'll admit I had not seen it before. When we set out to develop the calculator we wanted it to work globally, and focused on that. This will be a helpful way to improve it specifically in the US, so I'm adding it to https://gitlab.com/gitlab-com/organization/issues/24
You are right that we used compensation from before we had the systematic formula. However, we then repeated the exercise (of finding linear correlations with various COL indices) when we had a larger cohort but before the formula had been implemented systematically, and it still pointed to the use of the Rent Index instead of another index.
You're also right that we need the calculator to work worldwide, and I suspect that that may be part of the reason here that the calculator works well on that scale and then not always as well as it should on more local scales. We'll continue to explore how to get better on both scales; the challenge is always that we want to keep things as simple as possible also.
I've made two issues based on your comment here and the one where you shared specific data for Sacramento (thanks for that!):
BTW, I know I've been kind of hard (fair, I think, but not gentle) on you guys in this thread, and I want you to know that I really appreciate how well you've taken it and how responsive you've been.
Would love to get more input from you to make sure the calculator reaches its goal of providing fair market compensation in your location. Can you please send me an email to let me know your city and whatever further data you are willing to share? ernst@gitlab.com
My local city, but the data isn't so much mine as data that the US government shares.
Sacramento, CA.
Mean Salary (per latest BLS data) [0] for Software Developer, Applications: $107,540; for Web Developer: $78,050
Sacramento, CA Gitlab locality pay index: 0.39+0.25=0.51
Vs.
New York City, same BLS figures [1]: $108,770/$81,430
NYC Gitlab locality pay index: 1.00+0.25=1.25
Sac/NYC Salary Ratio (BLS): 0.989/0.958
Sac/NYC Salary Ratio (Gitlab): 0.512
Fundamentally, the rent index based methodology you are using is, I would guess, giving you below market pay almost everywhere that isn't NYC or San Francisco, assuming that you've hit the market wage for the skills you are targeting in your NYC baseline.
I'm not sure what it is about small Midwestern cities but the calculator seems to dislike them. The calculated rates for Cincinnati are roughly half of market rate here. I understand the calculator will not be perfect in every city worldwide but it might be better to have no calculator as the current one is extremely discouraging even though I like GitLab.
It's based on rent. Each city is punished in proportion to how much cheaper its rent is than the rent in NYC. As NYC is one of the top 5 most expensive cities worldwide for real estate [0], any city marginally more reasonable is going to get pummeled.
Perhaps it's that there is lots of cheap housing in the suburbs here, and in the greater metro area but that is outside the city proper. But most of the tech / startup activity ie concentrated in one small gentrifying neighborhood where rent is much higher (+50–100%), so coincidentally people in tech aren't buying those houses because the commute is so far from the core.
I wonder if any of these indexes breaks down a city by zip code. A good analogy for here would be if you averaged all rent over the neighborhoods in Brooklyn then used that number for a bunch of candidates in Williamsburg.
It really penalizes living in a third- / fourth-tier startup hub, for example, vs either a first- / second-tier hub or a non-hub.
Taken from another perspective maybe it's an intentional filter on the candidate pool to specific cities or countries. That wouldn't seem to be consistent with most remote philosophies but it's something to consider.
Interestingly, Buffer's salary calculator is almost the opposite with a relatively small percentage difference between Nashville or Austin vs SF or NYC for instance.
Correction: even though the ratio calculated from it and the calculation for it are correct, I somehow mistyped the Sacramento locality index, which is 0.64, not 0.51.
Didn't notice it until after the edit window was closed.
I sent you a more detailed email, but basically it is preposterous to assume a "very experienced" senior engineer in ANY part of the United States is going to be happy with making $65K.
Exactly this. A very experienced engineer who is capable of working remote will likely be pretty intelligent. They'll realize a company is attempting to steal the surplus they created by living a low-cost lifestyle. I don't really understand why a company feels they have any claim to this.
Remote employees who are good at being remote have some very good options at this point of their career. Why the heck would they take less money simply because they had the foresight to move to a low cost of living location? Half the (stellar) people seeking remote work have built their entire lives around this fact - and have made very conscious decisions regarding their career and lifestyle.
Obviously it's working out for Gitlab, but I can't imagine any of my senior remote talent finding this acceptable in any way. I guess I could see it working for a couple years "converting" an engineer who is super excited to move into remote work vs. on-site. But beyond that, this policy seems extremely dangerous to me.
This is precisely what turned me off applying for a job at Gitlab after initially being hugely enthusiastic. My family and I moved away from London to the city we grew up in to save some money, partly because I knew I could work remote for the same sort of money I had been making while paying considerably less on rent and living expenses. The cost of living adjustments Gitlab do would mean entirely negating that benefit.
I'm not really sure what the justification for CoL adjustments is, beyond "we can get away with it". Apparently I'm worth paying $120,000 working from home in London, but if I move 70 miles south I'm worth half that. Not only does it make little sense logically, there's no way cost of living here is less than half that in London, so its not even calculated correctly.
It's definitely not our intent to pay below market in any location. If our calculator shows a large negative adjustment from your current compensation, please send me an email (ernst@gitlab.com) so I can review the data. We don't promise to make overnight changes to the calculator, since changes need to be robust and simple (i.e. no cherry picking city by city numbers), but we do gather data and make edits as we learn.
The philosophy is flawed. Good people don't make average-for-their-area salaries.
Depending on which of the 5-6 applicable job titles listed by the Bureau of Labor Statistics's Occupational Employment Statistics [0] one chooses to apply, my salary is between 40% and 120% higher than the "average mean wage" (itself an inflated statistic) in my area.
This is true not just of myself but of all the good candidates I've hired. Good people don't work for average rates, especially not good people who are capable of doing remote work.
GitLab is doing itself a big disservice by targeting the "average" local wage.
Remote employees' market is the entire world though, that's the part you're not taking into account. Your competition is the other NYC or Boston or SFO or wherever companies that are willing to hire me and pay me a generally competitive rate (very roughly 80-100% of SF pay, in my experience). Sure, you don't have to compete with a GoogFaceAzon offer, but you do have to compete with the companies similar to yours that do pay a more globally competitive rate.
There's a very important difference between: "SFO is very expensive so we have to pay people who live there more" and "we can pay people who don't live in SFO less"
No one makes a salary calculator that robust without intent. I think paying twice as much, and cutting your work force in half would do you a greater service, than playing around with these cost of living calculators.
hamishtaplin; unfortunately coverage is not fully global yet; I think we have about 372 cities in there at the moment. This draws from Numbeo.com's data set on rent indices. But if your city is not listed, our default solution is the following "If you live outside a metro region we base our offer upon the lowest rent index number of any metro region in your country (or state, in the case of the USA), if your country is listed"
We're working on a global compensation framework, to be open and fair about compensation for everyone that works at GitLab. It's described in more detail on https://about.gitlab.com/handbook/people-operations/global-c... . The local rent index (+ a fixed 0.25), NYC benchmark, level, and experience all play in to the compensation. Having the calculator has allowed us to make offers to people in lots of new locations. I'm always looking for ways to keep it robust (i.e. as simple as possible) while being fair as well. If you have specific ideas on how to improve it, please send me an email on ernst@gitlab.com
If you are really serious about being fair. Ask yourself this question: Why would a guy who can easily get 6K+ USD per month by working on Upwork, Toptal work for Gitlab for 1/3rd of that money and that too Full time?
Regarding using the rent index; that was a data-driven decision as described on https://about.gitlab.com/handbook/people-operations/global-c...
but as I mentioned, it is a work-in-progress just like everything else at GitLab always is, and I'm open to alternatives / ideas.
Why are we bashing GitLab when they're at least taking steps to make their pay public? Every company has some version of this formula, you just can't see how off it is.
If I ever apply for Gitlabs (which I'm often tempted to do) I'm afraid that my history of conversations on HN will betray my tendency to bring up uncomfortable issues... Oh well... ;-)
Maintaining the idea of fairness is often important in the eyes of employees, but I wonder if it's actually a good idea in practice. Really, you want to hire the best people you can for the money that you've got. So with the system you have in place, if you have 2 equally skilled people, then there is a pretty big incentive to hire the cheaper one.
The end result is likely to be a bit of a skewed culture. Very skilled people are more rare than less skilled people. They are hard to hire, so you will tend to hire whoever you can find. Less skilled people are much easier to hire, so you will find them in almost any geographical location.
The end result will be a company where only the best people will be hired in the expensive region, while the inexpensive regions will have a mixed bag. Because very skilled people are rare, you will end up having inexpensive regions being overwhelmingly represented by lower skill levels (low skill -> easy to hire -> available in any geographic location -> cheaper geographic locations will be hired first)
This will create a power imbalance in the company because the highest density of high skilled workers will be geographically close and therefore in the same timezone. High skilled workers in lower paid regions may have a stigma attached to them because they come from a lower paid region -- and hence are associated with the higher occurrence of lower skilled workers. This may result in considerable friction over time.
I think you can mitigate this problem by creating a second tier pay system for your most skilled workers. This should be a harmonised pay scale and you should pay attention to trying to evenly distribute positions in this pay scale across geographic boundaries. To make it obvious which pay scale people are attached to, you can create new titles for the positions.
You will still have an "Us vs. Them" problem, but at least it will be people you have consciously decided that you want to promote in the company. It is explicitly not fair (in that not everybody is equal), but it makes a clear message of how you want the leadership to work.
It also makes salary negotiations a bit easier. Often people aspire to the highest level of compensation, even if their contributions do not warrant it. When people ask to be promoted to the special pay tier, it creates an opportunity for having a frank discussion about the person's performance. This can clear the air and set proper expectations -- or possibly indicate clearly to the employee that they aren't as valued as they wish to be. Even if someone leaves in this circumstance, it can often be to the benefit of all parties.
Hope you find this interesting/useful. It's always a tricky balancing act, so I wish you luck :-)
I think you make a great point. I do want to add some nuance:
1. We currently have great people all around the world. Many of them used to be in expensive locations but moved.
2. Because we're remote only the problem of concentration would be time zone only. But for practical purposes South America is a similar time zone as North America.
3. We have one career path (junior/intermediate/senior/staff/etc.) that is available to everyone based on performance.
Thanks for the comment, it is interesting and I'll share it with our Sr. Director of People Ops.
We have recently hired great people in Belgium based on the calculator rates. Of course there is no objective market rate, there are likely people getting paid more and less.
Matt, since I deal with the comp calculator every now and then, if you'd like to provide more specifics of your situation, can you please email me on ernst@gitlab.com ?