It's clear why people do it (more pay) but it sets up bad incentives for the companies. Why would a company invest money in growing the technical skill set of an employee, just to have them leave as soon as they can get a better offer?
> culture of job-hopping
> Why would a company invest money in growing the technical skill set of an employee
At Taos, there was a monthly training session / tech talk on some subject.
At Network Appliance ('98-'09), there was a moderate push to go to trainings and they paid for the devs on the team I was on to go to the perl conference (when it was just down the road one year everyone - even the tech writers - went).
At a retail company that I worked at ('10-'14), they'd occasionally bring in trainers on some thing that... about half a dozen of the more senior developers (who would then be able to spread the knowledge out ... part of that was a formal "do a presentation on the material from the past two weeks for the rest of your team.")
However, as time went on and as juniors would leave sooner the appetite for a company to spend money on training sessions has dissipated. It could be "Here is $1000 training budget if you ask your manager" becoming $500 now. It could be that there aren't any more conferences that the company is willing to spend $20k to send a team to.
If half of the junior devs are going to jump to the next tier of company and the other half aren't going to become much better... why do that training opportunity at all?
Training absolutely used to be a thing that was much more common... but so too were tenures of half a decade or longer.
I'm pretty sure it just comes down to bean-counting: "we have a new fulltime permanent asset for $100k" vs "we have a new fulltime permanent asset for $120k" is effectively the same thing, and there's a clear "spend money, acquire person" transaction going on. Meanwhile, "we spent $20k on an asset we already have" is.. a hard sell. What are you buying with that $20k exactly? 20% more hours? 20% more output? No? Then why are we spending the money?
It's certainly possible to dance around it talking about reducing risk ("there's a risk this person leaves, which will cause...") but it's bogged down in hypotheticals and kinda a hard sell. Sometimes I wonder if it wouldn't be easier to just fire staff for a week then re-hire them at a new salary.
I guess that's how we got here to begin with. We take a workforce and treat is as expendable instead of as a proper team.
I suppose it will vary per industry but I can't imagine an other kind of engineering being comfortable just letting go of people mid-project because "we can afford to lose them".
Employers get straight up lazy, by having soft negotiating employees to ignore. This laziness will bite them.
This incentive is entirely backwards. It should be "what are we losing with not spending that 20k?". You lose out on someone used to the company workflow, you waste any training you invested in them, you create a hole that strains your other 3-4 100k engineers, and you add a time strain to your managers to spend time interviewing a new member.
if you really believe you can buy all that back for 120k as if you ran short on milkk, you're missing the forest for the tree.
>Sometimes I wonder if it wouldn't be easier to just fire staff for a week then re-hire them at a new salary.
if society conditions a workforce to understand the issue, sure. But psychologically. you'd create an even lower morale workplace. Even for a week, people don't want to be dropped like a hot potato, even if you pick it up later as it cools. People want some form of stability, especially in an assumed full time role.
You keep a good thing going, you buy oil for the machinery, you keep your part of the bargain and do the maintenance. You pay the correct price for the stuff you are lucky enough to have been getting on the cheap.
I like the directness of the question: "Why should I pay more when it won't burn down right this instand if I don't?" This is a question asked all over, and it is dangerous, keeping anything going requires maintenance and knowledge in how to maintain it. That goes for cars and it goes for people.
This is not business, it is miserly behaviour, it is being cheap.
The miser will find himself in a harsh, transactional, brutal world. Because that is the only way for people to protect themselves against him.
This is why I never do internal job transfers. The total comp doesn't change. If I do an external job change, I will get a pay rise. I say it to my peers in private: "Loyalty is for suckers; you get paid less."
It's no surprise the market adapts to the new terms and conditions. But companies simply don't care enough to focus on retention.
You're falling for the exact same fallacy experienced by failed salesmen. "Why would I bother investing time in this customer when they're just going to take my offer to another dealership for a better deal?"
Answer: you offer a good deal and work with people honestly, because if you don't, you'll never get a customer.
What you say only works if everyone is doing it. But if you're spending resources on juniors and raises, you can easily be outcompeted and outpoached by companies using that saved money to poach your best employees.
give a big enough raise and they won't want to be poached. You won't retain everyone, but your goal probably isn't to compete with Google to begin with. So why worry of the scenario of boosting a good junior from 100k to 150k but losing them to a 250k job?
In some ways you will also need to read the room. I don't like the mentality of "I won't hire this person, they are only here for money", but to some extent you need to gauge how much of them is mission-focused and how much would leave the minute they get a 10k counter-offer. adjust your investments accordingly and focus on making something that makes money off that.
I've started viewing developers that have never maintained an existing piece of software for over 3 years with skepticism. Obviously, with allowances for people who have very good reasons to be in that situation (just entered the market, bad luck with employers, etc).
There's a subculture of adulation for developers that "get things done fast" which, more often than not, has meant that they wrote stuff that wasn't well thought out, threw it over the wall, and moved on to their next gig. They always had a knack of moving on before management could connect the dots that all the operational problems were related to the person who originally wrote it and not the very-competent people fixing the thing. Your average manager doesn't seem to have the capability to really understand tech debt and how it impacts ability to deliver over time; and in many cases they'll talk about the "rock star" developer that got away with a glimmer in their eye.
Saw a post of someone on Hacker News the other day talking about how they were creating things faster than n-person teams, and then letting the "normies" (their words not mine) maintain it while moving on to the next thing. Thats exactly the kind of person I'd like to weed out.
Some genius MBA determined that people feel more rewarded by recognition and autonomy than pay, which is actually true. But it means that all the recognition and autonomy in the world won't make you stay if you can make 50% more somewhere else.
Th power structure that makes up a typical owners-vs-employees company demands that every employee be replacable. Denying raises & paying the cost of churn are vital to maintaining this rule. Ignoring this rule often results in e.g. one longer-tenured engineer becoming irreplacable enough to be able to act insubordinately with impunity.
A bit bleak but that's capitalism for you. Unionization, working at a smaller companies, or at employee-owned cooperatives are all alternatives to this dynamic.
But as someone who originally wanted to be a specialist (or at the very leastT-shaped), I see a lot more problem in fostering specialists than generalists under this model. Sometimes you do just need that one guru who breathes C++ to come in and dig deep into your stack. Not always, but the value is irreplaceable.