Another perspective to consider as well: while you are spending the time investing into and training people who needs the training and investment, your competitors are throwing money luring away the ones you have already trained, and leaving you in the dust in terms of velocity.
Turtles all the way down. Once a game shifts into zero-sum, it's not gonna stop getting played until it collapses.
Normally, I would say to avoid entering into any zero-sum games. But the world has made a sharp turn towards zero-sum over the past 5 years, so that advice has rapidly become impractical in today's climate.
Not every business needs to be aiming for hyper-growth. Perhaps some tech startups can take a breather and reconsider whether they need to be engaged in the same zero-sum game as everyone else. Because grow at all costs doesn’t just harm untrained juniors- it also leads to corner cutting and short-term thinking that could bite the business in the back later on.
Or is it? I think this ignores the human psychology factors. Like actually following through with being loyal to employees, training as a benefit etc.
Also if you are going to lose employees because you can’t match competitive salaries than i would say you are losing them if all other things are equal.
In another words this greatly oversimplified version of events here only allows for you to come to that conclusion and dismisses how an organization could adopt different practices, values and foster organizational culture that combats these issues differently which I think training is an essential component.
I actually think this is a good argument for licensure like civil engineers etc have to have, because one thing it mandates is required training hours (among other reasons I won’t diverge into here for the sake of staying on topic)
You can debate what that should look like and I encourage that but I see little downside to forcing employers to acknowledge that all employees may need some time just to train on new things and different concepts away from the day to day work. I know this is a little bit of a tangent here but it’s something I see so often at every level of an engineers career path yet organizations so rarely set aside adequate time for it.
When you are early in your career, it’s quite easy that within two or three years your market rate can easily go up 20-30%, but your HR policies don’t allow more than a 5% raise.
Why wouldn’t a developer leave for more money and more learning opportunities?
1. Not saying they should or shouldn’t and as I noted if you can’t match salary and all other things are equal you may as well take the raise.
2. If that’s HR policy and you request for an exception and it’s denied, that may be a sign to start asking more questions.
3. You’re assuming that’s HR policy. Again, example dictates you have one option without actually thinking through how an organization could position themselves differently. Of couse salary is a component and rightly so, but at a certain point it’s just not everything
Think of it this way: lifestyle, ancillary benefits, “perks” etc can be all valid reasons to stay a place that treats you well and displays real loyalty (which is often displayed in more generous long term planning like big 401K contributions and fully paid health insurance for the family, open source software time etc). Can’t say I would just arbitrarily leave that for an extra 20% because that 20% can be easily eaten in other ways. Not to mention transparently knowing that your job won’t evaporate if the economy gets soft is a win. All this salary gloating is fine until that happens. 1999-2001 was not a fun time to be in the upper band taking pay cuts
Let’s not grossly oversimplify this. I’m never going to say don’t maximize your value, you should, I’m saying there is more than one (salary) way of doing that.
FAANG or not.
Oh and one dirty secret FAANGS don’t tell you? They happily underpay on salary once you’re in, or freeze you into a specific department etc. it’s not all roses.
You’re probably speaking as someone who is not early in their career. But we are talking about junior developers.
I’m nowhere near west coast salaries but just big city America salary for context. At my age now in my mid 40s, married, making about the average salary of a top IC in my market, with the big house in the burbs (again not bragging, any developer with 5-10 years of experience could easily afford it), with the white picket fence and 2.1 kids, yeah 20K more wouldn’t make a difference in my lifestyle.
But, when I was just starting out in 1996 making $33K a year, $20K meant a lot.
But salary compression and inversion are real phenomena where HR policies don’t allow for raises to keep up with the market.
I was working during both 1999-2001 and 2008-2011. In 2000, it was very much just a dot com thing. If you worked in corporate America as a standard Enterprise Developer you weren’t really affected.
2008 was rough, but still there was no such thing as job stability. Companies were laying off left and right. I survived three rounds of layoffs - barely. But even then you could find contract gigs if you were the perfect fit.
Well, your 12 years my senior so age is something else eh? ;) I started out at 19 working at a FANG (because of privacy and such I don’t want to drop which one) not as an engineer but doing support work. Within a year I got the chance to be a junior engineer no questions asked (basically) because my manager at the time was impressed at my grasp to “get it” when it came to application usability.
That is to say I got extremely lucky. I know that. My takeaway since (I’ve been a software engineer for ~10 years now) is that the way I was treated as a junior is what I described throughout this post, and my mentors were the ones that drilled home what the hidden costs were taking jobs based on salary, how to properly evaluate benefits etc. I learned a boat load.
So I want to preach to developers and companies alike that things can and should be evaluated differently and to avoid pitfalls that are easy in this industry
And that’s just it. You worked at a FAANG - a company large enough that could carry the dead weight of junior developer (no insult intended we were all dead weight at some point).
I’ve worked at smaller companies by choice or at smaller divisions of large companies (occasionally). One developer salary is a major cost and can add to their revenue.
If you only have a few openings, you better make them count.
For instance, I know that some features I designed and developed from the ground up was the difference between us getting a client (B2B) and not getting a client. I also know how much revenue that client added directly to our bottom line. I was what is usually called a Single Responsible Individual. When one hire needs to be that impactful, there is no room for training juniors. All of our local software engineers can point to a feature they spearheaded that added measurably to our revenue.
Now the hard truth is, why hire junior developers locally when you can hire people with much more experience overseas for the same price? I know the stereotype of the crappy outsourced developer, but I haven’t found that to be the case.
Anecdotally, I was lucky enough never to be a junior developer[1], I got my first job out of college with a small company based on an internship the previous year. My first assignment was create a networked data entry system in C that was the basis of a new department that they were starting that allowed them to double in size. But I had been a hobbyist programmer for a decade. By the time I got my next job, I was already considered a mid level developer.
[1] yeah that did hurt me later on. I didn’t get any type of real mentoring and stayed an “expert beginner” for a decade.
Because you can mold junior developers into a certain quality. You can’t always do that successfully when you hire experienced developers sometimes. That’s why I was brought into the situation I was: it was more cost effective to get me up to speed than it had been trying to hire experienced developers for the same work, because they had too many pre conceived notions about how the product was to to be built
For what it’s worth I work at a small company now that is a startup and this is how we do things, to great success, the way I described it
To be clear, I do not work in Silicon Valley either, never lived in SV. So I get that part of it
That’s the point. Once you have “molded” the junior developer for a year a two, they can easily jump ship for greener pastures.
I’ve seen the argument about paying them market rates. But honestly, if they are young and unencumbered, their “market” is the entire US. Meaning you may not have been in the position to pay them what they could make if they were willing to move across the country.
To go into more anecdotal detail, I had been programming as a hobbyist since I was 12 in assembly for 10 years by the time I graduated from a no name college in the south. I had two job opportunities - one making an entry level developer salary writing COBOL [1] in a slightly larger city, or working as a computer operator in a major city. I chose the latter job that paid much less just to get to the city. I got lucky and I was the only one who knew how to program so they gave me the previously mentioned project straight out of college. They gave me a raise the next year to that of an entry level developer (I was hourly at first and got a lot of overtime).
But now, three years later, the project was done and with a major green field C project under my belt, my market value had gone up more than 50%. They couldn’t justify paying me that and I got another job.
Now if a similar scenario had played out in today’s market instead of 1999, even if they could have matched my local salary of $80-$100K for a mid level developer, I could have spent a year studying “algorithms and leetCode”, picked up and moved to SV and doubled or tripled my total comp. There is no way they could compete with that.
Let’s look at the current state of affairs. Almost every engineer at my company is between 35-50. They purposefully created the office in the burbs three years ago to attract older developers. They not only get experience, paying local market salary is relatively easy comparatively. The chance of any of us uprooting our families, selling our big, relatively cheap 3000 square foot houses in the burbs with the great school systems and moving to the west coast is slim.
I still think it’s an incorrect assumption that you’ll just lose engineers you train, full stop. There are a lot of reasons being willfully ignored and a lot of assumptions being made that I have not seen nor seen data to the effect of happening en made.
We train developers in popular languages (particularly our stack leverages Vue and C# and a good deal of custom SCSS) we are only ~3 hrs from the valley yet we aren’t losing engineers in droves and haven’t ever for the years we have been in business
You should pay juniors market rates for their positions, period. I don’t agree with that at all
It wasn’t a usual set of circumstances and I had a good manager who basically bet his neck in me being a good fit. I’ll never forget such an act of kindness. I hope to pass that in as much as possible in a responsible way
> I actually think this is a good argument for licensure like civil engineers etc have to have
This logic is sound, but I don't personally agree that bureaucracy is gonna solve any of our problems.
The rest of your comment, I believe if you spend time reading my OP carefully and spend some time noodling over it then you'd find that all of it had been covered already.
I don’t think it’ll solve all our problems but I don’t think bureaucracy per se is the enemy either. I’d need more of an argument as to why it overall wouldn’t be a good thing.
I don’t buy gate keeping either as the number one issue, see the lawyer glut as an example.
>while you are spending the time investing into and training people who needs the training and investment, your competitors are throwing money luring away the ones you have already trained
That is a zero-sum attitude that does not hold up when a company does other things well. If you are training your employees, you are likely to be doing the other things that help retain employees (https://www.bayshorestaffing.com/images/uploads/Blog_Image.j...). And if you are focusing on and actually delivering all ten of those benefits, employees are extremely unlikely to be jumping ship unless they are either a poor employee or have poor character (which you don’t want anyhow), or the competition is paying not only well above market rate, but well above your rates. Which means that they are now at a strategic disadvantage because an inordinate amount of funding needs to be diverted to payroll - much more so than in a company like yours.
Any company can make an end run around zero-sum thinking by fully and honestly employing those ten benefits. Employees can and will rise to the occasion, bringing a competitive advantage to your company that is well in excess to their numbers.
Turtles all the way down. Once a game shifts into zero-sum, it's not gonna stop getting played until it collapses.
Normally, I would say to avoid entering into any zero-sum games. But the world has made a sharp turn towards zero-sum over the past 5 years, so that advice has rapidly become impractical in today's climate.