You're leaving out some serious costs incurred by your company and team. The loss of institutional knowledge, the loss of expertise, business process knowledge, personal relationships that could make hard changes much easier. Sure, you hired someone for $X instead of $X*1.2 but in terms of work done you probably missed out on a lot and came out way behind.
I think you're both overestimating those costs and also underestimating the difficulty of just being able to suddenly pay 1.2X for people.
Re: institutional knowledge and expertise, etc - we tried to avoid too much concentration. If all the institutional knowledge for system X is tied up in person Z, what if they want to take on to a new roll, or I want to ask them to work on a different system or a new project? I like people who focus on what they can do next, not solely what they've already done. Otherwise it's a bad place for the company to be even if someone doesn't leave. Change is a constant, flexibility is good.
Re: personal relationships - morale is always something to keep an eye on, but someone having an exciting new opportunity never seemed to hurt the rest of the team's morale that much.
I think you're also making an unspoken assumption that the new hire wouldn't be superior to the person who left in some areas! The most common case of this was "generalist who built a ton of stuff in an earlier phase of the company leaves, replacement is more experienced in the specialized area that that generalist was currently working on since the company was larger now and they couldn't contribute to everything as easily," but that's hardly the only way.
And lastly, as I alluded to about budgeting more to keep the top two performers than the third - I think you're overestimating the amount of effort and/or success put into by the average developer at becoming the go-to expert on specific techs or business processes. If I tell my manager "I know the second most about React, the third most about Node, and the second most about the plugin system business logic" I'm not going to expect them to find me irreplaceable.
You're trying very hard to dismiss experience specific to a company and industry, but I'm not buying it. Someone who has intimate experience with an established code-base and the company will be vastly more proficient than a new employee of similar intellectual capability. It's why companies often try to hire people within similar industries and tech stacks to help reduce this gap.
It's like trying to argue that a mechanic who has only worked on Ford vehicles for 20 years should be able to quickly have the same proficiency as a mechanic who has 20 years of experience on only Porches. Nonsense.
Remember, a company can typically expect to hold onto a developer for maybe 3-5 years, so even half a year of training is a significant portion of their tenure.
But the status quo is already change and loss of expertise and teams and products continue along fine.
Also you maybe discounting the change in code itself even when I have years at a company I’m still continually learning things because I’m working on new things or new things are being built. If I left a new hire would be able to ramp up on these fresh code based without much hassle. So expertise itself has a half-life in a fast moving field like a lot of software shops.
>status quo is already change and loss of expertise and teams and products continue along fine.
Change in a way where past experience still translates to value. And yes, with enough money and brute force you can overcome the loss of tribal knowledge, but that's the whole point of this conversation; it's an expensive thing that's often not worth it and definitely not something easily dismissed.
