Expecting Developers to Leave

Because they will.

brown wooden side by side door
Photo by Craig Adderley on

My current team is the longest I’ve ever been with an organization (other than my own freelancing business), almost 5 years. Over the years the needs, motivators, situations, and lives of people within an organization can and will change. It’s the nature of life.

There are obvious ways to reduce turnover, like avoiding burnout of your team, compensating people well, providing adequate training and opportunities, and aligning individuals with meaningful work. Even with all of these things, and no matter how much people say it, no one is guaranteed to be around forever – or even the next year.

Twice now in my career, I have had someone say to me “I don’t plan on going anywhere” and then offer their two-weeks notice within 3 months’ time. And that’s ok.

We should celebrate when someone gets an opportunity to take a chance and chase a dream, or grow, or get a new opportunity.

What makes a difference at these points, is that the organizations and teams that expected developers to leave fare far better than those that do not.

Why should you expect developers to leave?

You have probably heard the phrase: “What if ______ gets hit by a bus?”.

This effectively means what if something unforeseen happens and the person is no longer with the organization. This phrase actually causes a huge problem in a lot of teams. Getting hit by a bus is a rare event. When we pause to ask if someone will not be with us, we phrase it and think about it as if it is a rare occurrence. In reality, in January 2020, the average tenure for a Computer Science/Math employee was only 3.9 years. This means that not only will someone leave on your team, it’s probably going to occur sooner than you think.

Why does expecting developers to leave help them not leave?

When we expect people to leave, our priorities change. We switch from “I can always just ask” to “Make sure we can be successful without you”.

When we change the culture to focusing on simplifying, documenting the “why”, and ensuring others can easily maintain code without the original author, we inherently reduce complexity. When we reduce complexity and the baseline requirement for understanding code and systems, we free up our minds to be more creative in other places.

This benefits teams not just when the developer leaves, but also helps free that person from questions when new developers join the project without the extra hand-holding.

Assuming devs will leave helps us unlock the full potential of our teams in creating real value for customers, both faster and with more brain bandwidth to build better solutions.

Thanks for reading! Enjoy this article? Join the newsletter!

Ten years ago I thought I had to choose between good opportunities as a software developer in larger cities or living where I actually wanted to live (a much smaller town).

I spent the next decade building a personal brand, a freelancing business, side projects, a local and online developer community, and more to create the career I wanted and live where I wanted.

Now, I want to teach you to do the same. Join me and hundreds of developers on my newsletter for my most popular posts here and other useful tips and tools to help make your own opportunities.