On the one hand Mr. Dean rightly recognizes that longer-tenured developers bring more company-specific and domain-specific expertise to the table and they should be paid attractively to prevent them from leaving and taking that knowledge with them.
On the other hand he touts his use of a compensation formula, reducing engineering salary to a formula rather than taking into account an individual's background, experience, expertise, demeanor, and individual impact. (To be fair, he does emphasize that the formula will include "performance" in some way, but I've always been leery of boiling down performance to a simple equation. We've all been in roles where people have had material impacts other than lines of code committed, features completed, or KPI scores.)
I suppose I fundamentally agree with the author's premise that tech salaries should rise with the overall market to keep institutional knowledge from walking out the door, but on the other hand I don't think following a simple equation is the best way to get there.
It might be valued that way presently, but that doesn't mean that's the worth. The companies that rightly assess the situation and determine that the cost of mistakes made because institutional knowledge is gone or the cost to productivity of retaining replacement personnel is high enough to justify an additional 2% - 6% annual salary increase across the board will outperform the companies that are constantly paying the training toll.
How many times have you had a deployment go wrong shortly after the one guy who knew how everything worked left? What did it cost the company in terms of developer hours, productivity, opportunity cost? How many times have you witnessed a new hire take 30 - 90 days to get even halfway up to the speed and productivity levels of someone who's been with the company for a year or two? If you're swapping one employee for a small handful of failures plus a new, at-market employee who has half the productivity level for a full quarter then you're easily paying a 25% premium to let that employee go, when you could've retained them and made them feel appreciated for a 6% annual raise. It's frustratingly straightforward to determine which result is better for the company's bottom line.
On the other hand he touts his use of a compensation formula, reducing engineering salary to a formula rather than taking into account an individual's background, experience, expertise, demeanor, and individual impact. (To be fair, he does emphasize that the formula will include "performance" in some way, but I've always been leery of boiling down performance to a simple equation. We've all been in roles where people have had material impacts other than lines of code committed, features completed, or KPI scores.)
I suppose I fundamentally agree with the author's premise that tech salaries should rise with the overall market to keep institutional knowledge from walking out the door, but on the other hand I don't think following a simple equation is the best way to get there.