> Think about it: if a company pays a person less because of the color of their skin or their gender, the company would be in big trouble. But somehow it's OK to pay a person less based on their location?
I'd suggest the author thinks yet a bit more about this. "color of the skin", "gender", "location of living", I'm sure the author can figure out what differentiates the first two from the latter. For a start, one could think about which of these things one is able to change. Or you might ask the question: which of these things have actually something to do with my job? And yes, location matters: the company usually needs to create a subsidiary in the country of the employee, get familiar with their judicial and tax system, then there's also the issue of time zones, travel cost to company meetings, etc.
Don't get me wrong: one can surely discuss whether differentiating pay based on location is OK or not. However, comparing this to discrimination because of skin color or gender will not help this discussion at all, as in effect the author is comparing GitLab to a racist and sexist organization, which will end any discussion fairly quickly.
> my salary was around €120 000 per year [...] For The Netherlands this is a good salary, and you'll have a hard time finding companies that offer better and let you work from home full time.
For his country, he was well paid and worked from home 100% as well.
> But if I had instead lived in the Bay Area, I would've earned at least twice that amount, possibly even more. Not because I am somehow able to do my job better in the Bay Area, or because of any other valid reason for that matter, but because I would be living in the Bay Area instead of in The Netherlands.
He says it was "not fair" that he wasn't paid the same salary as people in a different country.
Why would they? If they're getting more value out of the Bay Area employees than it costs them, why would they do it?
Employees aren't interchangeable cogs. It's funny how HN will complain about outsourcing and offshoring as doomed endeavors when they imagine their own jobs going to someone in a lower cost of living location. Any company that fires an expensive employee to replace them with a cheaper employee in a different location is making a huge mistake! Employees aren't interchangeable cogs!
Then as soon as the roles are reversed we're supposed to believe that the people in the more expensive location are easily replaceable. Any company that pays people differently is making a huge mistake! Employees are interchangeable cogs!
They can always change their multipliers if they think the employees they're hiring there are getting paid more than they're worth relative to other locations. And lots of companies mostly just shrug rather than getting into a bidding war with FAANG in particular.
I mean Bay Area puts you near the big tech companies which is an interesting talent pool; their knowledge, experience and connections will have value beyond the skills needed for their day job.
The Bay Area is probably their birthplace, best talent pool and main source of funding.
Similarly, as it's the case in global governance, almost all nations have an office in New York, from where they are able to talk to each other and make use of their seat around the table at the United Nations.
The Dutch and their history of sailing boats over the ocean... In these modern times, I believe it's about planting a flag on the land of the Vatican/Mecca of the digital tech industry.
I'd bet that GitLab, as an entity or corporation, felt mission-driven and empowered by settling not far from GitHub.
Neither/both? It's one of those cases when people don't appreciate the the employer's and employee's interests are rarely aligned. I wrote some thoughts on this a while ago as I realised lots of people I encountered who've been in an individual contributor role their whole career haven't been forced to think about the opposite side of the arrangement: https://glenngillen.com/sensible-remote-compensation/
Thankfully where I work now (ockam.io) indexes to Bay Area salaries, irrespective of where people are based.
Did this argument just come full circle back to literally what GitLab is doing by paying engineers in the Netherlands less?
Regardless, it's silly to propose that engineers are interchangeable cogs in a machine and you can find perfectly identical talent anywhere. If that was true, companies would ignore all of these locations and skip straight to the cheapest country they could find.
But network effects matter, and hiring out of the Bay Area taps you into a different set of experience and networks than almost anywhere else in the world. I'm not suggesting that every Bay Area engineer is better than every Netherlands engineer, but the Bay Area talent pool really is unique and well connected in a way that's hard to find elsewhere.
But that's not what Gitlab is saying, that BayAreans are better workers. They maintain that they're merely adjusting for regional CoL, for the same person in the same position. They can hardly get closer to saying people are interchangeable cogs.
I see your point. There are more factors than talent being different in the Bay Area I think. I work for a Bay Area start-up in the Netherlands. They opened their office here for a specific talent. This talent can be found in the Bay Area too, and they can pay the salaries there too but the employees in the Bay Area don't stay that long compared to here. For the company this is a big issue because you keep bleeding out know how. So the reason they came here was a combination of the talent, affordabile salaries (100-150k for staff level), and employee loyalty. We had only 1 person left from a team of 25 people in 6 years while half of the people in the Bay Area office is left. Give us 40 holiday days, 40 hour work week and a decent salary we will stay.
I mean, if they could they would. Why have any engineers in the US at all when you can hire them at 1/2 to less in India, South America and even Africa?
> The author has a poor understanding of economics.
Because as we all know the laws of economics are fair and just. Truly a business man who strictly follows the laws of economics would always compensate people fairly for their value delivered to the company.
In all seriousness, how does this make economic sense? The company is incentivizing that people move to areas with a high cost of living, but why exactly? What economic benefit does that bring to the company?
The only reason that's ever been explained to me is that the cost of competing for talent is higher in those areas than others. However someone's location is a poor indicator for talent potential, so why would you compete in high cost areas?
> The only reason that's ever been explained to me is that the cost of competing for talent is higher in those areas than others.
You are looking for stability-based economics and wondering why your conclusions don't appear in reality. Well, it's because your economics are wrong.
They pay more there exactly because there is larger competition. And they hire there because that's where their money come from and where they started hiring before going global. If they reseted their hiring choices and had to do all of them again now with the current company, they would be better off hiring at cheaper places and not having anybody on the more expensive ones, of course. But the sheer absurdity of that conditional should be enough reason for you to see it won't happen.
>However someone's location is a poor indicator for talent potential?
No it's not? If this were true, then economic hubs wouldn't exist. If someone is talented in field it's likely they will move to an economic hub that has jobs for their talents. If I wanted to open a trading firm I'd likely find the most capable candidates in Chicago, because thats where most of the jobs are today. There are certainly capable hires in Idaho, but how much time should a company spend looking for a needles in haystacks?
> In all seriousness, how does this make economic sense? The company is incentivizing that people move to areas with a high cost of living, but why exactly? What economic benefit does that bring to the company?
It doesn't always bring an economic benefit to the company, which is why there are debates over companies calling employees back into the offices. That is almost always based on gut feeling and herd-mentality, than on any concrete data.
However, companies have to recruit from labor markets, and as such, they are bound by its vicissitudes. Despite the pandemic scattering many software people all over the country, the vast majority of competent software developers with cutting-edge work experience are still to be found in the Bay Area. Therefore, it makes sense for the company to insist that other hires also live in the Bay Area. Perfectly understandable. If the company is able to compete effectively for talent in the remote market and able to make it work (timezones and cultural differences do matter, even if it were possible to recruit remote workers easily), then it would do it, sooner or later.
My anecdotal observation is that CoL multipliers for HCoL areas don't actually compensate fully for living in those areas. I had an opportunity back in the 90s for a job in the Bay Area and passed in part because the higher offer would have been a quality of life downgrade at the time.
> The company is incentivizing that people move to areas with a high cost of living, but why exactly?
Is it? Are you better off if you earn more but live in a high cost of living area? I hear about people working in SF for the big tech companies but living from a car because they can't afford to live there.
1. GitLab (as with most other companies with geo-dependent comp) pays based on Cost of Labor--not Cost of Living. So if a market has crazy-expensive real estate but salaries haven't caught up (somewhere like Vancouver), you're out of luck.
2. GitLab is NOT encouraging team members to relocate to HCOL areas at all. In fact, while they encourage hiring in LCOL areas (there are target "location factors" for teams, so there's a bias toward hiring in lower-cost areas), the Handbook ( https://handbook.gitlab.com/handbook/people-group/relocation... ) states that "Relocations resulting in an increase in compensation must be approved by the team member’s direct manager, and location factor changes that are >.2 will require direct manager, VP as well as an eGroup Member approval."
TL;DR -- don't get hired in Iowa an expect to bounce to SF right away.
Not paying location-based salary is arguably more unfair.
If you pay the global median salary to everyone, people in high cost areas are screwed and you’ll never be able to recruit there.
If you pay everyone in your company the highest salary, people in low cost areas live like kings while their peers in high cost areas live a more modest lifestyle.
As a company you’re not out to solve global inequity, you’re out to hire good talent effectively and efficiently. Like leaving a 40% tip at a restaurant, overpaying the going rate on salary doesn’t really get you anything but feel goods at a certain point.
Actually, a company's attitude toward this problem has to be balanced. I live in a country where most international companies pay less than the US and even the EU average. The effect is quite easy to predict: they are not attractive to senior candidates (i.e., Nokia) and suffer from higher employee attrition (not right now, as the job market is pretty dead). I don't want to mention the effect on employee morale. Is it discrimination, as the author says? When you do exactly the same job in the same company, same department, same team, with the same output — then definitely it's discrimination. Does it encourage various xenophobic behaviors coming from better-earning employees - very rarely, but yes. Is it legal? — Yes.
Balanced, sure, but not completely location blind.
Usually what I see is that remote jobs will offer a slight higher wage than the going rate in lower cost of living areas. That way you’re in a situation where moving to a higher cost of living area and making a more regionally average salary isn’t all that attractive.
> When you do exactly the same job in the same company, same department, same team, with the same output — then definitely it's discrimination.
But that’s my point as well: if you’re in San Francisco paying $5,000 a month in rent for an apartment and your coworker in Cambodia is also getting an SF salary living in a mansion with servants because your company is location blind that’s also a form of inequity.
That's not the way it works out in practice though. I've been a hiring manager and have had to see the impact these geo-based policies have on the salary of those in my teams. I work remotely and know how much it's hit me relative to my peers. Melbourne & Sydney are regularly listed in the list of most expensive cities in the world, yet Australia is almost always treated as one big market at the bottom end of the scale. I've had team members in Canada who are paid significant 6-figure amounts less than direct peers, if they moved ~1hr south they'd earn significantly more.
This is rarely about avoiding paying a FAANG engineer $500K and letting them work from Bali. They're weaponised in ways to give a plausible defence to why two people with the same role and experience are paid vastly different amounts for doing the same job.
Living with others (parents, partners, etc) is something that decreases core costs of domiciling anywhere you go. That is an excellent method of maximizing revenue while not abandoning your family.
Otherwise, see The Complacent Class: The Self-Defeating Quest for the American Dream by Tyler Cowen.
What about having a family? If you pay everyone the same, those living alone or with a partner will live like kings while those with children will live much more modestly. Oh wait, we get 2k in tax credits per kid. I forgot that one is all good.
My point is, people are going to have different lifestyles that cost different amounts and give them different benefits. Companies should fuck off pretending they care about fairness or cost of living. Just call it what it is - competition-based pay. You pay someone in SF more because you are forced to by market conditions, and if you could, you would pay them less, with zero concern for their rent or mortgage. And since you CAN pay someone in Kansas City much less, they do.
We've already seen the prevalence of remote work change the equation. Many places now pay SF 110% and everyone else in the US 100%. The COL difference between SF and KC is not that 10 percentage points. Nor could you compensate someone for the discomforts - both political and meteorological- of having to live in Missouri, who God himself has abandoned.
I was just pointing out what the author of the statement wanted to say, wasn't really going to argue about the point.
It's incredibly hard to budget for children though, you can't really foresee how much they will cost. One child eats little, one eats much, one is picky, one not, one likes soccer, the other one likes lego.
Very hard to predict, except maybe year 1-2. But then one might be good with breastfeeding while the other might require formula and the cost of the first one is 0 while the second one could be very high
The other commenter is correct about my meaning, 2k/yr is rounding error for kid costs - at best it derays the increased cost of the "Family" health insurance plan.
And I'm not saying it should be more, I was more saying it in jest to help deter comments like "but you get tax kickbacks!". I do think that we should be doing more for children - free school lunches with no means testing, free childcare from birth instead of just when they enter the public school system, and so on - but the child tax credit is the most visible "kickback" so I made a joke about it to acknowledge it.
My point here, more generally, is that companies shouldn't be trying to play this game with "fairness". Just call it what it is - capitalism and the invisible hand of the free markets. If people have problems with how that system allocates capital, then do something about it, but don't try to pretend any of its machinations have any relation to notions of justice or fairness.
Very true. I mean even on my "platinum" healthcare coverage, it covers the gap of the deductible (which I know isn't exactly the same thing). Or looked at another way, it pays for 2.75 weeks of daycare.
(And I say this as someone not overly invested in that world - I have a 17 yo stepdaughter, and I am fortunate that in addition to my excellent healthcare, my company pays 100% of the premiums for my partner and kid, not just me).
How come it's okay for a company to say they don't give me a raise for increased costs of living, but it's okay for a company to pay less, because I live in an area with lower costs of living?
Of course pay is about bargaining power. How do you think a salary negotiation works? Why do you think a software engineer gets paid more than a nurse in most places?
Yeah this is an insane line of thought. You won’t fix pay, you’ll just see jobs stop existing by going this route. Market dynamics in labor are a good thing and you can change your location to benefit from them.
Don't know why the company wouldn't give you a raise for increased cost of living? Plenty of companies will adjust pay based on location, including moving around. And plenty of companies adjust for inflation as well.
Of course any adjustment in pay needs to fit budget, so the company and line manager would need to have the budget to afford to. And there's probably plenty of companies that won't have this as an option or won't adjust for inflation, but there's also plenty of examples that do.
Your salary is a negotiation. Your company wants to pay each employee as little as possible. If you are unhappy with your salary you should look somewhere else. In fact, that is why companies pay people in expensive areas more. Those expensive areas have more available jobs so employees are more likely to leave. If you want those employees to stay you need to pay them more than employees who have a harder time leaving.
I feel you have less empathy for a another worker and stressed that others are competing with you
It’s ok for enterprises to pay different prices/salaries in different locations yet individuals don’t get to do the same is a flaw in how we are taught what we can ask for
I mean he lives in Amsterdam, which is more expensive than the rest of the country, sure, but nowhere near what it's like in SF according to https://www.numbeo.com/cost-of-living/rankings.jsp (Amsterdam is ranked 75, vs SF at 8), and I'm not sure if that index includes health care and social benefits like state pension, etc. Speaking of, that's only salary, ìt excludes stocks, bonuses, pension contributions, and other benefits.
Then there's accessibility; living in central Amsterdam means he can fulfill most of his daily needs and transport by bike. Can't get much cheaper than that.
TL;DR, he can move to SF if he wants to earn SF rates.
Debunked time and time again. The oft-quoted "70%" stat is referring to all men vs all women. Within the same job, the pay is much closer to 95%. Any difference is still worth understanding and closing, but there are plenty of pretty reasonable explanations for why a 5% pay disparity may exist between men and women.
It’s fair to say both are. GP is strongly implying women get paid 70% for the same work (illegal in the UK at least) whereas P misses the subtlety that women don’t have equal access to the job market. Compare the rates of women in software engineering vs childcare. Then compare the salaries.
I've worked in 5 different countries in my life, and one lesson you learn quickly is that it's impossible to compare salaries between locations at face value.
For example, now I live in the US and although my salary is about twice what it was in England, my lifestyle remains about the same, worse in some aspects, and better in others. I'm almost certain OP lifestyle would have taken a hit living in Bay Area, even with a higher comp.
And this is simply comparing income, not accounting for many other variables (social benefits, taxes, culture...). In fact I'll probably take a big hit in comp to move back to Europe so that I can live a more comfortable lifestyle.
I agree completely. This is what I always tell my family in Europe: Sure, my salary on the US West Coast may be high, but the lifestyle this affords me (while being reasonably future oriented in preparing for retirement, family planning etc) is almost certainly worse. (Not to mention cultural differences in attitudes towards work.)
You can't assess salaries as someone who would temporarily work somewhere else and then export that money back to their home country. You have to view the salaries in the context of someone who will spend their life there.
It's also just very situation-dependent. I live in at least the periphery of a HCoL East Coast urban area but I have a paid-off house, don't have kid-related expenses, and don't eat out a lot (especially expensively) in the local area. I do travel a fair bit but those costs would be similar no matter where I lived. So, for me, I don't really live in an HCoL area to the same degree as if I were renting in the city and going out on the town all the time or were paying for childcare.
I think you have to get the actual content from the Wayback Machine now.
Gist was that many Armenian families tended to be miffed at the amount of financial assistance their relatives who had moved to America tended to send back, particularly upon learning of their apparently high salary amounts.
Article then goes on to describe how American society tends to nickel-and-dime its members to death from every direction.
More broadly, the article was a fascinating outsider’s look at our culture and lifestyle.
Things they mentioned as being different from Armenian life:
* You pay federal taxes and state taxes to a myriad of different agencies with different limits or starting points on all of them. Property taxes, vehicle registration taxes, sales taxes, etc.
* The US is more focused on being procedurally fair (you have rights that must be ennumerated to you upon being arrested, etc) but not on being just (he mentions child neglect for latchkey kids, mandatory sentencing, a woman accused of kidnapping for trying to take her child away from his abusive father with a custody agreement)
* Poor federal safety net
* Suburban housing and little mixed-use zoning leads to required cars, homogeneity of America, lack of walkable anything
* Individualism (not knowing all your neighbors; he mentions that in Armenia if you had a test for a tumor multiple friends would take off work to weep in the waiting room with you; the idea of being an automaton in your company rather than a human with emotions)
As for location, the motivation is stated here, and in my opinion, it really makes sense: https://handbook.gitlab.com/handbook/total-rewards/compensat...
Imagine they would pay Bay Area salaries everywhere including Philippines or Ukraine. People there would be in "golden handcuffs" and burn out instead of changing job when it's time to go. This would produce terrible results for both the company and people.
And of course, if they chose to pay some kind of world-median salaries, then they wouldn't hire people in California or London at all.
There are other controversial things said about product managers being unneeded, and that the company shouldn't have more than 100 developer for a product.
I think it's pretty clear that the author is a great autonomous engineer who would be happy and very successful in a (relatively) small startup. Maybe if not for the tax rule changes waiting, he would have left the company earlier, and would write a happy article about his experience there.
This gets us back to the location-based rates again by the way:). Imagine how difficult it would be for the author to leave the company if in addition to stocks, he would have had $300k compensation in Amsterdam.
> People there would be in "golden handcuffs" and burn out instead of changing job when it's time to go
Good ol' "we can't pay you that much, because what if we wanted to stop paying you that much. It'd be bad for you if we handed you this pile of money, you might hurt yourself. We're helping you by keeping it to ourselves, trust us."
They actually do not hide the main reason and state it first:
"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."
That's why I like their approach and communication. As a Ukrainian, I would be happy to work for CA salary here, but I do understand that a good local market rate is enough for me if the job is great.
EDIT: and one more thing to add here: as an employer, you usually prefer to hire people whose motivation is not only money. You want to work with people who like the job and their colleagues. The current market practice is to pay local rates. Thus any company that pays much more, has to address the challenge of filtering out people with "incorrect" motivation.
I think there’s at least something true hidden in the post you’re responding to. While I don’t necessarily think it’s a strong enough point to base salary decisions on, nor do I think it’s the actual reasoning behind GitLabs policy, I can for sure see how being overly paid for a job that you’ve grown to hate produces poor results for the company and possibly the employee
> Imagine they would pay Bay Area salaries everywhere including Philippines or Ukraine
That would be absurd.
But what if they paid Philippines or Ukraine salaries everywhere instead? They wouldn't hire Bay-area engineers. Okay. And maybe the offshore has too much language/timezone friction. Okay. So choose a different price point, whatever is the cheapest to get engineers who match your condition, regardless of what their steet address is.
> Imagine they would pay Bay Area salaries everywhere including Philippines or Ukraine. People there would be in "golden handcuffs" and burn out instead of changing job when it's time to go.
You're saying that as if companies retaining employees is a bad thing. Stock options are already a form of widely used "golden handcuffs". If people want to keep working somewhere, compensation should only be one decisive factor among many others.
> And of course, if they chose to pay some kind of world-median salaries, then they wouldn't hire people in California or London at all.
Why not? People in London or California would have to compete by the same criteria as people in Ukraine or the Philippines. This is only a good thing, as it opens up the talent pool to a global market.
The point of fair compensation is not about giving everyone the _same_ salary. It's about removing the location aspect from affecting compensation, and making it more of a merit-based system.
Especially for a remote-first company like Gitlab, where people are free to work from anywhere. It's ridiculous that employees are encouraged to live in countries with high compensation just to take advantage of this system, and are penalized for working from countries they actually want to live in.
Not to mention that it makes the lifestyle of a digital nomad much more complicated. What if I want to live 3 months in London, and 3 months in the Philippines? That kind of lifestyle would involve messy contractual changes and salary adjustments.
This system makes no sense, and is a remnant of traditional corporate structures. Of course companies love it, because they can get the same quality workforce by hiring internationally for much cheaper. Offshoring is an old corporate tactic, and needs to be abolished. It's shameful and hypocritical that remote-first companies like Gitlab still cling to it.
<hr>
Taking a look at the article you linked, it's quite clear:
> 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.
Translation: it would cost us more to hire quality people everywhere, and we'd rather hire them cheaply.
> A concentration of team members in low-wage regions, since it is a better deal for them, while we want a geographically diverse team.
Thinly veiled diversity claim. The same thing happens with the current system, where people are encouraged to concentrate in higher-wage regions. Removing this only gives them the freedom to live anywhere.
> Team members in high-wage regions having much less discretionary income than ones in low-wage countries with the same role.
So? Since when is a company concerned about how much "discretionary income" employees have? Your only job is to compensate people fairly for the role based on their abilities.
> 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.
Addressed above. This is BS, since you already give them golden handcuffs in the form of stocks, perks, benefits, etc. Compensation shouldn't be the only "handcuff".
> If we start paying everyone the lowest wage we would not be able to attract and retain people in high-wage regions, we want the largest pool to recruit from as practical.
Again, entirely backwards. It's not about paying everyone the "lowest" or "highest" wage. It's about paying everyone fairly for the role and their experience/merit. You don't need to choose either Bay Area salaries or Ukraine salaries, but come up with your own compensation structure.
Buffer has been doing this for a long time now, and they have cost-of-living location bands, but have removed two of the lowest ones in 2022[1]. I would go a step further and leave only the highest band for people who want to live in the most expensive regions in the world. But then again, since you've made yourself more attractive for world-class talent, it's likely that you won't have a large concentration of people living in these places anyway. So there's your diversity.
And even if you remove the entire concept of location bands, and people in these expensive regions get paid less than other opportunities in their region, they'd likely still want to work for you because you give them much more than just a fair salary, right?
All I read are excuses the company made up to avoid just saying: we want to hire talented people and pay them less. At least have the decency to be honest about it.
You actually quoted that they are very open about their main reason for paying local rates: they want to be competitive as a business, and if for the same amount of money they can hire more good employees, there is no reason not to do this:).
> Your only job is to compensate people fairly for the role based on their abilities
So it's about definition of fairness. You think it should be some universal measure regardless of location, they think it is a good market rate. And job markets in each country even after COVID are still different, that's why a "fair" amount differs across locations.
One more important consideration here is local laws regarding taxation and employment. People in EU get less than in the US, but generally it is much more difficult and expensive to fire them as an example.
Would it be fair if a person with employment-at-will contract who can be fired tomorrow with zero severance and has 14 days of vacation had the same salary as the person who has 30 days of paid vacation and minimum severance or notice period of 6 months?
Well, it's also complicated for tax and labor law reasons. Being officially a digital nomad is probably already problematic for, especially large, companies that can't really look the other way even if salary adjustments aren't part of the equation.
That's true, but a digital nomad could choose to work as an independent contractor, where tax burdens are mostly on them. They can choose to manage their finances in one country, while living in another. Or work as part of an umbrella company, which simplifies legal aspects for their clients.
I agree that it's a somewhat complicated issue, but there are solutions to it if the company wanted to solve it. Besides, these cases are rare and not many people will choose to live this way, so it's not the most pressing matter in this discussion.
Sure, a company can hire you as a contractor although that probably comes with downsides from benefit/stability/etc. perspectives. It's probably how you have to do things though if you really want to be a digital nomad.
The main reason Silicon Valley or where-founded-high-cost-of-living companies hire in low cost of living locations is due to the value they get in paying less for compensation but getting proportionally more value than the lower compensation. Requiring that compensation be the same everywhere would simply incentivize companies to only hire locally since they’d improve communication (even if fully remote) due to offsites, same timezone etc. Esp., in an economy where there is a large supply of people wanting to be hired in HCOL locations.
That’s not to say this couldn’t change in the future (sometimes it’s good to ignore the current “how” and incentives / reality). But it’s useful to be realistic. There’s also something to be said for companies taking the risk and hiring in other countries. This increases knowledge (not to say the company is “better” but it probably has some reasons for why the local talent joins), sows the seeds for future companies there etc.
The (good) companies I've been at are location agnostic on pay, or close to it. It's not about getting a discount, it's about expanding the talent pool. We want the best we can get, not the best within 25 miles of a hub.
If you have an infinite budget you can just outbid everyone, everywhere and get whoever you want. Companies like like Netflix do something like this.
If you don't have an infinite budget, you have to start making compromises. You can try to pay everyone according to the highest possible local salary you might compete against, but now you're arbitrarily paying more than you need to everywhere else. Could be fine if you have unlimited budget, but most companies don't.
So you could try to set a median pay that's higher than the LCOL targets but lower than Bay Area salaries. Now you're attractive to some talent, but other people won't consider your company because it pays less than their alternatives.
Location-agnostic pay is one of those things that sounds great when your company has limitless money (or feels like they do, as in ZIRP), but most companies at scale realize that they're either missing out on certain talent pools or spending unnecessarily to acquire people.
In the case of GitLab, the author was making a great compensation for their location. If the author had zero knowledge that other employees were getting paid more, would they have even cared about their own compensation?
> You can try to pay everyone according to the highest possible local salary you might compete against, but now you're arbitrarily paying more than you need to everywhere else.
This is the difference. I don't see it as arbitrarily paying more than I need to. I see it as paying people the same for doing the same work. My goal is not to pay as little as possible, or even to pay a high rate relative to their local market.
I can't look at someone in Romania doing the same job as someone in Chicago and tell them I'm paying them less because they're in Romania.
I completely understand that this is not economically optimal, and I love capitalism. I just have no interest in saving money this way.
> So you could try to set a median pay that's higher than the LCOL targets but lower than Bay Area salaries. Now you're attractive to some talent, but other people won't consider your company because it pays less than their alternatives.
Salary is only one part of comp. Comp is only one part of what makes a company attractive.
I see where you're coming from, but in practice offering location-agnostic salaries means you're not competitive in areas that command higher salaries (notably, large tech hubs like the Bay Area, Seattle, New York). If anything, you're trading the talent pool near those hubs (and let's be honest, the rest of the US) for talent in other countries.
That's a trade-off you might be willing to make, but I hope you understand that not every company is willing to write off the entire talent pool of the US.
(As a point of reference, the only two countries that Google pays comparably to even the cheapest parts of the US are Switzerland and Israel.)
You have bigger talent pools in the tech hubs, at the very least. And recent college graduates from top-tier institutions are most likely to either stay put (depending on the source, I saw 40-60%) or move to a hub, so you have a lot of untapped potential.
Talent being "better" is too subjective to really quantify, though.
Something like 15% of devs worldwide are in the US, so if you don't want to play ball, you're losing a nontrivial chunk of the total talent pool (even without accounting for timezone affinity or English fluency).
If you think paying market rate for a Bay Area dev is overpaying, are you exclusively hiring devs in Argentina (with the rapidly-devaluing peso)? You can get 10 devs for the price of one person based in SF! Even paying Amsterdam's market rate is drastically overpaying in comparison to the areas with the lowest cost of labor.
My experience is from a fully remote unicorn startup that hires globally. Not Gitlab. Have continued equity exposure and strongly believe in the remote first model as a differentiator. There is exceptional talent globally, but you must be intentional about finding it.
>Is there data showing the talent in those tech hubs is better than what you can find elsewhere?
There are great engineers everywhere, but this line of reasoning misses why talent hubs exist in the first place. It's more likely a qualified individual will line near a talent hub along side other companies that demand those skills. A better question to ask is how much time & effort will a company put in finding a qualified candidate outside of the talent hub.
For example, Apple has a similar problem with regards to manufacturing in China.[1] Do talented tooling engineers exist in the US? Of course. Is Apple going to spend 5 years trying to hire 100 tooling engineers in the US, or spend 6 months hiring the engineers it needs in China?
If you have the budget to hire someone from the Bay Area with a Bay Area salary, then you also have the budget to hire someone from Bumfuck Nowhere, with a Bay Area salary.
I agree with the other commentator who said: It's not stupid to pay a location-based salary, but please don't pretend it has anything to do with fairness. It's not about being fair - it's about the company trying to save money by getting a discount on employees when that discount is available.
I should emphasize that I'm not trying to comment on fairness, one way or another.
I'm pointing out that location-agnostic salaries are often trading one segment of the global talent pool for another, since what I've seen in practice is more like "everyone gets paid 80% of a Bay Area salary".
You don’t need to lose access to the entire US talent pool.
The company I work for paid high-mid US salaries before going remote. It has continued paying high-mid US salaries after going remote, just expanded to hiring from more locations.
So before we had access to the talent pool of one metro area in the US. Now we have access to the talent pool of all of the US besides a few very HCOL locations (which we didn’t have access to before anyway), and also most of the rest of the world. Our costs are the same as before, but hiring is easier and we can often get a higher caliber employee to fill an opening.
As the guy you replied to said—it was about expanding the talent pool, not about saving money.
Because software developers overseas make barely more than 6 figures usd. Basically everywhere in the US beats that so if you do a "global wage" youd get no one from the us.
Companies clearly dont want a 100% overseas work force. If they raise the price point so that they get Americans to accept why have overseas employees at all? The entire point of bringing them on was to save money on their salary.
This is a direct consequence of people wanting WFM but not understanding the implications.
Going into an office gives employees pay leverage due to cost of living in that locale (assuming they live in a top pay market, SF/NYC/etc).
But if you have an entire Remote company & culture, now - companies can hire in any locale and pay lowest common denominator (even if that locale is half way around the world).
Remote work turns everyone into effectively an independent contractor competing against all other talent from all around the world.
In office means you’re mainly competing against other people in your locale.
fortunately, wfh is widespread enough now that if a company doesn't want to pay you then you can take your skills elsewhere. If the talent pool is worldwide now then so are the employment opportunities.
Conflating the three is easy, because instead of paying for delivered value, the company is doing arbitrage on location ( like it could do with gender, race or anything else)
All companies will take advantage of maximizing their profit or reducing cost, but it's a slippery slope once a subjective metric to determine value is used.
I for one live in a "low" CoL, but my AWS bill is just the same as a person in NY, SF or Geneva, should I also expect a discount because "my income is lower"? Or is it only fair to be billed equally, because the value all of us get is the.same ?
Turn the tables, if a dev in India, Romania or Mexico is delivering the same value as one in the US or UK should (s)he be paid any less ? Why ?
This argument falls apart when you consider that some projects have zero or negative value. Developers who work on these projects still get paid and we obviously don’t have to write a check when we make a mistake that costs the company money. Nobody actually likes “delivered value” compensation except under hypothetical circumstances where they imagine it can only increase their pay.
The hiring market is a market. Supply and demand drives compensation.
Delivered value isn’t one of those forces driving supply and demand. It sets the maximum an employer can pay someone and still get an ROI, but that’s it.
> Turn the tables, if a dev in India, Romania or Mexico is delivering the same value as one in the US or UK should (s)he be paid any less ? Why ?
Because it’s a job market and you’re bidding for candidates against their other options.
If you’re house shopping and you find an identical 3 bed, 3000 sq. ft. house in all of those markets, would you expect to bid the same for it? Of course not.
The sooner we accept the realities of job markets and supply and demand, the sooner this all makes sense.
Are you really asking why companies take risks on new projects that might not work out? Or expecting that companies can perfectly predict which projects will succeed?
Look at it this way: What if the developers were only paid after the product broke even and starts "delivering value". You think you're going to get a lot of developers signing up to work on a new project that might only pay them if they stick with it for a few years and it succeeds due to reasons that include things out of their control (like sales cycles, market moves, etc.)?
Replace "delivered value" with "expected delivered value" and the argument goes through mutatis mutandis. Of course there are uncertainties in the value of unrealized work, but the company is paying because they think the expected value of the work is higher than what they are paying in wages.
So if the developer makes a mistake that lowers the delivered value, who pays? E.g. slower than promised development, things that were promised don't work at all or cost more for less results, etc.
The chance that they won't deliver factors into the initial expectation and is reflected in the hiring and salary decision. You can evaluate this chance both globally and for an individual by considering their interview, past experience, recommendations. Presumably if a developer is routinely not doing their work, the employer will revise their expectation downward, and ultimately stop employing that developer if they are a net negative. I see no problem here beyond the inherent uncertainty that comes with working in a complex world where your knowledge is incomplete.
(edit to add: well, no problem except capitalism, but that's a story for another time)
> Are you really asking why companies take risks on new projects that might not work out? Or expecting that companies can perfectly predict which projects will succeed?
Uncertainty is fine; is mean that if the expected value[0] is below zero it's a terrible idea to do it.
> Look at it this way: What if the developers were only paid after the product broke even and starts "delivering value". You think you're going to get a lot of developers signing up to work on a new project that might only pay them if they stick with it for a few years and it succeeds due to reasons that include things out of their control (like sales cycles, market moves, etc.)?
Empirically yes; what you've described is close enough startup employees with low cash and high stock payments.
Here's your mistake. Companies have never and will never pay for delivered value. They pay the least they can to get an acceptable candidate. The difference is important, and the mentality that companies are paying for delivered value rather than the minimum acceptable amount leads to these mistaken conclusions often.
As for why? Because their goal is to maximize profit of course. Why pay more when less will do? The overseas dev should be paid less because their opportunity costs are much lower, so they accept a lower wage.
> And yes, location matters: the company usually needs to create a subsidiary in the country of the employee, get familiar with their judicial and tax system, then there's also the issue of time zones, travel cost to company meetings, etc.
Where a person lives is indicative of their culture. And their unwillingness to move shows deep ties to family and friends. There is a clear difference in mental/emotional makeup with those willing to relocate at the drop of a hat.
Just because these traits are not protected by US law does not mean that they should not be valued. They are also traits of human diversity and discriminating based on those traits is still discrimination, just not discrimination against US-protected classes.
You may be right. Though if the articles author is right that they hired too many devs, then they probably could have had a team of 30 sf salaried devs instead of 130 lower salaries and would have done more with them (theoretically)
My (biotech, mostly remote) company does this. They may not love it but they realize they have to hire from SF, Boston, NYC etc to get the best ML talent and people expect market salaries / don’t want to up and move if they don’t have to.
> But somehow it's OK to pay a person less based on their location?
At the end of the day, it winds up being a choice between
- Pay someone based on their location - People in lower COL areas complain, but are (in theory) being paid an amount with the same buying power as someone in a higher COL area (being paid me) [1]
- Pay the same regardless of location - People lower COL areas are making more buying power, but people in higher COL won't even work for you; because it's not realistic to pay the higher COL amount to everyone [2]
There's no solution that makes everyone happy.
[1] Not really true, since it doesn't account for a lot of factors; such as retirement savings, etc.
[2] Not strictly true but, if you pay the higher COL amount to everyone, then you can hire fewer people for the same amount of money.
I guess the question is, do you need people in high-COL areas to work for you? There's no shortage of developers in Arizona / Europe / Canada / etc, so why would companies like Gitlab spend so much money on bay-area devs? A corporation could save a lot of money by only hiring developers elsewhere who deliver similar work. And cutting labor costs does seem to be the operating mode that a lot of software companies are in at the moment.
A lot of talented people tend to concentrate in the hcol areas because it gives them the most optionality (plus many other benefits, of course, for people who can afford them).
If you’re hiring for some specific niches or need very senior people, removing candidates in hcol tech centers from your search pool could make it a lot harder to hire. Like imagine saying you want to hire a great US political lobbyist but you can’t hire anyone who lives in DC. It would be tough right? The dynamics in tech aren’t as dramatic but there’s still some of that effect.
I’m not saying an alternative strategy couldn’t work, but there are good reasons companies want to be able to hire in hcol markets.
I mean sure, if you're hiring people for skills that you can't find elsewhere, then of course you pay them more. But not specifically because of where they currently live.
>I'd suggest the author thinks yet a bit more about this. "color of the skin", "gender", "location of living", I'm sure the author can figure out what differentiates the first two from the latter.
I suppose what you're getting at is that you can't change your race or skin colour, but you can change your location. That isn't really the case if you're Ukrainian, or just from a country with a weak passport.
I guess OP was wrong in that some people really can't figure out what differentiates the first two from the latter. You can change your location even from a country with a weak passport but it won't be easy (like it won't be easy to get accepted into a top-tier university), but you still can't change color of skin no matter how hard you try.
Yeah, his statement makes about as much sense as the expectation that all people must be charged the same for something all over the world. i.e., 50c-equivalent hamburger in, say, South Africa should have the same price in San Francisco. Ain't gonna happen because economic realities do not bow to idealism, however well-intentioned.
> And yes, location matters: the company usually needs to create a subsidiary in the country of the employee, get familiar with their judicial and tax system, then there's also the issue of time zones, travel cost to company meetings, etc.
B2B contracts are a thing. It's very common for many devs that work remotely for other companies.
There's also companies that offer something like "Payroll as a Service".
Still B2B is superior in every way, and can often net you much more money than just being an employee due to being able to leverage tax-optimizations.
> one can surely discuss whether differentiating pay based on location is OK or not. However, comparing this to discrimination because of skin color or gender will not help this discussion at all
Exactly.
Compare it to something else, like paying people more if they own a sports car.
> the company usually needs to create a subsidiary in the country of the employee, get familiar with their judicial and tax system, then there's also the issue of time zones, travel cost to company meetings, etc.
This is why women who want to get pregnant don't get hired in the USA (extra costs associated with postnatal (ETA: maternity) leave). And yet that's not okay. So your basic rule of thumb is not quite comprehensive.
It's weird I have to say this, but from what I wrote it of course does NOT follow that ANYTHING that makes economic sense for a company cannot be discriminatory. That would be a dystopian rule straight out of an Ayn Rand novel.
And, which one has a historic asymmetric power balance.
We discriminate pay on job role, on job level, on performance. We discriminate on length (tank crew), eyesight (pilots). That is not Discrimination however, because it lacks a historic asymmetric power balance.
That's actually a point worth discussing. Because here's one thing that should be obvious, but apparently many people are unaware of: if you work for a large, multi-national company, you are almost certainly affected by location-based pay. GitLab is not an outlier here, but well within the norm for a company that has subsidiaries in different countries.
The main difference with GitLab is that a) they are completely remote, b) they are called "GitLab" in every country instead of creating subsidiaries with different names, and c) they have made the "mistake" of making the payment differences entirely transparent. They were absolutely not forced to do that, but they did it nevertheless, and they should be applauded for that.
A while ago there was a thread about cheap African labor, and some Africans showed up in the thread and explained that what we (westerners) consider ‘cheap’ is actually still a lot more than the local salaries, so it gives them a lot more social mobility.
No one pays based on cost of living. They pay based on what people it takes to hire a certain role in a given market. There is no point in making companies look good because they pay exceedingly well compared to the cost of living in some areas if the opposite is true in others.
Obviously there is some correlation with pay vs cost of living as it helps people determine what they are willing to accept, but it is not the primary mechanism companies are using.
Also companies who pay the same regardless of where you live are still not paying based on cost of living.
As you are almost certainly aware, the majority of racial problems in the US boil down to the very simple fact that black people are on average of low socio-economic standing; and if there is one thing the US system is geared against its any person of low socioeconomic standing.
Put succinctly:
You might consider that its ok to pay differently based on if you’re in Los Angeles or Bryan, Ohio- but would you feel the same if pay was different depending on if you lived in Inglewood vs Santa Monica?
The racial disparity situation in America (and all over the world) is complex enough a topic that it cannot be boiled down to such a simple explanation. I encourage you to research the various systemic challenges people of color have faced since they were forcibly relocated here such as redlining[0], loan discrimination[1] and examples of literal war crimes committed against black communities that have been swept under the rug for reasons[2].
Inglewood and Santa Monica are close enough to require the same level of income in order to afford a certain standard of living. Sure the standards of living may not overlap much, but they are on the same scale.
That's not true of California and Ohio in general.
Regardless of Ohio or California: you're saying that companies should pay less based on the income of their neighbourhood and you don't agree that it will disproportionately affect people of colour.
Interesting perspective, I don’t think I agree though.
Not income of their neighbourhood, but the cost of living in their city/state. It needs to be a big enough region that a good job gives social mobility, but introducing California wages into Ohio would cause massive inflation there, driving normal people into poverty. At the same time nobody could live in LA on Ohio wages.
So, he joined as employee #28 reporting directly to the CEO, then gradually more managers were slotted in above him, then one of the managers put him on a PEP, then he got the hint and left. I wanna say this story is pretty standard, and probably a big part of the reason why people in big companies often don't do great things.
Heck, even if you start a project within a company and it gets successful, the company can just slot in people above you, so you become employee #n in a project that you started, and then these people can say you underperform and so on.
My read is that he was one of those early employees that is a huge pain to manage. They want to do what they think is fun and interesting and they have strong opinions about shit that is ultimately inconsequential. It's a nightmare to manage an IC who is friends with the CEO and doesn't think you're making the right choices. But ultimately they don't accept accountability for any decisions, they just move bop around and cause problems.
One tell-tale sign is endpoint security and using his own device. It's the kind of permissive cultural thing that does not scale because of compliance issues and developer productivity overhead. But it's very hard to wrench these long-time devs away from their preferred Linux distribution which requires conditional build stuff everywhere to support. Use a work computer for work, let them monitor the updates and stuff, as long as they're not using the webcam to record you who cares?
The database backup story - my guy you were on the database team. Backing up the databases is job 1. You can't just passive-voice away "oh there were no backups". But of course he's more interested in fighting about sharding architecture than actually keeping the site running day-to-day.
His big takeaway is that Gitlab didn't spend enough time on performance for their hosted offering which was a huge money loser. Just because he thinks performance stuff is fun to do, if the hosted offering is a money pit of course they're not throwing more resources at it. You have to make an actual business case for why your thing is more important and makes money more than another project. You don't just engineer in a vacuum for the fun of it.
Your read lines up with another point in the article that I found to be stated in strangely absolute terms:
> you need to be able to deploy your code fast, i.e. within at most an hour of pushing the changes to whatever branch/tag/thing you deploy from.
This sweeps under the rug all of the potential issues with fast deploys. I guess it depends on the product. I work on a managed database service, and one category of potential bug is that we accidentally delete or corrupt customer data. We have to be much more careful and can't just deploy what was submitted to mainline in the last hour without doing significant regression and performance testing.
But anyway essentially the main reason they give for fast deploys is:
> being able to see your changes live is nice because you actually get to see and make use of your work.
I think this is true. But, it lines up with this negative interpretation of this article. The author seems to prioritize themselves over the health of the product they're working on.
> It's a nightmare to manage an IC who is friends with the CEO and doesn't think you're making the right choices
Since I find this take harmful, let's rotate the scene: what if you have no business being in the manager's seat above that IC in the first place, and you are effectively being used as a tool by someone who is not the CEO, but, say, a newly-appointed CTO? What if you _are_ making the wrong choices? What if that IC is one of the few people in the org having the experience and the knowledge to tell you that you are? What if that IC is making the right calls and suggestions, but your implicit directive you got from the newly-appointed CTO is actually to manage that IC out "because they are such a pain for everyone"?
I have been on both ends of this situation and I do believe most scale-ups are _not_ doing a good job retaining and nurturing their early-stage staff+ ICs into their larger era. This has multiple reasons, but it does often feel like there is a lot of value to be had if just those staff+ ICs weren't so horribly mismanagemed. A hire-above-from-the-outside is prime example.
And if I sound bitter - let's just say I have experience being "that IC". It wasn't pretty, and no - I was not an asshole.
In every startup I've been in, there was undue deference to long-time ICs. They didn't normally stir up public fights with execs but they would openly undercut line managers and then move around in the org as people tried to stop being responsible for them.
It's not really clear what you do with a staff+ long-term IC. A lot of them don't want to manage or be involved in leadership, but they want to pull down a huge salary and just do work that is frankly replaceable by a senior eng.
To be clear I do believe there are levels of IC experience above staff, but being 21 and joining a startup doesn't make you a Principal Engineer just because you hung around until you're 30. Especially if you've only worked at that one startup.
> It's not really clear what you do with a staff+ long-term IC
Set clear expectations in the first place. "I want to run things my way here, I'm the new management and I don't like you" is not an expectation - and that's what I have observed happen all too often.
Sure, you could argue such people are needed only at the early stages of a company, and counterproductive when the company gets bigger. But I don't buy that. Why then are big companies asking all the time: "Oh, where's our internal startup spirit? How can we bring it back?" Right after firing the people who encapsulated that spirit, for being "hard to manage".
I think this trend to talk about startup practices in large orgs is more executive nostalgia and a complaint about all the processes put in place to catch mistakes that have been made before.
The same people as developers would be pursuing rewrites of rock-solid 20+ year mature software projects because there's a trendy framework.
Large organizations don't have 'startup spirit' because 'startup' companies fail. Employees of large mature orgs with 6000 employees didn't sign on to a company that's got a good chance of not existing next quarter. They're not taking massive risks and throwing halfbaked features into a brand new product with 1 client hoping to get bought by facebook or maybe an insurance company.
If those big companies are really complaining about not having startup spirit maybe they should provide an exit for the VCs and aquihire (briefly because the engineers will all leave asap) a startup!
Sometimes it is not even about the "startup spirit", but more like "why is it that we didn't do any projects of significance in the last year, and why is our incident rate 3x from what it was just 3 quarters ago, and why are all these migrations not finished yet?"
Because sometimes all they're after is for slideware on GenAI. The people they fired encapsulated a spirit of innovation that doesn't fit the operating model and therefore is of no value to them.
I can assure you that me being a pain to manage wasn't the problem, nor was it ever brought up. In fact, the only negative/improve-upon-this-thing kind of feedback I got once or twice was to adjust my communication style to be less blunt/harsh, something I agreed with and did end up improving upon.
I can also guarantee you that the work I did very much did good work instead of "cause problems". Feel free to ask anybody that worked at GitLab during the same time (or is still there) and see for yourself :)
> I didn't get along well with this manager,The resulting conflict lead to a "performance enablement plan"
Respectfully, in your post you literally say you got a new manager who PIPed you for being hard to work with. The whole tone of the article feels like rehashing old disagreements.
Respectfully, I didn't. I specifically wrote the following:
> I didn't get along well with this manager, The resulting conflict lead to a "performance enablement plan", a procedure meant to get things back on track before the need for a "performance improvement plan" (PIP). A PIP is meant to be used as a last attempt at improving the relationship between an employee, their work, and their employer.
Not getting along with someone doesn't imply or mean that a person is difficult to manage. Instead, it means there's simply friction between two people.
In this specific case, the main source of friction was that my messed up working hours resulted in me performing tasks later than expected (though still within any deadlines), though I recall those time frames not being well specified to begin with (i.e. it was more of an implicit assumption that X would be done by hour Y).
I believe I was also a little late for a meeting because I'd overslept. That's not good, but it certainly isn't a case of "Wow this person is so difficult", instead more of a case of "This person needs to get his schedule back together".
Either way, you seem to be interpreting the story in a way different from what's written down. I doubt I can change that, so I'm going to leave it at this comment.
how can you assure that? it seems like a classic self-fulfilling prophecy of arrogance.
changes bring some adjustment uncertainty, and sometimes it goes well, things get better, sometimes it gets worse. with enough time you'll draw a short stick. it sucks.
> how can you assure that? it seems like a classic self-fulfilling prophecy of arrogance.
Because colleagues have told me so, and the annual employee reviews were positive as well. In fact, outside the PEP the only actionable/to-improve feedback I got was essentially "Sometimes you can be a little harsh/blunt", which is vastly different from "this person is difficult to work with".
The dev who makes shit work and and tracks measures the ops gains / reduced headcount needs and reports their impact up the chain. Who also gives talks on how everyone can make their stuff run as simple as they do.
I have that at the current company I work at. Some manager started a successful project with me and the management is too greedy and busy trying to replace me and the manager by bringing in politics, social dilemma and putting layers of management between everyone. Truly a sad state to be in. I learned my lesson as to why you should never truly care about what you do at work. Feels like the project will rather go belly up and disintegrate because of that.
You should care about the work you do. Just remember who you are doing it for. They own the work they being the company. If the company wants to reward incompetent kleptocrats then I salute them as long as I get PAID the second they stops happening they can with the greatest of respect get f’d. then you just take your trade and apply it somewhere else having learned expensive lessons they paid for about what worked.
> to replace me and the manager by bringing in politics, social dilemma and putting layers of management between everyone.
sorry, this seems ... too vague for me to understand what's going on, and how it connects to their greed.
are they trying to 'scale up' this project? why aren't they keeping you? replace you how? in what capacity? are you currently wearing too many hats according to them? can you please give some details?
> Heck, even if you start a project within a company and it gets successful, the company can just slot in people above you, so you become employee #n in a project that you started, and then these people can say you underperform and so on.m
The trouble with these stories is that they’re n=1 anecdotes and we only get one side of the story.
There’s an implicit claim in many comments here that we need to assume that the employee was actually a higher performer, didn’t need managers, didn’t deserve a PEP and so on. That’s understandable given that we tend to put ourselves in the shoes of the person writing a piece and being anti-corporate is always popular on HN.
However, those aren’t safe assumptions in cases like this. I’ve worked at a couple early stage startups that acquired early employees who couldn’t (or wouldn’t) grow with their role and the company. It’s common to keep early employees around out of respect for their past work, a belief that they hold difficult to replace historical knowledge, or simply because they’re well connected to founders and other early employees who have grown into leadership positions.
But in reality, simply being an early employee and being involved with early important projects doesn’t necessarily mean that person is the best person for the job or even a good fit for continuing to do it. Some of the early stage employees I worked with were great at cobbling something together from scraps and keeping it functional with a collection of cron jobs and manual interventions, but their operating style doesn’t work at a bigger company at all. If they can’t adapt and change or they become disgruntled about having to work on things the way you have to at a bigger company, they start to become more detriment than help. That’s just one example of many different potential failure modes of early employees as companies grow that we don’t like to talk about.
> I wanna say this story is pretty standard, and probably a big part of the reason why people in big companies often don't do great things.
It’s “standard” in the sense that every early company has a number of early employees who don’t grow with it, but it’s not the only or even a common fate. GitLab has plenty of employees who have been there for a long time, but you’re not hearing about them from disgruntled blog posts. Consider the selection bias when reading this.
As for the claim that they can’t do “great things”: I’ve used GitLab for a very long time and I disagree. The product continues to evolve. It’s not a stagnant product at all.
I largely agree, especially with the sentiment that there are two sides to any story.
I think one angle I'll nitpick though is this doesn't have to be related to whether or not the employee was a high performer or had particular leadership needs or whether they're adaptable to the current maturity level of the org. There can and likely are many other elements such as whether the manager/employee even get along, or agree on direction, strategy, problems, etc.
And the difficulty is, these types of issues can often show up as performance issues. In lots of cases, is the performance issue the employees fault or the leaders.
In my anecdotal experience where a job went from the best role I ever had to one of the worst happened over a very short week or two with the change in a manager. And I think to the point you're making, when I resigned I outright said... each of us is going to blame the other for my departure. The hard truth is the answer is likely if either of us had been different people I'd still be in that role doing work I really enjoyed, but in that particular leader/follower relationship we simply didn't get along well at all.
If I ever did a what it was like or why I left post, I'd probably have plenty of arguments for my side, because I think to your point, I'll be the hero in my own story.
> In my anecdotal experience where a job went from the best role I ever had to one of the worst happened over a very short week or two with the change in a manager.
Two managers in my case, both of whom were, let's say, not successful in their roles. And a glass ceiling so that I had to do most of the work _and_ be a tech lead, yet "could not manage the team because reasons".
Sudden reorgs + hire above + glass ceilings = golden ticket for horrors like this.
‘He worked remote’ thought popped into my head. He wasn’t there to “grow into leadership role” with the rest of the early employees. I do agree with your read of the situation.
btw, that restaurant in Amsterdam is apparently the go to place for startups. I am certain I sat in one of those chairs (was this on 2nd floor facing the canal?) with another fabled startup.
I recognize the feeling of shouting into the void trying to get people to care about something.
You’ll be telling, showing, raw stats, massaged stats, appeals to authority, what have you, but if the only thing the directors care about is features, it’s all for nothing.
After 3 years it finally became a problem because they noticed that releases kept failing, but I don’t think it had anything to do with me so much as someone typing ‘how to stop my releases failing’ into Google.
I don’t know how to solve that, as I’m going through the same thing again now (with a different subject).
From my own experience as very early employee, I know how it feels, to have them slot in more leads and managers above you and step by step losing the mechanisms, that enabled you to be very effective early on, when you just got things done. Later every step needs to go through some slotted in manager position, making sure you don't work on something "wrong", no matter how much your early ideas and contributions enablef the company to rise in the first place.
I wonder if this is what is behind years old stale issues of gitlab, especially regarding Gitlab CI. From the outside you get the impression, that they completely lost ability to build great things, since they do not seem to care to fix years old bugs that still come up again and again.
I thought it was a great write up of the lifecycle of a successful startup. If you stick around you get to see a lot of change. Some positive some negative. Of course at 1000+ people you can’t have everyone reporting to the CEO
A better approach is to have separate career tracks for 'people' managers and 'project' managers.
People managers do the performance evaluations and various HR administrative tasks (signing time cards, hiring, firing, etc.) but they rely on feedback from their group which are both individual contributors and project managers.
Project managers lead the projects and have to select/attract the right combination of individual contributors to their project if they want it to succeed.
A project that 'gets more management' will usually have to justify the addition of PMs from a cost-benefit perspective. And a project that is overburdened with management types will usually see the ICs migrate to other projects in order to improve their impact.
All this happens organically, so individual contributors are empowered instead of being disenfranchised through organizational changes.
That sounds like basically matrix management which has many well documented issues. The biggest one in my experience is that the people managers need to be themselves judged on some rubric. If that rubric is success of projects then it tangentially aligns with business goals. If it's something else or they don't have power over projects then they are encouraged to play constant politics.
> Why would they need to play constant politics if they don't have power over projects? Not everyone is motivated by the same things.
They do have power over the projects. Being able to PIP someone is power over everything that person does including which projects they work on. Including which projects no one works on. Except it's not their direct power which means to leverage it they need to play politics. Adding layers doesn't remove that power but simply increases the amount of politics they play to make up for it.
The goal with the matrix management is to distribute the risk. If your people manager puts you on a PIP then at least your project managers will have some ability to push back on that.
But there is no good reason for the People manager to care anything about what projects have people working on them. If they start to care about which projects are successful instead of all projects are successful then they're not a good fit for the job. And yes I have experienced that, as well as it's opposite.
and this leads to 4 engineers and 6 managers sitting in a meeting, and nobody actually being responsible for anything.
no, of course, there's a lot of value in providing escalation/descalation/rehoming processes, and dedicated ways for org-wide feedback on people's and projects' impact, but people are not just three orthonormal roles on top of each other in a trenchcoat, if there's not clear hierarchy then - as others pointed out - the informal chaos takes over (because it's the human default)
Do you have any practical experience with companies running as it's described in this motivational book?
Many of those books are selling well because they are well written and say exactly what reader thinks might work, but if you ask anyone else who worked with the author, the reality can be quite different.
> Do you have any practical experience with companies running as it's described in this motivational book?
I do not have experience running it at a company level, but at a team level (I have been an engineering lead in two companies for the last 6 years).
From all the books I've read (I read a lot), this is the one that was most "spot-on" about treating other humans and making them feel valued and therefore building a team with strong bonds.
> Many of those books are selling well because they are well written and say exactly what reader thinks might work, but if you ask anyone else who worked with the author, the reality can be quite different.
Absolutely agree.
In my experience I resonate most with any books when I have already, unbeknownst to me, been applying what they preach (which has been the case with Setting the table that I'm currently in the process of finishing).
I believe that it requires a lot of introspection to be able to apply new knowledge (ie, if you haven't thought about it or experienced it before reading about it)
That's what I like about "agile roles" like Product Owner or Scrum Master, they take a slice of traditional manager's responsibilities, but they don't have any reporting authority over other workers. My EM has like 30 direct reports and it works fine because he doesn't really have anything to do with our day to day work.
Those semi-managerial roles are the biggest problem with that model, in my opinion. Sure, it works as long as everything is peachy. But as soon as there are any real conflicts of interest, it will show who is the real manager. And it's not the product owner or scrum master.
With authority comes responsibility for your actions. Without responsibility, no authority. The product manager is a manager in name only, and product owner even less so.
That doesn't mean you can't have several direct reports. The classic matrix organization for example. But it means semi-managers without real responsibility have no real mandate for doing a good job at the slightest hint of trouble.
> But as soon as there are any real conflicts of interest, it will show who is the real manager. And it's not the product owner or scrum master.
If there's a conflict of interest, it needs to be discussed based on merit, not based on who has the bigger authority.
If there's no agreement, it needs to be escalated to somebody who has the authority (manager). But IME this doesn't happen very often.
I like this model, because the default position is that none of the engineering, product, process is the "master", so you need to negotiate. If one of the roles also has reporting authority, that automatically skews the decision making towards yielding to them.
I'm not sure how you can evaluate 30 people you don't interact with closely.
NIMS, the National Incident Management System, talks of ICs having between 3-7 direct reports, when there is a need to be connected to what they are doing, because beyond that, you can't reconcile things easily.
That list of “skills” is spot on. I also especially like his use of the term “skunking” to describe how somebody’s personal opinions/problems/issues impact the rest of the team. “51%ers” are exactly the kind of people I want to work with.
I hope I'm not violating any copyrights – page 143 of Setting the Table from Danny Meyer [1]
> To me, a 51 percenter has five core emotional skills. I’ve learned that we need to hire employees with these skills if we’re to be champions at the team sport of hospitality.They are:
1. Optimistic warmth (genuine kindness, thoughtfulness, and a sense that the glass is always at least half full)
2. Intelligence (not just “smarts” but rather an insatiable curiosity to learn for the sake of learning)
3. Work ethic (a natural tendency to do something as well as it can possibly be done)
4. Empathy (an awareness of, care for, and connection to how others feel and how your actions make others feel)
5. Self-awareness and integrity (an understanding of what makes you tick and a natural inclination to be accountable for doing the right thing with honesty and superb judgment)
For future reference, you are certainly not violating US copyright law, because quoting a few sentences from a book falls under fair use. https://en.wikipedia.org/wiki/Fair_use
I was curious why the author decided to call them "51 percenters." A google search of the term suggests that the skills of this group of employees are divided by 51% hospitality and 49% technical excellence. Please feel free to correct me if there is anything wrong in my interpretation.
Exactly! I’ve never been able to express a succinct list of why some teams and/or companies feel better than others, but “51%ers” explains it perfectly.
Someone "whose skills are divided 51-49 between emotional hospitality and technical excellence" [1]. Seems quite bizarre to me to define it so precisely. Even if skills were measurable in such a way, how many people will be exactly 51% emotional hospitality, and why is 52% or 50% not suitable?
i think the implication is if a 51%'er has to decide between technical excellence and emotional hospitality then, all other things equal, they will use emotional hospitality since that's the majority of their skills (51%). It sounds like preferring to hold a hand vs rejecting incompetence. I don't really agree, i get not being jerk is important but i would flip it to 51% technical excellence 49% emotional hospitality.
I find the bit about employees being permitted to use their own computers almost astounding. However small an organization is, it should be insisting on providing a company-owned machine and having all company business be conducted on that machine.
This has massive benefits to the company in terms of control of corporate IP, huge benefits to the employee in terms of separation of work time and personal time, and it doesn't even cost that much to do.
Semi-related, I would recommend to anyone who is a Linux native to try to find some kind of "minimum viable setup" that is really really easy for you to run out of VirtualBox or Parallels or something for this reason. No matter where you go, you know you can have a suite of tools which work just as you want them to there. Being able to tear it down and rebuild it quickly is also a great way to deal with debugging certain kinds of problems of the "it runs/doesn't run on my machine" category.
How you do this is of course up to you. At one end of the spectrum is just relying on your memory. At the other end is using NixOS https://nixos.org/ to get fully reproducible builds anywhere you go. Between these are a vast field of options. I know a guy who maintains an Ansible file set to `host: localhost` which installs everything he wants from that file. For me, I just stick with the latest Ubuntu version and maintain a few shell scripts [1] that install 80% of what I like to have on a new install.
If you like the scientific approach, you can install something like https://atuin.sh/ and do some statistics on what programs you actually run most frequently based on your long term shell history.
Not to mention the inability to enforce full disk encryption and (hopefully) avoid leakage when someone quits.
It’s obviously not a silver bullet but at least then leakage must be hostile action or incompetence by transferring sensitive data outside of authorized channels.
Here's what my previous company did: “please jump on a videoconference call, now please share your screen, and go to the disk encryption settings to show me it's enabled, thank you”
You get the same benefit as with stronger enforcement since as you said disk encryption won't protect you from hostile actions anyway.
I strongly disagree, because if the employee isn’t handing in their device when they exit that data is still out there.
As I said, this is not a silver bullet, but for the data to still “be out there” the employee must at some point transfer the data out of the company device, which should be a policy violation.
Also, I honestly personally think a company not providing hardware is a huge red flag, I’ve never encountered it in 15 years (but maybe it’s less common in Europe, I don’t know).
Unless your company provide automatic backup management with straightforward recovery for your employees (which I've never seen, including at customers), your most cautious employees will backup their device in order not to lose their work, and then there's always data “somewhere out there”.
Again, the way you deal with employees having company's IP remaining on their computer is to set up a call and ask them to remove it. Good faith employees will do it, bad faith ones would have copied it on their drive before handing out the computer in the first place.
> Unless your company provide automatic backup management with straightforward recovery for your employees
You make this sound like some kind of pipe dream. I don't know what companies you've been at, but for a lot of large corporations today it's completely normal to store all your data in the cloud, from documents at O365 to bespoke SaaS services like gitlab or book-keeping or whatever -- and the ones that don't do it for whatever reasons usually do something very similar, just internally via self-hosting.
If every single employee needs to back up their unique snowflake workstation, then something is fundamentally wrong with how data is handled in the first place.
> your most cautious employees will backup their device in order not to lose their work
The reason employees do this in the first place is because they don't trust the company to ensure the data doesn't disappear. That's the problem right there. I've seen it many times and it's always in chaotic companies filled with shadow IT, which of course are the most vulnerable companies for the same reason.
Of course there's something fundamentally wrong with how the data is handled in the first place at most company big or small, welcome to the real world.
BTW the setup you describe with data being replicated in various places without specific coherence is exactly a situation of “there something fundamentally wrong”, and I've yet to see a company where there's a whole-PC backup job running in the background that gives the ability for the IT to give you a clone of your computer on demand in case of loss/failure (and I'm saying a clone of the computer: from the post-it to-do lists, your keybindings/ preferences in software, your bash aliases and small helper scripts, to the customized toolchain you spent three days setting up on five years back and don't remember how to install). Not everyone uses their computer as a mere PowerPoint consumption device…
I suppose companies using Mac could do that because that's exactly what time capsule allows you to do but idk if that's easy to deploy company-wide.
Anyway, none of what you said justifies to block workers from using their own device (they can and will use the cloud tools you mention with no issue from their computer), and invoking IP protection reasons is just security theater.
I'm not a lawyer so take the comment with a grain of salt, but employee's should likely insist on using company devices as well. If the company were to be sued it may open up the personal devices to all sorts of subpoena for the contents of the device.
All popular operating systems support multiple users. There is no worklife balance benefit whatsoever for the user to require a separate machine. It is only inconvienient.
1. What happens when you have a legal dispute and all of your personal data is now caught up in the legal discovery process? Repeat for layoffs, etc. where you have no warning to make backups in advance. Don’t forget to think about what happens if you look for another job and your record of that is on their system.
2. How painful will the conversation be when someone’s personal activity leads to them getting malware, and now you have to treat that as a company breach, rotate everything they have access to, contact every user whose PII was in test data or bug reports, etc.?
3. Say you work on something on your spare time, but some suit insists that it’s company property since it was developed on company equipment. How much fun will it be arguing that you only worked in your spare time?
4. Where is the convenience, really? It’s probably not actually the case that you are getting paid to swap interchangeably between work and home, or that you work on the exact same things (if so, good luck convincing the lawyers that they don’t own your work), so you’re probably using that convenience to contribute unpaid overtime to your employer. Having a hard boundary between those is usually mutually beneficial.
And using a company computer somehow prevents me from doing that? Most spyware that they force upon you doesn't seem to, in any way, prevent me from just uploading a zip file to wherever I want.
I have a few 10-15 year old repositories backed up somewhere, but surprise surprise, nobody (including myself) cares.
It’s theoretically possible for someone to do something bad with them, but it’s just not realistic for 99.999% of the population. I guess it becomes an issue when you have 100k employees.
That is still clearly intellectual property after 15 years. There could be trade secrets in there. And the slightest suspicion of which is a good reason to sue you, should anyone every need a reason to. It could be an personal conflict spun out of control or an incompetent manager needing someone to blame for a failed business or whatever.
If there are any customer data or logs in there, then you could be personally liable under data protection laws. They might not even have an expire date, depending on what kind of data it is.
Better safe than sorry, unless you think you have something to gain from keeping that data around.
I would care. 10-15 year old is probably no longer an issue but technically they're a liability and if they were much younger (which at some point they were) they would be a much larger liability as well as an issue if you ever went to work for a competitor and this came to light (like it just did...). It's not to your advantage to have copies of your former employer's IP and possibly even data laying around. Hostile audits are a thing too, again, on 10 to 15 year old code probably not because that code either has changed considerably or it may have been abandoned.
> huge benefits to the employee in terms of separation of work time and personal time
While I agree that separate work and personal computers might help in this regard, in my opinion it only helps a little.
I believe that behavior related to separating work time and personal time is influenced primarily by one's own habits, abilities and, in the end, decisions.
Giving the choice is what benefits the employees more: sure if you want more separation that's nice to have the option, but I prefer by far use my own computer when I'm WFH because it's a beefy desktop. In any case being forced to use a company mandated operating system is a nuisance for productivity… (be it Windows, where productivity is just bad, or MacOs where I need to relearn everything starting from the most basic key bindings …).
Also, companies have no control over corporate IP that land on an employee-controlled PC anyway.
> I find the bit about employees being permitted to use their own computers almost astounding. However small an organization is, it should be insisting on providing a company-owned machine and having all company business be conducted on that machine.
I've worked with small and startup healthcare/healthcare-tech companies who not only permit it, but have formal BYOD policies... when they are dealing with PHI.
Honestly, the company will never care as much about my machine as I do. It’s always an uphill battle to get anything more than whatever they think the default spec should be, so I’d consider it a feature if I could use my own machine.
From an employers perspective, maybe. From an employee perspective? Yeah I'd much rather use my (much more powerful) machine where I have everything set-up exactly how I like instead. Tons more convenient.
it's GitLab, open source / open core / source available, MRs in the open, etc. there's basically zero difference between internal/external contributors. (unless the employee was working on some embargoed/security/backoffice/infra stuff)
I used to feel this way, but largely grown out of it. In the end, you're asking for SF salaries, and those in India are asking for NL salaries(or SF salaries). You'd largely find a race to the bottom, I think.
The simple fact is you made a good living for your area, and they made a good living for theirs. If you want more, move. If you won't move, there's likely a reason why.
Everyone wants a SF salary with an Indiana or even India cost of living. For obvious reasons, that can't work.
From the other angle: There exist companies that do not do location based pay. If you're hired, you get a US level salary, whether you're in San Francisco or Poland or Indonesia.
These positions are phenomenally competitive. You have swung open the doors to the world, and said "Give me what you got!", and you reap the benefits by having a much, much larger pool of applications and talent to sift through, with a lot of truly exceptional people in there - mostly very intelligent, very driven people from poorer countries.
That's how supply and demand works. If you are offer to pay people more, you usually end up hiring a higher quality candidate.
Yeah those companies don't exist because they would be wasting money. Salary isn't "location based", it's "competitive salary based". It just happens that competitive salaries strongly depend on location.
If you were to forget about location and just say "we'll negotiate all salaries" then you would end with exactly the same result because people in NL are willing to work for much lower salaries than people in SF.
I don't get why so many smart programmers don't understand this basic fact of economics. Eh maybe they do understand it and are just jealous of insane SF salaries (I certainly am!).
I would be wary of demanding equal pay by location anyway because you'll end up with all jobs moving to India.
Those companies do exist. I can confirm specifically that at least when I had an offer from Supabase they paid everyone, internationally, regardless of location, the same pay bands. Being USA based it was one of the reasons that I turned down the offer because I was able to get a much higher salary elsewhere but it would have been extremely competitive had I taken the role and moved to some place like Vietnam.
I wish I could have taken the Supabase role because it was definitely my top pick otherwise. One look at the output and caliber of people they hire also indicates that they have little issue finding talent.
FWIW this was a couple of years ago and I have no idea whether they are still doing this equal pay band thing or not. But they were doing it for awhile at least
The fact is that location is irrelevant for some roles. If you are looking for top talent, you'll pay top talent value. If you constrain your hiring to a single location, you're simply reducing your own pool of candidates.
Today, most labor arrangements are more and more like companies. If you were to select top companies to contract for some job that doesn't really care about location, you wouldn't be choosing companies based on that. You'd choose based on how good they are.
It's the difference between trying to buy the cheapest versus buying the best. Of course if you're always looking for the cheapest, you'll always move towards overseas jobs. But if you're looking for the best, you can get the best from all over the world by offering a single solid compensation package.
It's all a transaction, isn't it? At the end of the day my labor is worth however much I can get for it.
Sure, you could squeeze even more profit by paying overseas workers less, but then you create all sorts of imbalances that can and will hurt your business in the long run.
I always joke that if you want to hire me (I am not from the US) and pay 50-60% less just because I live here, why wouldn't I work 50-60% less?
You're getting the 1% of a lower income country, for an average local developer salary. If you want the 1% of SF you'll have to pay a lot more, even if they are equivalent in the value they provide. The company still wins, and as a result you get happier employees.
You can always cheap out, but it's never without consequences.
> Yeah those companies don't exist because they would be wasting money.
Basecamp has been around for 20+ years and they publicly mention that they hire based on SF rates, not even SF but the top 10% of SF[0] for positions around the world.
When you have only 30 employees, and your people at the top are buying multiple supercars and planes, and your revenue is somewhere in the ball park of $5M+ per employee... you sure as hell better be paying salaries commensurate with that, or people are going to be bitter.
Indeed. I don't understand why a remote company would want to pay top dollar for a mediocre developer living in the US, while refusing to pay the same for an exceptional developer living somewhere else.
Because of marginal returns on applicant motivation. A $200,000 position sounds great to a person expecting $150,000. $200,000 also sounds amazing to someone expecting $40,000. But, the same person expecting $40,000 will also be amazed by a $100,000 position, and certainly not half as amazed as the $200,000 one.
You also know that companies are looking to optimize margin, so those US level salaries are only temporarily. Given enough good people in India, or other low-income countries, that pay level will drop significantly.
What makes you think US level salaries are temporary? Isn’t this the case for last 40 yrs? Why it will change now? Is it due to advance in remote work or more supply?
Sure, that's of course what we would expect. However - and I don't know about you - if my options were between getting paid $200 a month as a farmer with my dad, or earning $8000 a month as a software engineer in my room, I would probably still take the $8000 option, even if it only seemed like it would be around for 3 months.
I may even be grateful for the chance, instead of angry that it wasn't a deal that was going to last in perpetuity. I admit I may be in the minority here.
I recently visited some teams in India, they indicated quite a few coworkers moved back to India to be closer to family and friends. Not everyone is dreaming about moving to the US. And yes, I agree that I couldn’t see myself living in India, with all the pollution and overpopulation…
I've worked with teams from Bangalore who were staff of the bank I was contracting for -- they were amazing, but also not appreciably (if at all) cheaper than employing someone in London or New York.
Several well-known banks had large offices, and competition for talent was high. No race for the bottom there.
It doesn't particularly matter where you employ people, if you're trying to save costs by paying people less then you're going to have a bad time.
Good engineers will accept lower payment if their costs are lower. Similar to how amazon is operating, by lowering costs, minimizing margin, they can win over customers and win the market.
Conversely, if there is a shortage of known-to-be-qualified engineers then anyone who is any good will command a high salary regardless of their cost of living.
If you want to pay them lower wages, they'll work for someone else instead.
A consequence of that is that local companies, that have local economy level income, can't compete on salary with those foreign companies. So they can't get the top-tier workforce they used to have access to. Ever increasing the economic disparity between countries.
They allow brain drain to happen, without the barriers of having to move countries.
I'm pretty sure someone making 2-4x their local salary for a remote company and paying taxes is healthier for the economy than working your ass off (or not) for a local startup that wants to end up getting acquired OR doing the same remote work with 2-3 layers of management extracting the difference in pay. At least in Poland I can't think of any single company I'd want to work for.
There is also the factor of the country receiving hard foreign currency, which I understand is generally quite desireable. This is less relevant for EU vs US compensation, but for more developing ("3rd world") nations could be significant.
If they don't have to move countries, it's not really brain drain at all. It's exactly the opposite in fact.
If they did have to move, then they would, and you'd have brain drain. But because they can remain in their communities (while earning the globally-competitive income that they would otherwise have to move for), they now pay taxes to their local government, buy from local businesses, mentor local youth, and so on. When they've earned enough money from their job, they may quit and start a startup in their own community, or become an angel investor supporting startups in their area, rather than yet another bay-area based fund. These are all good things!
You might be right, if we assume that everyone who takes these high paying remote jobs also makes sure to never ever spend the money they earn locally, either.
However, if I was earning an order of magnitude more money than I currently am, I might want to pay a little extra to go to the really good barber, or to eat at the really nice restaurant at the riverbank. Or, hell, I might just employ a cleaning service every week, to save myself a few hours' time vacuuming my apartment. These necessarily local services will also see their revenues rise. To me that seems to be a more important effect on the local economy at large.
But how would you feel about working as a barber, chef or cleaner, when you could earn two orders of magnitude more making Internet thingamajings for people on the other side of the world?
New York never has a critical shortage of barbers, chefs or cleaners even though for many decades it’s been possible to earn 100x as a Wall Street bond trader or quant.
A healthy growth economy can tolerate income differences. But the balance is certainly precarious, as the example of New York or London shows. It’s constantly on the edge of driving out the remaining barbers and chefs because they can’t afford rents.
But the money stay in the country and increase the chance that the employee eventually starts their own business, possibly using the cheaper workforce as an advantage.
A smaller company can do it. The post links to a post by Bryan at Oxide Computer. The salary scheme for the generally senior people they hire is quite egalitarian. It's also pretty modest by senior-level Bay Area (and even many other locations) standards.
Probably. But some percentage of people who buy into what the company is doing are willing to take lower pay to work there because the pay is "enough" or whatever.
This may work if you are only hiring senior people, but imagine hiring some mid level or junior employee. if US junior salary is Poland senior salary, would you willing to hire the senior dev from Poland to junior position ?
The issue I see is that software engineering is a team sport. Having a bunch of intelligent driven people doesn't mean they will together act like an intelligent driven group. Work cultures differ greatly between countries including in some subtle unconscious ways. Even Western Europe versus the USA have a very different dynamic in terms of how ICs and managers interact with one another.
But when Indians, Germans, or Canadians move to the Bay Area for better pay, they don't immediately (or necessarily ever) become culturally Californian. They might put their complaints aside for the paycheque, but they'd probably have equally-happily done the same as a remote worker. Especially when their whole organization is remote anyway, so there's essentially no subtle cultural difference between a Canadian working from Canada, and a Canadian who just moved to Mountainview while zooming from their spare bedroom.
Furthermore, if the difference in compensation is really explained by differences in employee productivity caused by work culture barriers, then location-based pay must somehow maps to the productivity cost of that work-cultural barrier. There's no reason to think that this should map directly to cost of living, and it would change over time; if the workforce composition shifts towards Europeans for example, then now it's your workers in the bay area who are less productive due to missing subtle cultural cues from their German managers.
Now see that's an interesting problem space to be in. Keen eye.
To me it seems like a really exciting place to apply recent innovations in LLMs. If LLMs can chew through thousand page legal binders like toilet paper, there's no reason they can't chew through a thousand 1-page resumes and spit out "These are the ten most promising ones based off of our statistical analysis." Firms can specialize in the production, hosting and fine tuning of these LLMs, and even play both sides of the market by allowing candidates to see how good their resume looks for a given job description.
I think this is much likely to become a lot more common in the latter half of the 2020s.
Whether or not it is pleasant for the applicants, it'll happen if it provides a benefit for the companies. They don't care about the applicant experience because they have no incentive to.
The flipside of this is that there will be an asymmetric advantage available to firms that are capable of finding excellent candidates that fall into the ML blind spots.
This is the dystopian future that is likely already happening. Slowly but surely we will lose control over our own labor. As the name implies, we're just human resources.
> you reap the benefits by having a much, much larger pool of applications and talent to sift through
Interviewing/hiring is incredibly noisy though. If SF engineers have a much higher average skill than the rest of the world then you might still end up with better people if you just hire from SF rather than the world in general, even if the latter has a much wider pool with more top people in absolute numbers.
To be clear: we don’t only hire in the US. We have employees in at least the US, Canada, and Europe at the moment.
We do want some overlap in working hours with the US, so it is true that we cannot realistically hire anywhere just yet, but not being in the US is not a dealbreaker.
This suggests that cost of living in SF is the cause of high salaries but in fact the only reason SF/Bay Area has high cost of living is because of the high concentration of highly capital efficient businesses with strong skilled labor demand coupled with the complete unwillingness to build high rise density most places in the Valley area. I know quite a few people who make SF level salaries working remote in random states across the country. Of course it can work. And SF should not get too cocky. Detroit used to be the Motor City, Music City, and a cultural and technological force in the world, but then its core competencies got disrupted by cheaper, more efficient labor elsewhere.
> you're asking for SF salaries, and those in India are asking for NL salaries(or SF salaries)
No. You got it all wrong.
You're asking for equal pay for equal work. If all your team members are paid in full but you, in spite of doing the exact same work, are paid a fraction of what they are paid, then something is terribly off.
Your contribution to your team does not depend on where you're currently located. How much time you waste on commute does not change the expectation placed on your output. If your office location is prohibitively expensive that means your company needs to sort their mess and work on a location that's more affordable. It makes no sense that you need to subsidize your employer's bad office location.
Why does it matter? Salaries should depend on the value you deliver. I don't think companies limit their profits depending on the location. Apple devices are often more expensive outside the US.
While I can empathize with this, this is a moral judgement. Price is not determined by fairness, but by offer and demand (and other factors). Otherwise teachers might earn more than football players. I think one could argue they should.
I agree. It's just supply and demand. I just disagree with people saying salaries are somehow pegged to living standards. No it isn't. Companies don't care about your living standards. They pay what the market commands thats all.
Whilst we all want SF wages, those wages are because housing and cost of living in SF are exceptionally high compared to say Bali.
So you want to earn 200,000 USD. Whilst living in a part of the world where that effectively places you in the top 1% of earners.
You're only looking at this from that angle. What about the person who's living in SF, and scrapes by paycheck to paycheck. Whilst you live in a much cheaper area to live in, and you have a very different financial situation. Your both paid the same wage.. because "fairness".
You might say, "JUST MOVE". But do you think that's a fair thing to tell someone?
Sure people move to places like SF, but people do that for more than money, they do it for a variety of reasons. And one of them is that there's a lot of demand in that area for your talents. So if you wanted to change jobs, grow your career, etc.. you can. But that area has a higher cost of living.
You sacrifice some of those things when you move to the small country town, there's no tech hub. No meetups, nothing.
So do you think it's still fair to say to that person "Hey I know you're living hard... But at least you can spend that little money you have left on public transport getting to a meetup!". Whilst the person living in the middle of nowhere can afford first class.
I get what you are trying to say. I'm one of those people who makes that kind of money in a cheap country. I'm just saying its fair from a value delivered perspective. Paying you less doesn't mean the company donates the money saved to a charity. It just goes to the companies balance sheet. I've had plenty of arguments with company exec's about this:
1. its not fair you get to live like a king! -> would you move here to live like "a king"? Oh you don't want to deal with the pollution and the bureaucracy and lack of safety. Ok. Ah so there is a cost I am paying by living in a bad country.
2. paying you SF salaries would be unfair to people living around you -> ok so you would be ok paying that extra amount directly to a charity right? Oh ok you aren't.
I'm saying it's only fair for a employee to think they should be paid proportional to the value delivered. Companies exist to make more money. This causes a clash. In my last company the CEO specifically wouldn't hire staff engineers from cheap countries because he didn't want to give the other engineers the idea that they too can command higher wages.
Just pay people the same amount and let them decide how to live their lives. They are adults.
> The problem with this line of thinking is that cost of living is the same everywhere. It is not.
I don't understand what point you think you're making. My disposable income is not my employer's business, and I definitely do not live below my means to subsidize my employer's business.
You wanted me to do my work in exchange for my salary. Pay me. Don't think for a minute you are entitled to go through my grocery bill to see if you impose pay cuts.
Equal pay for equal work doesn't mean the same pay. It means that an employee from Bay Area, one from Netherlands and one from India are able to buy the same amount of goods on their local markets from their wage.
Remember that all of those local markets sell iPhones at a higher cost in USD than the Bay Area. Exactly which goods should they be able to buy the same amount of?
Ok. So the salary difference should be the difference between the monthly median rent: for a 1 bed apartment that’s $1500/month cost difference, double it for taxes and fuzzy math, salary increase of $36k/year. Maybe it should cover “the median rent”, whatever size unit that is, so $1500 in Amsterdam vs $4k in SF: +$60k. Or should it cover buying a 3 bedroom house, though? That’s more like an extra $8k/month for SF, so salary difference is +$190k.
This kind of detail is where it falls down. Should people be able to purchase the same goods, or the same relative local position in society?
But money is portable, and Local market means a different thing than it did pre-pandemic.
The argument that local cost of living is the only factor falls apart when people are moving from high CoL markets to low CoL markets with their advantaged savings. Especially within a nation, or times of large movement (again, pandemic - where folks with higher CoL wages were better positioned to acquire prime real estate in lower CoL markets).
> Equal pay for equal work doesn't mean the same pay.
Yes it does. You want me to deliver an output, not to slack off if I live X or Z. If you value my work, you pay me. You don't get to claim a benefit just because I chose to live somewhere cheap. Otherwise it would make sense to pay me millions if I chose to move to a penthouse in Manhattan.
I mean, you aren't payed in buckets of rice or whatever. Or even a inflation adjusted basket of good and services.
You are paid in dollars (or equivalent). So they don't get to claim to be paying the basket of goods if they won't automatically match inflation either
>It doesn't matter whether you're paying somebody in the Bay Area $100 000 per year, or somebody in the Philippines, because the cost for you as a business is the same.
The cost for you as business is NOT the same. Start from the taxes part, that 100k is what the employee gets but the cost for the business is higher depending on the country/area because they also pay tax on top, social benefits etc. Also need to have in many cases a local business, doesn't matter if that is virtual etc, since they need to adhere to local laws thus having resources supporting that etc.
So while I'm on the employee side here as I'm also working on a multinational coorp with global role yet paid with local standards, there is more than meets the eye
yep. People vastly underestimate how difficult the logistics of "pay an employee for services" can be, particularly when you don't have a legal corporate presence in the country where the employee resides. There are services that handle this for you and they charge a 30-40% premium on top of the employee's salary. And sometimes this is still worth it, because many countries charge an absolutely obscene incorporation fee for foreign-owned businesses.
Fwiw companies like Remote and Deel charge a fixed fee of substantially less than 30-40%. IIRC we pay about 600 euros per employee per month to Remote. That’s a lot of money that I’d rather give to the employees themselves, but it’s much much less than 30-40%.
Yep, and they choose not to have it unless there's some compelling reason to. We've got staff in many countries, but it's not a blanket "work from wherever you like".
It’s not. If I have to pay some service or agency a lot of money to be able to employ you, there’s less money left to pay you. Employers at distributed companies don’t look at your take-home salary, they look at the total cost to employ you. Fees and taxes differ wildly per country, there’s no other way to compare. So if a large % of that total cost goes to middle men, then that makes you a more costly employee at no benefit to either you or the company.
If I’m considering two people for a job but one is in a place where paying them well means I spend a huge amount on fees (or “employer-side taxes” for that matter, looking at you Austria), I might well choose the other.
so why not set a “total remuneration package” as it’s known where I live. It’s the total value, inclusive of compulsory payroll deductions and taxes, and set the salary to match that. The cost to the company is the same, but your take-home depends on where you live.
in many areas salaries must be specified as the take-home part (including the taxes you pay as employee, but not including the part that the employers pay, which is not part of your remuneration), because doing otherwise would be confusing and could be considered deceptive.
If I work for you, and you're willing to double my salary to subsidize my moving to an area that has wildly more opportunities for me (which is precisely why the salary is higher there), don't mind if I do move there.
You just need to ask yourself if offering incentives to get your employees to move to hot job markets is in your benefit.
Why is that? It isn't obvious to me. It seems like an excuse companies use to pay people less, especially if the company is based in a high-paying city.
> Everyone wants a SF salary with an Indiana or even India cost of living. For obvious reasons, that can't work.
Why should someone living in Indiana make less money than someone living in NYC for a remote tech job?
Both are located in the US separated by a 2 hour flight. Both are in the same timezone too. For a remote company where you have employees spread around the US, there's no difference to anything here.
> Why should someone living in Indiana make less money than someone living in NYC for a remote tech job?
There's no moral reason to satisfy "why _should_", but let's be honest. A company with equal salaries regardless of geo is more likely to cut the salaries of people in expensive places to live than raise the salaries of people in less-expensive places. This is especially true in places where both salary and fundamental necessities like health coverage are included in compensation, like the US.
Such companies then lose the employees who prefer to live in expensive places, to companies who _will_ pay them more to live in more expensive places.
Whether accepting that result produces a more efficient staff for a company is the more indicative question IMO. Or asking why some places are so much more expensive to live in.
> Why should someone living in Indiana make less money than someone living in NYC for a remote tech job?
Because on average they'll accept less money. Someone in NYC is more likely to have other options with higher pay. If a business wants to hire them, they have to offer more. Simple as that.
Same here. The reality is that what company chooses to pay is the minimal amount they can get a candidate to accept for that location.
If the candidate had other better offers, then they can either reject the offer or propose a higher counter-offer. If the company received a counter-offer and chose to accept it, then this amount becomes the new minimal amount.
Over a period of time, if there are enough counter-offers (or rejections), this continues to increase. Since, the two (or however many) locations don't necessarily have the same demand or supply, it's inevitable that some location will end up with much higher compensation than others. It's the nature of free market and why some companies engage/d in hiring collusion (see https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L...)
There are two ways to evaluate salaries / compensation packages: 1. What is your price in the market? 2. How much money do you need to be able to focus on your work and not worry about money. Most companies use a mix of both approaches, depending on the role and the individual. For most employees, the second perspective makes for a better experience. As long as you get enough each month to make the money problem a non-issue, you get to focus on the work itself, which can be a very positive experience. Some people (or the same people at different phases of their lives) want to optimise for getting the highest price they can get in the market. That's a valid choice, but one that in many cases results in a suboptimal work experience.
By that logic, the only one who wins is the company. I would like to believe that most of us, employees, want what’s best for us, employees.
If company X was paying N for a SF engineer, and suddenly it finds out that it can pay N/2 for an engineer that’s as good as the SF one (but lives, let’s say, in Mexico)… well, jackpot for company X.
the issue comes when the pay does not match the living standards.
despite having the least in absolute terms, it is possible to have a great life with the mid-to-high level income in IT there. can't say the same with what most people earn in europe.
in general i agree, but the problem with location based salaries is that they are working for locals, but not for expats. expats everywhere have higher living costs than locals, in part because they will get more expensive housing that is more up to the standard they are used to, and they also may have kids that they can't or don't want to send to a local school, and they will buy more imported food that they are used from home.
when i looked at their salariy calculator i figured that i could not live on the salary they would offer for my location. school costs alone for each child are as much as i pay for rent.
it's a problem because it means that many expats can't work for gitlab because they can't afford to live on that salary.
if i am working for gitlab in my home country, i can't move into the home country of my wife because my salary would be reduced below what we need to live there
But there’s no benefit to Gitlab or to society in general for Gitlab to subsidize people to move to countries where they can be rich compared to the locals. It’s a personal obstacle to working at Gitlab, not a problem with the setup.
strongly disagree. there is a big benefit to have cultures mix and help with integration into an international company, both to gitlab and to society. that's why i moved to china.
i am not demanding to maintain a lifestyle from elsewhere or even from my home. i just expect the acknowledgement that as an expat i simply can not avoid certain extra expenses that locals do not have. with regards to kids, there isn't even another option. children that did not grow up speaking chinese at home have no realistic chance to successfully pass through chinese schools.
why should i not be able to demand that?
this hinges in whether we want people to mix and integrate. if we do want that, then we do need to support people who make that choice. if we don't want to support that, well then we just won't get people who are willing to make that move.
so if gitlab is not paying a salary that allows me to do that, then gitlab is missing out on the benefits of the mix and integration that i am achieving. it's quite simple.
it's fine if gitlab (or any other company for that matter) does not want that. that's their choice. but they also have to accept that the consequence for the company is to not get those benefits. you get what you pay for.
Salaries are based on the market economy of supply and demand. Salaries for a specific role are different in one location over another because that is what the market is in each location.
If you want developer salaries to be the same in all locations for the same level of work for reasons of fairness and anti-discrimination, you should ask why salaries of developers are higher or lower than other roles. Developers get paid highly because of supply and demand. Why not advocate for all workers, regardless of role, be paid the same - this would also be fair and anti-discriminatory. It seems we want to benefit from the market economy on one side and then want fairness on the other side. The logical conclusion of this kind of reasoning is communism where all workers at a company are paid the same, regardless of role. We know how that worked out.
If all developers, regardless of location, were paid the same, companies would much rather hire all their developers in a single location. Why bother hiring in locations far away? Jobs would have never flowed out of high paying locations to lower paying locations.
The Bay Area has the highest salaries because Silicon Valley has had many years to develop and the vast majority of tech companies are based in the Bay Area. Many companies are started in the Bay Area because people who work together in one company often break off and start another company. Many people at these successful companies have become wealthy and this has driven up home prices. This has made the Bay Area one of the most expensive places to live. Other workers cannot afford to live in the Bay Area and so there is a shortage of labor. This drives up the cost of every thing, including restaurants, groceries, and personal services. If the Bay Area does not add substantial housing, it will continue to see companies move to other metros.
In the US, salaries are different based on metro and state and are based on the market economy. Companies move to offices to particular metros if they is a healthy supply of workers and supply is greater than demand so that it is more cost effective. This location competition is healthy.
The role of any government, whether it is metro, state or country, is to create thriving economies so people want to move to that location. This means investing in critical mass in particular industries so many companies in that industry want to locate there. It also means ensuring other costs are low. In the US, health care insurance cost between $24k and $36k/year for anyone with a family. This is higher than the full salary in other countries. If the US does not figure out how to solve its health care costs, it will continue to see jobs leave for lower cost locations.
Supply and demand, yes, and when jobs are tied to locations the demand is concentrated. So supply needs to move to where the demand is, or face a lack of demand and lower prices. If the demand is willing to disregard geography, their supply will be that much greater.
With fully-remote working, the demand isn't as concentrated, so supply need not be as concentrated either.
As someone not currently living in the Bay Area, or London, or another tech hub, I'm quite happy not to be paying the cost of living there. And honestly I don't think it's fair that people who live there should be better compensated just because they decide to live somewhere expensive. But I understand why it happens, because when companies hire specifically in a tech hub there are lots of people willing to work with them but only if their pay is higher. It's a vicious circle for employers, a virtuous circle for employees, and only sustainable for as long as productivity remains above cost. It's not built on a stable economic foundation.
I don't want to accept lower pay for the same job, which may mean that I don't work for those companies. That's the market at work :). On the other hand, if a company wants to employ folk to be physically present in London, they're not going to want to employ me. While if a company is willing to pay the same to everyone, they'll get fewer people in London and more people outside London, and they might even be the same people just dropping their commute :).
There's enough global demand for Software Engineering to drag everyone up. It is universally the case that if you pay peanuts you'll get monkeys, but paying an equal wage for equal work benefits the company and wider society and I don't particularly care if that's lower than I might get if I was willing to work in London (or the Bay Area), so long as I'm not required to work in London (or the Bay Area).
Terrible managers are the bane of our industry. OTOH, many startups owe their existence to their founders having had to deal with terrible managers in their previous jobs. The story of the traitorous eight and Fairchild semiconductors comes to mind. In my own life, if it weren't for getting a non-technical but political and vindictive manager in my last job, I probably wouldn't have had the motivation to start my own startup. In hindsight, I wish I'd been assigned a manager as bad as the last one I had, earlier in my career. :)
I wish you could flag companies that have toxic management without compromising your privacy or getting outright censored. It would also be great to find companies that truly need your skills, so you can hop more easily without the HR overhead.
Microsoft has toxic management but it also has M1 who are just trying to navigate the maze and do the right thing. It is never straightforward like this.
Besides toxicity, i believe the main issue of some bad management is uselessness. Perhaps it leads to toxic situations, but the root cause is that they don’t add value to anything in the org.
It’s worse than not adding any value to the org. These people actively undermine value in the org by depleting their direct reports’ morale. OTOH, any organisation that tolerates and turns a blind eye towards such subterfuge, perhaps deserves it.
“People don’t leave bad companies, they leave bad managers”, an aphorism that ringers truer with every departure I observe.
(But I also see how the incentives of the org can erode at the energy put into cultivating management skills and prioritisation of effective management work.)
Ruby's entire programming model was based on the premise that language speed does not matter since most of the time you are waiting on IO / Network. Well now, both on Node.js and JVM we have programming models which say that - while I wait for IO / Network let me do some other work or service more requests (Async / Webflux / Coroutines).
IMHO - using Ruby/Rails in 2024 can be wasteful, but of-couse for the right situation it can be a good choice. (Just) For example an enterprise app where you know the number of users will be limited, or when you know the development speed is paramount or where you want to build a quick proptype to test the market out. Rails is a great framework and the productivity is unmatched, but with time a 2-3 years old Rails project is always tricky to maintain.
Ruby now has Fibers and other constructs for async like Ractor.
> Rails is a great framework and the productivity is unmatched, but with time a 2-3 years old Rails project is always tricky to maintain.
It isn’t any less tricky than a Django or Express project. With any codebase discipline and regular tending to the garden of code is important to prevent weeds from growing.
If anything that Ruby (and Rails) has going against it is still the raw language performance and higher memory requirements/usage than its counterparts, which makes it less desirable for workloads that require low latency or small memory footprint
I guess it depends on how one defines "productivity:" is it spitting out code as fast as your keyboard works, or is is not having features do weirdo things because who can reasonably say what the code does at any given time?
I have more than once tried to contribute fixes to GitLab's codebase, and every time I open the thing in RubyMine it hurpdurps having no earthly idea where symbols come from or what completions are legal in any given context. I trust JetBrains analysis deeply, so if they can't deduce what's going on, then it must take an impressive amount of glucose to memorize every single surface area one needs to implement a feature. That or, hear me out, maybe "it works on my machine" is a close to correct as the language is going to get without explicit type hints as a pseudo static typing
Bugs exist in all code written in all programming languages and you will find bugs in programs written in statically typed languages too as you know. Programming languages are rarely chosen for the absense of bugs alone though or we'd all be using SPARK Ada or something.
> spitting out code as fast as your keyboard works, or is is not having features do weirdo things
This is a straw man. No-one has suggested that "spitting out code as fast as your keyboard works" is what Rails allows you to do, or that Ruby code results in features that "do weirdo things".
In reality engineer productivity is important and Rails enables it in a web environment.
> I have more than once tried to contribute fixes to GitLab's codebase, and every time I open the thing in RubyMine it hurpdurps having no earthly idea where symbols come from or what completions are legal in any given context.
Yes, I prefer writing statically typed languages and I would /greatly/ prefer Ruby to be statically typed for a number of reasons, but it will likely never be so in a way I consider to be usable (see https://github.com/ruby/rbs). Not being able to definitively tell what a method returns or where one is defined is a total PITA, but it's one of the array of up and downsides to Ruby, with each language having a different set.
> I trust JetBrains analysis deeply, so if they can't deduce what's going on, then it must take an impressive amount of glucose to memorize every single surface area one needs to implement a feature.
You don't need to know how all of Rails works to write a Rails app, as I'm sure you know, so this seems like another mis-representation of the truth, just as you don't need to know how the compiler or CPUs work to do a lot of (most?) programming.
> That or, hear me out, maybe "it works on my machine" is a close to correct as the language is going to get without explicit type hints as a pseudo static typing
You seem to be suggesting that Ruby on Rails applications behave unpredictably on a machine to machine basis but that's not really how Ruby works in practice, or matching on my experience.
Meh, it's fine for 99% of use cases. Rails only becomes a pain in my experience if you have random, huge swings in traffic or a ton of active users with websocket stuff (mostly solved by anycable). But very few products are going to reach those limits and if they do those problems can be solved too.
Stripe, GitHub, and Shopify are the shining examples of Rails scaling in all kinds of ways without problem.
Not sure how long you were there nor which team you were on, but as someone who's still working on Shopify infra after a decade, I disagree with you.
Scaling problems at Shopify are rarely if ever directly Rails related.
The biggest challenge was always scaling the database layer, and to some extend the deploy pipeline of the monolith given the amount of people working on it.
Perhaps we can debate whether this is really a Rails-specific problem per se, but we definitely had lots of problems scaling to prevent long-running IO from saturating web/job worker pools for things like taxes, shipping rates, syncing external inventory, ad syndication, etc -- anything where we had to make multiple network calls to the outside world from a Rails thread was a big pain.
Stripe doesn't use Rails. Stripe's application of Ruby is far removed from your typical Rails app. A lot of custom stuff was built into Ruby to make the multi-million line codebase work as well as it does.
I believe Github still use Rails for their main application. Spinning services out into microservices, even ones that are other languages, isn't really a sign that Rails isn't working for them, it's just what happens when companies scale. The company I work for is a Rails backend (React frontend) and we have some services split out into Go based microservices (eg. Twilio webhook handling has been offloaded to Go in Lambda), but it's still very much a Rails app.
> Even their frontend I think is now just react
It remains to be seen how successful this is and what the reasons were for the change. Personally I don't like it, it's less reliable and slower than before.
> Ruby's entire programming model was based on the premise that language speed does not matter since most of the time you are waiting on IO / Network.
Couple of points. 1) You probably mean Ruby on Rails and not Ruby and 2) that's not true of either. Ruby or Rails "entire programming model" was not based on thoughts around I/O at all, a huge about of the driving force behind Rails was DHHs ideas about developer happiness, which is intrinsically linked with speed of development.
Discussions about I/O /do/ happen in the Rails community because it's important when you're running a web server which is a lot of the use Ruby/Rails is involved in, but it's not the sole (or even a major) focus of the decisions made for the language or framework.
> Well now, both on Node.js and JVM we have programming models which say that - while I wait for IO / Network let me do some other work or service more requests (Async / Webflux / Coroutines).
Right, but if the goal is to maximise CPU usage of your web servers then you can completely do that using Rails, and have historically been able to do so by spinning up multiple processes in the same way you'd spin up multiple threads in, say, the JVM. Not as convenient perhaps, but a model that's been in use since at least the 90s when I started out. Luckily it turns out that web requests can generally be run in isolation so IPC isn't usually an issue (the same reason why multiple physical web servers is simple, just as multiple processes is).
> IMHO - using Ruby/Rails in 2024 can be wasteful, but of-couse for the right situation it can be a good choice. (Just) For example an enterprise app where you know the number of users will be limited, or when you know the development speed is paramount or where you want to build a quick proptype to test the market out. Rails is a great framework and the productivity is unmatched, but with time a 2-3 years old Rails project is always tricky to maintain.
Wasteful as a generalisation is blunt. Of course it can be wasteful, but so can writing your app in rust, it just depends where the pressures are. I'd suggest that not launching is a far bigger concern to most people at an early stage, and even mid to late stages developer speed is one of the most difficult things to scale.
Personally I'm the CTO of a company that uses Rails (backend, React frontend) and developer speed is /hugely/ important to us. We're always constrained by engineering resources and the speed of Rails development continues to be a huge win for us. We do have scaling issues, but 99% of the time they're not Rails issues, they're in the database.
Companies attempting to pay an engineer according to location, in my opinion, is another kind of discrimination. You are supposed to pay an employee based on his/her abilities, not her location.
We have rules in govts that companies should not discriminate against employees based on sex, religion, sexual orientation etc etc.. But it is fair to discriminate the salary of an employee based on location? For ex: I know a few friends who have moved from Europe to Asia with the same role and are getting paid less compared to what they were getting paid in Europe. Its the same role, its the same person, but getting paid less just because of location ?
> You are supposed to pay an employee based on his/her abilities, not her location.
You are supposed to pay them the minimum amount it takes to get them to show up to work. When someone moves to a less competitive market, where getting another job is harder, then they are more likely to show up for lesser pay.
And remember that a country may have a less competitive market, even if the workers are remote and not seemly bound by a local market, because governments often love to put up huge roadblocks when it comes to international hiring. If you are being paid less than you were in another country doing the same job for the same employer, this is almost certainly why you have agreed to take a pay cut.
That’s up to them. It’s the worker who chooses how much it takes to show up. I suppose if they want to truly play the part of being female they may want to accept less.
I disagree. I believe a company should pay based on ability of employees to have comfort and wellness, not some universal measure of value (which I believe to be impossible). What you are advocating for inadvertently breaks community and exacerbates gentrification and destruction of social fabric via inequality. Location matters.
You could also argue that difference in pay is less discriminatory. You are paying employees to have the same quality of life, same type of housing, same opportunity to provide for family, send your kids to the same type of schooling. These things cost differently in different countries, so require different income.
Exactly this! Location-based pay is not so much about cost of living as it is about buying power. In the end, money is just a place holder for real value which comes in the form of goods and services. And the real value of the same amount of dollars wildly differs per location. So if you want to pay fairly and not discriminate, you have to try and make sure people can roughly buy the same things in their differing locations for the money you give them.
While I'm sure it's very kind of companies to care about my quality of life and the type of my housing, it's honestly none of their business. Even if they tell me I'm "family."
Fair pay to me, at least, means paying for results. Not paying for hours spent toiling. Not paying for where I am on the planet. Not paying for how I get the results, just for the results.
Instead, there are all of these gamey factors inserted into the mix. They're emotional. They're manipulative. Yuck!
That’s not how free markets/capitalism is supposed to work. Companies are expected to just shop around for the lowest price on the capabilities they need. Are you suggesting we should adopt something else then capitalism/free markets?
Why are you supposed to pay based on abilities? Where is that stated?
As a company you need certain abilities, and you pay whatever the market decides these abilities are worth, and nothing more. Depending on location, the market will set a different price on these abilities, so you pay different.
Discrimination is around things that an individual can't choose (religion being the weird elephant in the room). Fair or not, this isn't discrimination.
In the UK, the Equality Act (2010) protects: age, disability, gender reassignment, marriage or civil partnership (in employment only), pregnancy and maternity, race, religion or belief, sex, sexual orientation.
Pregnancy, maternity, marriage, civil partnerships and gender re-assignment are usually chosen by individuals, not forced upon them.
Many people can’t choose where they live either. Getting a visa to the US is a ludicrous process and even if they wanted to they maybe tied by family obligations.
But people don't choose to be rich or poor exactly either. As a general rule, discrimination is around things for which there's no choice. Having a choice over where they live or whether they are rich doesn't mean it's easy or practical. But that can't make it grounds for discrimination, even if unfair.
A worker in country X or country Y are very different for companies' balance sheets. For instance, my company is Canadian, and we are eligible for significant tax credits through SR&ED[0] for software developers. If a software developer moved their permanent residence to outside Canada, even if we could magically pin exchange rates to pay them the CAD equivalent in local currency, it would be a significantly different financial impact on the company as they aren't eligible for that program. I'm not an expert, but I imagine there are many equivalent programs in every country, state, and even municipality.
It works both ways, anyway. If those friends had moved from Thailand to Switzerland, would it be discrimination to pay them more?
I agree with this in theory but I can't see how it will work in practice. There isn't a global "value of ability" to base the pay on. It's valued differently in every location.
> You are supposed to pay an employee based on his/her abilities, not her location.
I don't believe that is a legal requirement, anywhere. Remuneration is based on many factors, which can include the cost of living. A company will not be able to hire someone in New York City, for the same price as someone in a less expensive jurisdiction.
This isn't discrimination, it's simple economic reality.
> Companies attempting to pay an engineer according to location, in my opinion, is another kind of discrimination. You are supposed to pay an employee based on his/her abilities, not her location.
So you’re saying, we should be paying engineers in Europe and in the US the same as an engineer in LATAM or India or Asia that has the same level of experience and skill.
The only way to be non discriminatory is to have a standardized formula of compensation that takes into account cost of living (rent, food, healthcare, taxes etc) where the final take home pay in locations around the world are equivalent - which I believe should be the case at most companies
> You are supposed to pay an employee based on his/her abilities, not her location.
I don't think this make any sense on so many levels. First, "abilities" are not a good way to think about wages. If you hire a neurosurgeon to do your gardening, you won't pay them more than a run of the mill gardener.
Rather, you as the employer compete against other employers on different markets in a fairly classical supply and demand situation. The "abilities" of an compliance expert with tech skills did not change much when GDPR was introduced, but as all EU companies scrambled to figure out the regulation (and the DPO role was popularised by fiat), the compensation went way up.
If the employee can participate in e.g the SF labour market, you have to pay a competitive salary in that market, if not you don't have to. As long as there are barriers, e.g a on-location worker in SF has more opportunities for whatever reason, the location premium makes sense.
To take your example in the opposite direction. Let's say a east-european company want to expand into the US and open up a sales engineering office in SF, and want their best sales engineers to go work their, it would be completely insane to not raise their wage. "We pay people after ability here you have 40k USD, have fun finding housing".
Yeah I absolutely hate that. I get why they do it from a business point of view but as an engineer, I'm instantly put off when I see something along the lines of "up to $x (depending on location)".
> A mistake GitLab made, and continued to make when I left, was not caring enough about scalability. Yes, directors would say it was important and improvements were certainly made, but it was never as much of a priority as other goals. At the heart of this problem lies the way GitLab makes money: it primarily earns money from customers self-hosting GitLab Enterprise Edition, not GitLab.com. In fact, GitLab.com always cost much more money than it brought in.
Is that really a mistake, then? As a first approximation, company has to invest in the thing which makes money, not the thing which loses money. Now, higher-order thinking might suggest that a more-performant gitlab.com might bring in more customers, build a stronger reputation and so forth. Still, if the company’s real business is selling self-hosted software, it makes sense to focus development resources on self-hosted software.
If Gitlab.com is a money losing product why is it the same price as the self-hosted option.
I literally bought licenses from gitlab before realising that the seat cost is the same if I let them host it or we do it. So why take the infrastructure cost?
But to be honest I do see the point of the author. Either stop "half-assing" GitLab.com or remove the product (GitLab.com) entirely (and focus only on self-hosting customers (GitLab Enterprise Edition)) might be a better decision in the long run.
But I am sure no one on management level wants to do this decision. So you half-ass a product.
This kind of situation can be frustrating for people working on the product itself (at least when they care). And each new developer that joins the product will probably suggest: "Oh we should care more about scalability." And each senior will be: "yeah yeah, i know..."
Gitlab.com is a marketing instrument and if you 'remove the product entirely' then the enterprise edition will sell only a small fraction of what it sells today.
That I agree with. There are some weird incentives at work though: a commercial user of Gitlab.com might see their frustration with Gitlab.com as the reason to go for an enterprise license rather than to switch to the competition.
Is it a defective product, or is it a fully-featured demo that is just good enough to show companies what they could have if they host the software themselves? "You get all these features, plus all the speed and security that comes with running this in your own corporate environment"
Why buy the cow when you can get the milk for free?
I’d guess because many IT departments figure that on-premise=secure and provides them the illusion that they can prevent source code from leaking this way.
Economically, if the Amsterdam developer is providing the same value as the bay area developer - you should probably pay the them the same. While it's true that the local market for Amsterdam developers is set lower, you're building a global company and competing with other global companies. Sure you can get a discount now on Amsterdam developers but eventually a competitor will offer them something closer to their value or they will leave to do their own thing.
I think we'll see the strongest companies pay location-agnostic prices for talent. Ultimately, it's about value delivered. If I'm Gitlab with a likely large encumbered ruby codebase and I want to sell to large enterprises that care about performance and reliability, I'm probably gonna pay this person more than 120k EUR a year. Most engineers who care about performance, type-safety, and reliability have no interest in Ruby so the market rate of that skillset is definitely higher. Is it bay-area 500k/year high? I dunno, but I imagine that the strongest companies who want top-talent will probably need to tie their comp to value delivered rather than location or they'll lose their talent to the companies that do.
If you pay people according to value you get happy value-generating employees. If you pay people the minimum of what you can get them for- you get the minimum - unhappy, less productive employees that eventually leave your company.
There is no free lunch. Just because they aren't the type of person to get counteroffers or move to the bay area doesn't mean they don't recognize their value or won't feel taken advantage of.
> The time it takes to deploy code is vital to the success of an organization
I've found this to be one of the most important metrics (if not the most important) for maintaining developer velocity as a startup scales.
Context switching is one of the most expensive operations in a developer's day-to-day work, and also one of the most ignored.
Managers love to build team schedules around their personal schedules, but this is often disruptive to ICs' "maker schedules."
Many orgs identify this and focus on the scheduling cost w.r.t. context switching, but the build-to-deploy time is equally (if not more) important for developer ICs.
> In practice this lead to GitLab building many features over the years that just weren't useful: a serverless platform nobody asked for and that was ultimately killed off, support for managing Kubernetes clusters that didn't work for three weeks without anybody noticing, a chatops solution we had to build on top of our CI offering (thus introducing significant latency) instead of using existing solutions, or a requirements management feature that only supported creating and viewing data (not even updating or deleting); these are just a few examples from recent years.
If my company ever grows to be as successful as Gitlab, I’m going to much more worried about innovation grinding to a halt than about people trying stuff that doesn’t work, or trying stuff the wrong way. It’s so much easier to shoot an idea down than to believe in it long enough for it to have a chance. I strongly agree with the author about making engineers be the decision makers on how to build out an engineering product, but I’m not convinced that this list of failed ideas is a bad sign at all.
This part of the article resonated with me, as I used to work as a tech lead for a very similar startup to Gitlab. We were always pushed to "ship MVP's" and "move fast and break things" by product and design, which always resulted in a half-broken features getting pushed to production and left there once the sprint was over. This also led to a constant inexorable growth of tech debt, that made me feel like we'd never be able to get things remotely stable in our corner of the product. I've since come to the conclusion that it's much better to build small, flexible, feature-complete systems that can be used for multiple iterations of ideas.
It's a matter of focus: Having some time to tinker and try out stuff that might just fail is great. If it consumes so much development time that the must-haves deteoriate, you let down your customers.
I think it's less innovation and more failing to understand the requirements (i.e. only implementing half of what's needed, and then moving to the next thing). E.g. adding labels to gmail, but no way to have filters, so you have to manually apply them.
I moved from using bitbucket, first own servers and later SaaS to gitlab.com SaaS in early 2018.
I cannot say anything else than gitlab performance and UI being much better. I was permanently complaining about bitbucket, but very happy with gitlab most of the time. They had rather frequent partial outages, but resolution was always quick.
Maybe starting 1 year ago I noticed gitlab.com reponse times going down. It's not that things hang or are super slow, but they seem to consistently take 2 seconds more than what they used to. (The number is a complete guess, I have no measurements either before or after.) It's still usable, but no longer the pleasant experience it used to be.
Being able to work from where I happen to live and I have thought about whether I would like to work for them.
That it's a good product would certainly be a motivation. However, frequent incidents being resolved fast must be incredibly stressful for the staff. I prefer to stay where we make heavy releases only a few times a year for regulatory reasons. (Even though stress levels can raise until the last MR for the release has been merged.)
The article is nice and well articulated, but I'd argue exactly the opposite on this point. The author seems to confuse equality and equity. He takes the Netherlands and Bay Area as an example and don't make a compelling argument as to how and why paying differently those employees is akin to discrimination based on race.
Were you to pay the same salary in Netherlands and Bay Area, you would effectively either (i) pay absurdly high salaries to your dutch engineers, similar to what the prime minister earns or (ii) pay absurdly low salaries to your Bay Area engineers (to the point that you'd basically have none of them).
Location-based pay means the company pays more for areas where the supply is priced higher. It's not about cost of living, because the company won't pay me more if I prefer a Ferrari over a Fiat.
Location-based pay pays people more if they're in a market where they have other options, so they don't go to those other options.
In essence, if you have location-based pay, you're incentivizing your employees to move to an area where they'll have vastly more employment options than to stay with you.
The Dutch Prime Minister gets paid €186k annually [0]. He has 13 years of tenure in this role and 22 years total in the politics industry [1].
I'd hope a high performing, vastly experienced engineer in NL could aspire to that, though they might not get the same benefits or future opportunities.
A prime minister usually has quite good offers after the political career. Rutte has been trying to get the leader role for NATO, for example, which is probably a step up in salary (?)
It's fairly universal that politicians are underpaid relative to the level of responsibility they hold.
I'd quite like my country (UK) to be run by folk who are competent, rather than by only those who can afford to run for office without being paid for it. Yes, MPs get a lot more than the median income. But many people who are well-qualified to be MPs are also well-qualified to hold roles that pay at least as well if not more, and without needing to run for election to get the job.
Taking the CoL in NL, particularly the Randstad area, that salary is not outrageous. Especially, if you're a new expat on a single income, without any social net, and with any hopes of owning property, within a reasonable commute distance from your work.
Who cares if you don't have Bay Area engineers? Their ability isn't based on where they live, is it? If they want to lower their costs of living so they can compete they can "just move".
The world is moving towards more closed borders, so moving is getting harder. But in the end we’ll all need to move to low-income countries like Yemen, Togo, and Ethiopia, to lower our costs, and be most competitive for employers?
Define best engineers first. I seriously doubt that hiring in SF will give you the best engineers, it might have one of the best ratios of good:bad engineers compared to many other places but it's not a given whatsoever that hiring one living in SF will be a slum dunk. I worked with many terrible engineers from SF over the past 20 years.
Which makes the point: why would a company pay such a premium on hiring from a single location if, in the end, it can only get the best engineers from there if it pays an even higher premium than the ridiculous salaries from the place? It doesn't make much financial sense, seems to be mostly based on "feelings" during hiring, like yours.
> seems to be mostly based on "feelings" during hiring
Silicon Valley has a local bubble economy. If overpaid engineers spend their money for overpriced health insurance, rent, mortgage or juiceros the boat stays afloat.
But if the SV companies start sending money abroad the bubble would deflate...
Also buying power is just not the same based on your location. A hundred dollars in the US and in the Netherlands will literally not buy the same things.
Bottom line you want the best people, which are spread around the globe, but within each country is a different price point for what you pay the best people. Bidding too high is wasteful to your resources, too low makes it impossible to compete in higher pay areas, and middle ground is the worst of both worlds: loose out on high pay areas, be wasteful in low pay areas.
I hope future generations will better understand that accumulating wealth should not be the goal of life.
Maybe future generations will not have to worry as much about accumulating wealth when countries work harder to ensure a high quality of life in the middle class. I doubt that will happen for the west until they figure out how to relieve all the pressure the housing market is putting on their citizens.
Lots to disagree about here, but I'd prefer to treat the moral of this story as, not all the same people will thrive in a small company after it's hit a growth inflection point. This is okay! Without some of those folks who are willing to go broad and wear a lot of hats, companies can't get to where they need to be to start growing in the first place.
The responsibility of leadership and managers in this situation involves creating venues where early, impactful employees can be adequately rewarded without becoming impediments to their personal growth or the growth trajectory of the company. Imagine how much less burnout the author would have felt if the stock situation didn't keep him locked into the company far beyond when he didn't feel welcome.
I've worked at enough places where early contributors white-knuckled their way through changing values until the first possible liquidity event, or just left a big financial upside on the table because they couldn't make the numbers and their sanity work at the same time. These "growing pains" result in burnout, poor quality and communication from individuals we've previously trusted as veterans, and a tumultuous culture with conflict between the old guard and new layers of management.
I believe we can minimize the friction on both sides by significantly increasing the exercise period for stock options, prioritizing hiring growth in duplicative roles for individuals showing early signs of culture clash and disengagement, and empathetic coaching that names the problem (terminal burnout) and includes resources for teams or companies that better fit that person's disposition.
> This then lead to the discovery that we didn't have any backups as a result of the system not working for a long time, as well as the system meant to notify us of any backup errors not working either.
Reminder that validating backups for critical systems is everyones[1] job in organizations where there’s not a literal backup team working on it full time.
This is probably one of the worst experiences a developer or sysadmin can have, but in no situation can it just be one persons fault.
If multiple lines of defense have failed (backup validation, monitoring etc.) and nobody noticed, it’s simply a question of when.
[1]: all technical personnel that can be remotely considered stakeholders in the backups not failing
I noticed that we weren't validating backups at a company I used to work at so I did a /really/ simple hack where I checked that the backups were within a certain number of bytes in size of the previous dump.
Literally a couple of weeks later after putting this live (I think it was a Nagios check) it alerted that the backups had gone down from many 10s of GB to a few k in size. I can't remember what had gone wrong now, it was years ago, but we /did/ catch the issue.
Obviously this isn't a comprehensive check, I later wrote a tool that pulled backups down, restored them, and did some sanity checks on the data, but the quick hack worked as an interim.
I really enjoy RDS for not having to worry about this. Point-in-time rollbacks for the past 24 hours, and if we accidentally drop the whole database we can restore it from the periodical snapshots.
For one of my team's services, we don't just back up the data: we then also restore it into a parallel environment. If the backup fails, the restore fails, and then the environment fails, and while our monitoring might miss some instances of spurious success, it's less likely that the whole chain will look like it's working if the actual backup is not actually working.
About two months ago, I was commenting on my struggles working at a place that offered cloud and self-hosted solutions where it was not going well. I was mostly convinced that the problem was organizational, but thinking more about it, it’s more complicated than that.
To be clear, I don’t think it’s impossible to do both. If your application is very simple and self contained, then of course; we use such services every day in a variety of environments. However, you have to design the software from the ground up for simplicity, and to carefully dogfood your self-hosted experience via your cloud offering to ensure both models are aligned. And of course, complex system architecture is a significant obstacle; assuming your customers are going to wrangle dozens of microservices, multiple database and distributed caches, etc. is not reasonable for most organizations.
So, if you strictly and carefully design your product to be self-hosted-first, I think these two models can coexist… up to a point. If you’re fortunate enough that your cloud offering becomes huge, you might reach a point where the simplicity of self-hosted-first becomes a restriction that turns into a liability. At that point, you can simply make a decision: who butters your bread? That sucks for your customers who lose in that decision.
If I select self hosted, it’s often because I am concerned about lack of agency, control, and partitioning, or I need to flatten my costs, or I have an external requirement that is incompatible with the cloud offering. Is it not a risk, then, to hitch my wagon to a company that offers both, and at some point may make a decision to rescind or water down their self-hosted solution? If it’s closed-source or open-core, then I would say so. From that perspective, I think it would be better to go with a vendor that just picks a lane, and avoid those that use watered down self-hosted to funnel customers into more expensive cloud offerings (in other words, open-core model is a big red flag for me). I suppose this is maybe getting into whether you should rely on proprietary software whatsoever for vital parts of your business, but let’s not get into that. Like I said, I think the question is complicated.
I read this meme so often on HN, so I genuinely want to know: how do you organize work and get people to act on a common vision if there are no managers?
I think people mistake “manager” as being people without tech skills. I think a tech company should have managers to create alignment and those managers should spend part of their time “managing” and part of their time still honing their tech skills.
In my experience, people will use "managers" as a proxy for complaining about all the other things they don't like.
Of course clueless managers and extreme bureaucracy will destroy a company, but I very often see engineers that just want to do X and ignore everything around it as if they were working in a isolated environment. It's often the managers calling these engineers back to reality, which creates tension.
The issue is you literally cannot be an engineer if you don't know how to build things.
On the other hand, there are plenty of managers that do not know how to manage people, that do not even know what is expected of them. Should they optimize for cost? For productivity? For employee happiness?
Competent managers are a minority. They tend to rise quickly, leaving the inept ones to run the day-to-day.
My guess for a reason would be that developers rarely care for business results. The technical challenge of scalability looks more like fun than fixing yet another enterprise permission issue.
I recently spent a few minutes applying to a Gitlab position, only to get a link to some Gitlab wiki explaining the list of EU countries they hire at is limited, and mine isn't among them. I wish whoever posted the ad had spent a few seconds copying and pasting that list from their wiki.
> No matter how you try to spin this, it's by all accounts an act of discrimination to pay one person less than another purely based on where they live. Think about it: if a company pays a person less because of the color of their skin or their gender, the company would be in big trouble. But somehow it's OK to pay a person less based on their location?
Yes, yes it absolutely is. My favorite example is a train conductor in the deepest netherworld of Saxony and a train conductor in Munich.
Both perform the absolutely same work, both in complexity and time, and yet with the usual "everyone gets paid the same" collective agreement, either the train conductor in Munich can't even rent a 1br apartment, or the train conductor in Munich barely scrapes by while his colleague in Saxony lives in a mansion.
Wage schedules in any multihomed organization have to be CoL based, there's no way around that.
ok lets look at it. Start with the absolute best case for sharding - a perfectly segregated data model, say either by user or customer id. No shared data, no joins between tenents. Some relatively straightforward framework code to redirect queries between N shards. cool. Operationally now you need N database clusters (at least a primary and a replica per cluster). You need to manage and monitor all those, figure cluster local and shard promotion schemes, figure shard based backups and restores. Probably figure out shard rebalancing. None of it rocket science, but a lot to get right, test and maintain.
Now do all that operational stuff in a way that works with on prem installs (gitlabs primary customer type).
And then add in the fact that practically noones data model is that cleanly shardable, so add support for cross shard joins, and global tables.
Its pretty easy to see how a couple of read replicas (that are near zero cost operationally if you're using a cloud db) are a VASTLY simpler solution.
I can truly relate to poor management. I'm unsure though if the author is referring at times to poor engineering/HR managers, or poor product managers. At my company they call the latter Product Owners but it's the same thing I believe. I deal so often with both being terrible. I've had terrible Engineering Managers, who simply don't understand the tech, and in the worst case they think they do but don't. Add in some office politics and they can make life truly unbearable. Same for Product Managers but it's a whole other array of chaos. I've had a tough time with poor managers, and so I can really relate to that aspect of this.
What I wonder though reading between the lines is if Gitlab has reached a point where they suffer from poor Product Managers/Product Owners. I see that in later stage startups and especially large orgs. One would hope Gitlab, by nature of its product space, would never suffer from that, so if they are that's disheartening. I'm unsure what at this point would really differentiate Gitlab from Github unless it's devex, and to have good devex they'd need engineering centric product vision, I hope Gitlab is not losing that by hiring an army of "Business Analysts" or MBA's. On the positive, in some respects I like hearing that HN comments drive the vision at Gitlab :)
I've seen some recent data on the salaries they're offering in my area. I like Gitlab but wouldn't be prepared to make those kinds of sacrifices to apply there.
>In spite of all this, I'm not sure what alternative I would recommend instead of the combination of Ruby and Ruby on Rails. Languages such as Go, Rust or Node.js might be more efficient than Ruby, but none have a framework as capable as Ruby on Rails.
Go would be a sensible choice.
Both .NET and Java have very good frameworks and are good choices for large scale development.
Rails is nice for small to medium websites, but for large microservice based apps will present some issues.
My conclusion after reading this is never give it your all unless it's your own company. Burnout after working for someone else in tech should not happen at all. The post overall has negative undertones so it feels like the burnout was really bad after all this time, I hope the author recovers and finds joy and peace working on their own projects.
> never give it your all unless it's your own company
It’s the classic “last founder or first employee” problem. If you are an employee at a startup, have no illusions: if “they”[1] don’t give a shit about you now, you can be sure “they” will not give a shit about you later.
[1]: the company is and always be an inanimate and abstract object, your boss and colleagues will change
It's important to know what 'your all' is for the company. I learned early on that working more than 40 hours a week writing code results in my introducing bugs into the code base. So doing more is counter productive.
Choosing to not care is much harder as we have all had years of education conditioning us that we need to achieve more and to be the best.
> Choosing to not care is much harder as we have all had years of education conditioning us that we need to achieve more and to be the best.
Very much so. I enjoyed reading Coddling of the American Mind as well. Not 1:1 but related to the conditioning, lack of maturity, and in some cases, learned helplessness.
Also, from my understanding, the burnout did not seem to stem from the actual work but more from interpersonal relations and disagreements. I am certain that is not uncommon
This is what burnout is. Burnout is not caused by working, but by stress. The root cause of this stress is personal and interpersonal factors. People can burn out on very small workloads if the ratio of interpersonal toxicity to hours of work is high enough.
Sometimes it looks like people are burning out because of extreme workloads. In these situations, I've always asked "why is the workload so extreme to begin with?" This gets you to the real source of stress.
It's amazing how many issues in life are caused by the act of thinking of these possible issues, than the issues themselves. My friend had horrible issues sleeping, he tried many things before going to psychiatrist. The conclusion was quick and accurate - your issues sleeping are caused by your fear of not falling asleep, basically anxiety. Anti-anxiety meds fixed it immediately.
Wu Tang has the best lines to describe corporate workers:
“You're just worms in the worst part of the apple that's rotten
You squirm and you turn from the right, still plottin
All slimy cause you stay grimy, petty crimey”
While some have no alternative others enjoy that kind of game and are part of the problem. Best stay away from such jobs, and undermine corporate at every turn.
Do just enough day to day. Show heroic effort here and there. Don't get too attached to your project, service, code etc. Always understand the undercurrents so that you can keep abreast of things.
Yes. To add, always try to escape, have a side project, dabble in opensource, wake up early and use your best brain capacity for that then go to work. I know it's hard but if you're just what you do at work then future employment prospects are lower than otherwise.
Exactly, every company and org has a meta that you need to understand. If you understand the meta and you can/want to play the game, then play else start searching.
> This then lead to the discovery that we didn't have any backups as a result of the system not working for a long time, as well as the system meant to notify us of any backup errors not working either.
This seems to be entirely normal for startups. I've asked about it during interviews.
Do these startups consciously decide not to have backups (for time/money reasons perhaps)? It makes no sense to me.
I've worked at some startups and most senior engineers know what's necessary to keep production systems running reliably. That includes monitoring and backups.
Could it be that this is entirely normal for startup with less experienced engineers doing things for the first time?
> I think the idea of product managers needs to go in favour of giving team leads more power and having them interact more with users. To me, that's ultimately what a "product manager" should do: help build the product at a technical level, but also act as a liaison between the team and its users.
Yes! In my experience product managers bring very little to the table, and the most enlightening discussions I have are when I'm allowed to talk directly to customers. Very often I find out about pain points with software (often ones which are easily and quickly fixed) by talking to customers, which I'd never heard of before through product management.
Story of bad management aside, this was also a highlight for me on the risks of early stage startup even when the startup goes big
> In my case the amount of taxes would be so high I wouldn't be able to afford it, forcing me to wait until GitLab went public
I have seen a bunch of cases where people really want to leave the company but can't due to short exercise windows and taxes that come along with exercise.
One of the companies I know had to partner with a lender just so that their employees could exercise stocks. So now if the company IPOs you owe the lender a load compounding at 15%
Thankfully many newer companies seem to be going towards 10 year exercise windows, but they are still a minority
> Thankfully many newer companies seem to be going towards 10 year exercise windows, but they are still a minority
I'm actually a bit on the fence for the 10 year exercise window, as I'm not sure it's always a benefit. As I understand it, startup exits timelines are on an upward trend, so in 10 years will the average exit still be below 10 years, and even then are you working for a company that meets the average timeline. Then, from a taxation perspective, if you do want to exercise before the 10 year expiry, if it's cost prohibitive now, it should be bankrupting after a few more investment rounds and increases to the 409A valuation.
So I'm curious if there is a side effect here that the 10 year exercise window actually leads to many more shares becoming even more cost prohibitive to exercise right before the company reaches a liquidity event and as such not exercised (if you're in the early stage employee group).
Yeah, you are right on the point that if you are not able to exercise now you might not be able exercise later also. It's still lesser of the 2 evils imo because:
1/ many companies have liquidity events as they mature. So you may not have to wait for IPO/exit
2/ In 10 years you often know if the companies gonna go anywhere. So if you feel the company's ngmi, might as well not exercise.
I have also heard some companies fixing their exercise price (as in its not tied to 409A) to $1 or some small value like this. That seems like the best option
While I understand the feeling, I would be pressed to say that this is purely driven by market dynamics. Companies that hire in a certain market have no incentive to overpay compared to the local market rates.
Software engineering has now become commoditised. This holds true for remote companies. Wages are a function of local supply/demand and labour costs in that location.
If you want to follow the same logic, you would expect to pay a coffee $10 in Brazil as you would pay in NYC. Following the same logic a coffee shop in Rio de Janeiro would say “location based pricing is discriminatory”.
This one seems to be contentious in the comments section but I've had issues with this before. At the end of the day it's a balance between accepting that reality involves a lot of factors that result in a Canadian coworker making half the pay of their U.S. colleagues, and chafing at the injustice of the same fact.
I've not been able to be reasonable about this issue. If corp A pays me X and pays somebody else 2*X, I will always, always have a discomfort around this setup (even if X is still great).
Totally agree. Overall the author's arguments against sharding seem short-sighted, at best.
All large successful user-generated content applications eventually need to shard, and most of them are read-heavy just like gitlab.com. The two primary motivators for sharding in this case are database size and blast radius, rather than needing to scale writes.
For database size, even if your DB still can fit on one beefy server, operational activities like backup/restore and new replica cloning take an increasingly long time. This in turn becomes a major risk to the business -- for example he even discusses how long the restore took when he had to restore the prod DB from the staging DB.
For blast radius, it's the ability to have outages (e.g. hardware failure) only affect a small subset of users. Or for a more extreme situation, the massive difference between "I accidentally dropped the database" and "I accidentally dropped a database".
Sharding does indeed add terrible complexity to the application as well as operations. But in any case, eventually the data size motivator becomes unavoidable for user generated content: you eventually must shard, and the longer you wait, the more difficult it will become.
Remember most of the business is on prem installs . Introducing the huge complexity of sharding to the codebase would have benefited these installs approximately zero.
The existence and uptime of gitlab.com is essential to the company's customer acquisition. If gitlab.com goes offline for an extended period of time (due to database size issues or anything else), it's a huge hit to the reputation of their brand. This will directly affect their bottom line even if it isn't the main direct source of their revenue.
And again, what's the alternative? If you offer a successful user-generated content platform, eventually you must shard. User-generated content only grows over time, it never shrinks, and at some point you exceed the maximum amount of storage that can be attached to a single server. And long before that point, you encounter horrendous operational headaches, such as full backups taking longer than 24 hours to make (let alone restore from).
It's also conceivably possible that their largest on-prem customers would be interested in sharding their self-hosted installations, so theoretically this could be a valuable high-cost enterprise feature.
I somewhat agree with what you're saying, but it still really depends. On growth rate in users and content, access patterns, UGC incremental size etc. Machines keep getting bigger, if your growth rate is low/moderate you might never reach storage limits. Or might theoretically reach them in 5+ years in which case many other things could change before then, in tech or the business. The alternative (to expensive front loaded investment in sharding) is just not doing it, until you have to, because its likely you might never actually have to.
Of course if you're growing like a popular B2C ala early facebook or whatever, yes you have to, asap, otherwise you'll die. That probably isnt the case for companies like gitlab.
Do your realistic growth projections, and your cost/benefit analysis, and pick the cheapest thing you can get away with.
Sure, I'm not advocating premature optimization here. Don't shard unless it's clear that you eventually need to. But we're talking about a specific company here, not sharding in general.
I believe in GitLab's case that they absolutely will need to shard eventually. This is a decade-old company with a $12 billion market cap, not some early seed-stage venture with unproven success. And they're absolutely growing faster than hardware storage capacity limits are increasing.
Even aside from data size motivations, they've clearly already had blast-radius problems from using a single monolithic production database.
It's not like sharding is some major unsolvable problem in 2024. It was a lot harder 10-15+ years ago, when engineers with sharding experience were extremely difficult to find, frameworks didn't support it at all, premade solutions didn't exist, etc. But even then it was absolutely solvable, I can say from first-hand experience, even with much smaller teams than what GitLab can afford to throw at this.
Every time we'd look into this, we'd look into the challenges we'd have to face and see if they changed since last time. One of the problems GitLab faces is that it JOINs all over the place. In addition, while most data can be shared on a group/namespace basis, GitLab also does a bunch of cross-group queries in frequently accessed pages.
To put it differently, try to think of an application that does all the things you _don't_ want to be doing if you're going to (or want to) shard. Then imagine that that's basically GitLab, coupled with the load patterns simply not justifying it.
Read replicas are better suited for this situation and way less complicated. And you said it yourself: you need to be careful and you loose the ability to do joins.
How is that true? If a company pays $30k monthly in Bay Area and $10k in Netherlands, what should the unique, non discriminatory wage should be? $30k or $10k?
Some people believe that every employee's productivity and contribution to value can be precisely quantified, and fairly split between employer and employee.
I've always been sceptical of this myself - how do you value that code review where I stopped a junior engineer's XSS getting into production? Incredible value? Or 10 minutes of work?
Always wondered that. It means everyone's salary is determined by the highest-cost of living area you want to hire from. Doesn't really make any sense seen that way.
Probably the company grew, and standards grew as well. It is difficult to do layoffs / fire people based on perf in Netherlands, so it seems that's why it was only hinted for the person to leave.
I am with the company on this one. Business is business, and it's both manager's and employee's responsibility to grow and keep up with the demands. Learn from errors and move on.
This is an interesting read and I am grateful for the author sharing their experience.
One thing that I could pick up is that the author is somewhat bitter about their experience, but isn't really taking responsibility for their own contribution to getting into the situation.
At most companies that are not evil and not exceptionally dysfunctional (and I presume GitLab is neither) getting to a state where one is put on a PEP/PIP is preceded by a longer period where they had indications that they are not performing in accordance with what is expected of them. Also, at most larger companies consistently "meeting expectations" is not hard, if you're in a role you're skilled for (which it sounds like the author was) and willing to receive the explicit and implicit signals from your environment, especially the hierarchy above you, and adjust.
Being able to make these adjustments and work effectively as part of a complex environment is an important part of working at a larger company. Not taking responsibility for the need to learn how this system works and adjust accordingly is counter-productive. It sounds like the author realised that rather late. Perhaps they could have had a better experience if they figured that out earlier.
I never had a problem with location causing differences in pay. However that it extends to options grants always seemed to me as utterly incomprehensible. Why should you living in the Bay Area mean you get a massively bigger lottery ticket than somebody in Europe or India.
> That's not an exaggeration by the way: the only service running at the time was a New Relic trial account that only allowed monitoring of one, maybe two servers out of the (I think) total of 15-20 servers we had at the time.
I don’t feel so bad about my monitoring setup now.
> Or as the Dutch saying goes: "Lekker gewerkt, pik!" (good luck translating that).
Google Translate says this just means "Nice work, dude!" Out of curiosity, is there some culturally-specific subtext which is missing from that translation?
The flaw in the argument is the assumption that Directors were more adept than Individual contributors. Most dev shops have this problem as folks further away from the IC work , the least they can anticipate the problems
"Many of the performance problems solved during my first few years at GitLab were N+1 query problems."
"Other frameworks have learned from this over the years and provide better alternatives. The usual approach is that instead of being able to arbitrarily query associated data, you have to pass in the data ahead of time. The benefit here is that if you were to forget passing the data in, you'd run into some sort of error rather than the code querying the data for you on a per-row basis, introducing performance problems along the way."
can someone...translate this for me into human? If I want to query for some data I have to ....first pass the data in? Where did I get the data? I can't parse this paragraph at all. Rubyists....
Project.limit(10).each do |project|
project.members.count
end
Here `project.members` returns some sort of query object that produces a query along the lines of this:
[...] FROM members WHERE members.project_id = X [...]
In other words, you can just query associated data on a per-project basis, without needing to pass any additional arguments.
The problem this results in is that in the above code you'd run a COUNT query for _each_ project. Instead what you'd want is a single COUNT that groups data per project, such that you can then pass that data along with the `each` call. This setup would only require 2 queries, instead of 20.
To eager load data in Rails you have to explicitly opt-in, resulting in something like this:
Project.includes(:members).limit(10).each do |project|
project.members.count
end
The problem here is that an opt-in mechanism is too easy to forget (as is evident by how common these N+1 query problems are), and even if you include it there are certain cases where you still end up running extra queries for each row.
The solution here is to separate querying from the row instance types, e.g. a "Project" type can't query data itself and instead requires it to be passed in. This makes it much more difficult to create N+1 query problems.
They're likely taking about being able to query for additional data from the view layer. Rails makes this very easy since you often simply pass along query results to the view, which are "database connected" ActiveRecord instances. This way you can easily build the infamous "iterate over Posts and show their Users" N+1 example.
According to them, other frameworks require you to fetch all required data before passing it to the view layer, thus preventing this issue from coming up on the first place.
Very interesting to read as a former employee of a company being Gitlab's customer, self-hosting EE production and solving everyday problems, with their support also, during the described years
I wish the ‘More people doesn't equal better results’ would be put into every manager door and desk. I would also add more results to the quote to make it even more accurate.
The paid by location argument is a challenge for me. On one hand I really like meritocracy. Be paid what the job is worth. Or rather, what the market bears. But then the tone changes the moment the market expands internationally. Lots of people ready to do the job for far less.
Sometimes I sense a hypocrisy. A demand for things to be fair… but only within this artificially delineated geography.
On the other hand, nothing will make it not feel freakishly weird when HR needs to “approve” you, a 100% remote worker, moving somewhere, as a mechanism for cutting your salary.
Everywhere I’ve worked there’s always been one burnout engineer like this who doesn’t really know what anyone else does or why but is absolutely convinced that everyone else except for him is an irredeemable moron.
> No matter how you try to spin this, it's by all accounts an act of discrimination to pay one person less than another purely based on where they live..
Companies aren't gods charged with dispensing fair wages to us mortals. They are participants in the capitalist market.
And in that market, all prices are a matter of negotiation.
In any transaction, the buyer wants to pay as little as possible, and the seller wants to earn as much as possible. This isn't evil or greedy. It's a basic incentive that comes from the fact that people/companies/literally everyone prefers to have more money than less money.
Thus, your company wants to pay you as little money as possible, and you want them to pay you as much as possible. The same is true when the roles are reversed and you're the one in the buyer position. For example, when you're shopping, you want to pay as low a price as possible, and the seller wants to charge as high a price as possible.
Again, all prices are a matter of negotiation..
Power in a negotiation comes down to your BATNA, i.e. your best alternative if negotiation fails. Put simply, whoever cares the least has the most power.
In a capitalist market, that BATNA for the buyer is the next cheapest option. The next furniture store that's selling this couch for cheaper. The next adequately qualified software engineer in the Bay Area who's selling their services for cheaper. And the BATNA for the seller is obviously the next most generous spender. The customer who's willing to pay a little more. The company that's willing to pay higher salaries.
If it sounds like I'm conflating two concepts by comparing customers with employers, and businesses with employees, it's because you've been brainwashed into thinking these things are different. They're not.
When money changes hands, whoever receives it is the business. Whoever pays it is the customer.
That means, in the relationship between you and your employer, you are the business selling a service, and they are a customer paying for your service. Your salary is just a price. Your resume was an advertisement. Posting it everywhere was marketing. Interviewing was your sales pitch. As an employee, you are a business. (Someone just came along and renamed all the terms to confuse you.)
Which raises the question: Why on earth would your customer voluntarily pay a higher price than they need to? If all the stores in your area are cheap, why would they pay you more for your services than your neighbor is asking for?
When you travel to a country cheaper than yours, do you pay every restaurant, store, and taxi driver the same way you would at home?
No, you don't. Because that would be foolish. You pay local rates, which are less.
That's the same thing companies are doing when they pay lower salaries in cheaper areas.
If businesses were perfectly rational economic actors then all bay area/sv devs would be out of jobs.
> When you travel to a country cheaper than yours, do you pay every restaurant, store, and taxi driver the same way you would at home?
> No, you don't. Because that would be foolish. You pay local rates, which are less.
But if you could magically teleport to store or restaurant anywhere in the world, would you pay high prices to go to SV restaurant or store? No, that would also be foolish.
So local prices make sense of physical businesses because people pay premium for convenient access, for not needing to fly half-way across the world to do your groceries or whatever. But that same does not apply to full-remote developers; the work(/value) is getting delivered to the business all the same regardless where the employee happens to be physically sitting.
If the work/value delivered would be the same, then all software development would have migrated to Vietnam already. For some reason, companies think it is important that some developers are physically in Silicon Valley and they pay a lot to get that.
Is it about language and timezone barriers? No, because there are plenty of alternatives in the US as well.
If physical location is significant then it's not full remote position.
Beyond that, this is not just about sv vs rest of world, but about doing per-location adjustment based on local economic conditions. And it is pretty difficult to argue that the value of a developer to business is in anyway linked to their cost of living
I'd suggest the author thinks yet a bit more about this. "color of the skin", "gender", "location of living", I'm sure the author can figure out what differentiates the first two from the latter. For a start, one could think about which of these things one is able to change. Or you might ask the question: which of these things have actually something to do with my job? And yes, location matters: the company usually needs to create a subsidiary in the country of the employee, get familiar with their judicial and tax system, then there's also the issue of time zones, travel cost to company meetings, etc.
Don't get me wrong: one can surely discuss whether differentiating pay based on location is OK or not. However, comparing this to discrimination because of skin color or gender will not help this discussion at all, as in effect the author is comparing GitLab to a racist and sexist organization, which will end any discussion fairly quickly.