Developer turnover is a constant struggle that all software companies experience. Employees transition to new companies for many reasons. Sometimes it’s culture, sometimes they’re not fulfilled by the work they’re doing, more often its due to poor managers. Some of those cases might represent good reasons for an employee to move on. And frankly, sometimes turnover is good. If your organization is performing at a superior level and the bulk of your team is made up of A players, then saying goodbye to a B or C player should be a welcome change. C players don’t feel comfortable around A players unless they want to be one. But losing a strong B or A+ player can do a lot of damage to productivity and morale. The reasons a developer might leave your company are too many to count but there’s one reason many business owners never seem to grasp that could easily be solved by a few simple keystrokes in Excel and two minutes of your time.
Nearly every decent developer I speak to tells me they receive at least two or more calls or LinkedIn messages from recruiters every month. When I think about that, it sort of makes me wish I would have travelled down the development path versus the business path. If you’re a great hard-working developer, you can write your own ticket. You can chose the language you want to develop in, work from anywhere you want, and get paid great money to do it. This constant barrage of recruiter calls makes it a challenge to keep great developers on your team thought. Add to that the generational characteristics of GenXers and you may have a group of experienced employees who don’t mind switching careers every two or three years.
Developers Have a Very Unique Growth Rate
But I’m not writing this post to solve all those problems. I’m telling you one of the reasons most developers leave after 2-4 years is because they are assured a large pay bump simply by moving to a new company. Why is it that employees (and especially in-demand tech staff) can receive a 20-30% bump in pay making a single job change? It’s not because the other company values their skills more than you do. It’s usually due to you not keeping up with the Jones’. USLegal.com defines salary compression as, “the situation that occurs when there is only a small difference in pay between employees regardless of their skills or experience. Pay compression is the result of the market-rate for a given job outpacing the increases historically given by the organization to high tenure employees.” But their definition doesn’t hold true for developer positions because it implies employees have to stick around for a while (high tenure) to apply.
How to Increase Consistency In Your Engineering Team
The development world is totally different and most employers have no idea how fast the pay scale changes for even a decent developer. First, let’s assume a junior developer has 0-2 years of a experience and starts out at $50k. Next a mid-level developer makes $85k with 3-5 years experience and finally a senior developer makes $120 with 7-10 years of experience. If your organization is used to giving a 3% cost of living raise to all employees, regardless of their true market value, then by year two your junior developer already has enough experience to make 20% more by moving to another company.
One easy step to not losing your developers is to put your habits and preconceived notions (or your disdain for reality) aside and pay them what they’re worth. If we take the same spreadsheet and start out by entering $50,000 in year one and $120,000 in year seven like this:
Then highlight from $50,000 down to $120,000, select Fill:Series from the ribbon menu. Then choose the Linear option from the drop-down box and press ok. Your worksheet automatically fills in the missing values. Adding a quick percentage increase function and you can see how poorly your 3% cost-of-living raise looks to a developer that’s highly valued in the market.
Many CEOs and hiring managers I have worked with hate the very thought of this. Many would rather ignore these numbers on the very principle that they would never pay someone a 17% raise. These are executives that don’t keep good talent around for long. Mind you, I would never say that anyone should automatically receive a 17% raise just for showing up. Developers should have a clear expectation of what it means to maintain and growing into a junior, mid-level, or senior position. The job descriptions should be well-defined so they know what’s expected to move to a new position and they should have some path to work their way up their own professional ladder. If they don’t meet the expectations then by all means withhold their raise. But if your strategy is to maintain the status quo for no other reason than to protect your precious sensibilities around employee pay then don’t be surprised with unreasonably high turnover.
Wrap-UP
And finally, I learned very early in my career that everone is replaceable. If you lose your lead architect who’s been with you from the beginning it may seem like your world is crashing down around you. But fear not, even she can be replaced. Just remember the cost to replace him with someone on the open market (or a consultant) may be double what you were paying him before he left. So, as the old Fram filter ad says, would you rather pay him now or the other guy later. It’s totally your choice but don’t say I didn’t warn you.
0 Comments