Programming

Above a certain level of seniority (in the sense of real breadth and depth of experience rather than merely high count of work years) one's increased productivity is mainly in making others more productive.

You can only be so productive at making code, but you can certainly make others more productive with better design of the software, better software architecture, properly designed (for productivity, bug reduction and future extensibility) libraries, adequate and suitably adjusted software development processes for the specifics of the business for which the software is being made, proper technical and requirements analysis well before time has been wasted in coding, mentorship, use of experience to foresee future needs and potential pitfalls at all levels (from requirements all the way through systems design and down to code making), and so on.

Don't pay for that and then be surprised of just how much work turns out to have been wasted in doing the wrong things, how much trouble people have with integration, how many "unexpected" things delay the deliveries, how fast your code base ages and how brittle it seems, how often whole applications and systems have to be rewritten, how much the software made mismatches the needs of the users, how mistrusting and even adversarial the developer-user relationship ends up being and so on.

From the outside it's actually pretty easy to deduce (and also from having known people on the inside) how plenty of Tech companies (Google being a prime example) haven't learned the lesson that there are more forms of value in the software development process than merely "works 14h/day, is young and intelligent (but clearly not wise)"

assume that productivity is a feature of an individual and not a feature of a team. That’s a wrong assumption. The fairest way to pay is same salary for the whole team.

So much of what we do produces nothing, but prevents a lot. There is definitely a reason to pay for experience and seniority: it's not so much about creating widgets faster but more about not making short-sighted decisions. And in dev work, we have a high chance of making bad decisions as we're second-generation lost-boys.

Having said that, those individuals are out there for whom compensation starts competitive and ends just short of their value. It's eye-opening to meet and talk with these people and, once you do, it will change your life having them in it.

Think of it from the company's point of view. If you're hiring a new employee then the options for a good candidate are a) move jobs and work for you, b) move jobs and work for someone else. You're competing with other companies.

If you're reviewing an existing salary for a good employee their options are a) do nothing and accept the shitty raise, b) move jobs and work for someone else.

Moving jobs has significant cost for most people - it's time consuming, stressful, might involve moving house, etc.

That downside gives employees who haven't proven they are looking for a new job a significant negotiating disadvantage.

If you really want you can tell your boss you are actively looking for new jobs. That will increase your chances of getting a bigger raise, but of course it has other downsides so most people don't do that.

He said in the article:

When hiring someone new, companies are forced to play in the open market, competing for top talent. But internally, they create opaque and informationally asymmetric compensation structures designed to minimize growth for existing employees to save the company’s bottom line.

So yes, this is totally just how many (most) companies are run. I work in healthcare and have faced similar issues, where someone I hired as a new grad who accumulated 5 years of experience with me would be making $20K less than someone I just hired who had 5 years of experience somewhere else. I always had some words for anyone who tried to talk to me about retention rates

Well, I'll give it a shot.

Part of it is that they can't know the point that someone is willing to stay vs leave, and they're always optimizing for that point. Saving money is always the goal for expenses in a company.

Part of it is that they have a budget that they can't exceed. Sometimes a person is overqualified for the job, and the job simply can't afford them. Sometimes that person will stay far longer than they should, when they could get paid much better elsewhere, and sometimes they choose to move when they're only slightly underpaid for their skills.

Part of it is that there is more to a job than money. Being comfortable, un-stressed, and generally happy is more important at some point than more money. The company tries to balance these things, as it's often cheaper to relieve or prevent stress than pay someone to put up with it.

In the end, it's super complicated, but all about money, on both sides.

Often the money if far more than the individual realises.

1. Depending on the country, there may be taxes or other benefits which rise to the same degree or more.

2. Members of the team or grade need to be paid amounts which are within some range so that everything is fair.

You may feel you're worth more than the majority of others, but it's rarely the truth.

A VP was brought in at the company I used to work for that claimed "I need to offer candidates substantial increases or else I won't attract top talent". He started hiring people at a significantly higher rate. (I left at this point) Soon, the other engineers found out and all hell broke loose. They demanded equal pay.

The company is currently in financial difficulties. The salary bill got too big. They're now struggling to complete the projects underway because they've had to cut staff and the 40yo company is probably going to be swallowed up.

...he should do anti-gravity next.

There's a python library for that.

I was kinda baffled by this too. I like the general idea that they present (you need to pay your own long-tenured engineers higher than market rate cause they actually know more about your own system), but this idea of a formula? What, are you gonna start counting git commits? A formula sounds like a super weird way to solve that problem.

Just look at the engineers that add value in your company and pay them a fair market rate. When someone leaves, find out what salary they get in the new job and ensure all your remaining engineers get at least that amount and adjust as you go along. Something like that perhaps.

Let's do FTL travel directly after