Newsletter
Engineering Management
Organization Design

Adapting to the 2-Year Tech Talent Turnover: A Personal Journey

High Talent Turnover Rate In Technology and Software

Let me tell you a story about my journey from a rookie CTO to someone who’s learned a thing or two about navigating the choppy waters of tech talent turnover.

I’m Klaas, and I’ve been in the trenches of technology leadership for over two decades. I’ve seen companies rise and fall, and I’ve learned that in this industry, high-speed change is the only constant. 

The Tech Talent Merry-Go-Round

One of the first hires I made at The Sun was a cornerstone hire in our switch from contractor to permanent staff. Technically solid, good attitude, future leadership material. I was excited about bringing him in and changing the place together.

Fast forward 18 months, and he’s handing in his notice. I got the polite “it’s not you and this is a great place. I was made a better offer”.

Sounds familiar? 

Welcome to the tech industry, where the average tenure of a skilled professional is about as long as it takes for the latest iPhone to become obsolete.

The tech industry sees a higher turnover rate than almost any other sector. Some research pegs tech turnover at 13.2%, while other studies report an even steeper rate of 18.3%.

When I first stepped into a leadership role, this constant churn left me feeling like I was building a sandcastle at high tide. Every time we seemed to make progress, another wave would come and erode the foundations. It wasn’t just frustrating; it was expensive and disruptive. I knew we had to find a way to build something more permanent or at least learn to surf these waves of change.

The Cost of High Tech Talent Turnover Rate

Let’s not just think the cost here is purely financial. Sure, the recruitment fees and onboarding expenses add up fast. 

But the real cost? 

It’s in lost productivity and disrupted team dynamics, and the projects that stall because key knowledge walks out the door with each departing employee.

Seeing through that is when I realized we needed more than just a good recruitment strategy – we needed a complete overhaul of our approach to talent management. Rather than grumble about leavers, I needed to solve two things. How do I retain people longer, and how do I reduce the impact of someone leaving? Because no matter how good retention is, people will still move on eventually. And the longer they stay, the more impact a leaver tends to have. 

Rethinking Retention: The Real Motivators

Free Friday beers and a Playstation can help with social connection, but they don’t move the needle on retention.

The truth is surprisingly simple but often harder to implement than buying a PlayStation.

There are really only two things that keep your most brilliant engineers around: Money and Problems. Specifically difficult engineering problems and competitive salaries. Everything else is just window dressing.

Let’s talk about those difficult problems first. Your top talent – they’re not just in it for a paycheck. Engineers are problem solvers at heart. They want to sink their teeth into challenges that push the boundaries of their skills and knowledge. 

Since my time at News, I encouraged my teams to explore cutting-edge technologies. And you know what? Engagement skyrocketed. They weren’t just coding; they were innovating, pushing themselves and our products to new heights. Some of it ended up in our product, a lot of it ended up in the bin. But it created an endless set of the good kind of problems.

While challenging work is crucial, it’s not enough on its own. 

I’ve seen too many companies lose top talent because they thought perks or passion for the work would outweigh financial considerations. 

We had to take a hard look at our compensation packages. Were we really paying our top performers what they were worth? 

In one organization I ended up raising the salary of a few engineers by roughly 50% over the course of 12 months. You could class them as “bad negotiators”, I guess. Don’t be afraid to admit you were wrong, and more importantly: fix it.

The result? A much happier and productive team. A much happier CTO (me) who wasn’t worried about his staff getting poached every day.

Embracing the Inevitability of Change In Reducing Turnover Rate

Now, I’m not going to tell you we solved the turnover problem entirely. In fact, I believe some turnover is good anyway, even if that means losing some great people.

The key here is we started viewing our team as a constantly evolving ecosystem rather than a fixed structure. We focused on creating robust knowledge sharing systems, so that when someone did leave (and they inevitably would), their knowledge and contributions remained.

We also got smarter about our hiring. Instead of always chasing the most experienced candidates, we started looking for people with the right mindset – those who were adaptable, eager to learn, and aligned with our values. Sometimes, the fresh perspective of a newcomer can be just as valuable as years of experience.

Building Resilience Through Technology

“That fix was written by John, he left a few years back. Yeah…nobody really understands it”. That, unfortunately, is a very common scenario. Code is written down for everyone, but the reasons why often remain in the developer’s head.

True resilience is about unlocking that tribal knowledge: documentation and the right engineering culture.

Engineers and writing documentation aren’t usually good friends. And no amount of document management, tracking, or task assigning is going to fix that. You might produce documents if you whip hard enough, but you won’t get good documentation out of it. Good documentation explains not just what happened but also why. 

So, we made a radical shift in focus. 

We cultivated an engineering culture where documentation wasn’t just an afterthought – it was an integral part of the development process. We started treating our documentation with the same reverence as our code. Every feature, every decision, every architectural choice – all of it was documented clearly and kept up-to-date. And yes, that takes time. And yes, that means your engineers aren’t typing code in that time. But I’ll take historic decision-making knowledge over more random code any day.

But here’s the kicker. It accidentally created a culture where knowledge sharing was second nature. We fostered an environment where engineers took pride in making their work understandable and accessible to others. Code reviews became not just about catching bugs, but about ensuring the logic was clear and well-documented; and we captured reasons why we made decisions.

We also embraced the concept of “collective code ownership.” No more silos, no more “this is my code” mentality. Every team member was encouraged to understand and be able to work on any part of our systems. This approach created a sense of shared responsibility and dramatically reduced our bus factor.

The results were transformative. When someone left the team, we were no longer left in the lurch. The knowledge was there, documented, and ready for the next person to pick up. Our onboarding time for new team members dropped significantly, and we saw a marked improvement in code quality and system reliability.

Remember, tools come and go, but a strong engineering culture centered around documentation and knowledge sharing? That’s what builds true resilience. It’s not always easy – believe me, I know. It requires constant reinforcement and leading by example. But in my experience, it’s the surest way to build an engineering team that can weather any storm, including the inevitable ebb and flow of talent in our industry.

A Final Word About Technology Talent Turnover

Look, I’m not going to pretend I’ve got all the answers. 

The 2-year tech talent turnover is a complex challenge, and anyone who tells you they’ve completely solved it is probably trying to sell you something. 

But what I can say is this: by focusing on creating an environment where people can grow, where their contributions are valued, and where change is seen as an opportunity rather than a threat, we’ve managed to build more resilient teams.

It’s not about stopping the tide – it’s about learning to build ships that can weather any storm. 

Remember, all models are wrong, but some are useful. 

I hope you find something useful in my journey. Now, it’s your turn to chart your own course through these turbulent waters. 

Read more of our carefully crafted articles: