There’s no way around it; turnover is a bear. We’ve likely all been a part of a team that experiences ill-timed or, at best, unexpected turnover. Even in writing this, I squirm at the thought of the scrambling to backfill, the difficult conversations with stakeholders, and the pressure that mounts while desperately working to get a new resource up to speed with an eye on dwindling velocity. Does any of this sound familiar?

Why is that for so many organizations, developer turnover comes as a surprise? Just a quick look at the numbers shows the simple nature of the industry landscape of which we are all at least implicitly aware. According to the US Bureau of Labor Statistics, demand for software developers is on the rise, projected to grow by 22% by 2029—a staggering trajectory when compared to the average projected growth rate across all occupations, paling in comparison at a meager 4%. In terms of new jobs in the application development space, 310,000 are expected to be created in the same time period. Simply put, demand for developers is up and the sheer volume of employment options is far from gratuitous.

Given the industry employment landscape, the question of whether or not turnover will happen is not a question worth asking. It will. And while a healthy focus of building employee retention is crucial, an equally crucial endeavor is positioning your product teams to handle turnover when it does happen.

As with all businesses, emphasis on the balance sheet is crucial to bottomline health. An issue with this emphasis, however, often arises in the tension between business value add versus real value add. Put into context, the unchecked objective of eliminating as much time as possible spent on business value add objectives curtails any meaningful effort to focus development team capacity on adequate succession planning. This common scenario, played out to its logical end, can leave teams feeling debilitating pressure when someone on their team moves on to a new opportunity, and plagued by the questions of how much time will be spent helping a new team member get up to speed.

“How quickly will a replacement be brought in?”

“What additional slack will need to be picked up in the meantime to ensure objectives are still met?”

“How long will it take to get back to our previous velocity?”

Such questions not only distract the team and detract from their work, they can also be the precursors to subsequent burnout resulting in additional turnover.

So what is one practical step that can be taken to help mitigate the negative effects of product team turnover?

The concept of minimal viability, generally applied to Agile product development, just may be the cure for what ails you.

Just as product teams seek to define and develop the minimum requirements necessary to deliver a testable piece of software and continue iterating from there, so too can succession planning be approached from the perspective of minimum viability. Think about it, or better yet, provide a bit of time for your product teams to think about it.

What are the bare minimum requirements of a viable succession plan within the context of the team’s work?

Focus in on the must-have features and lean on your Scrum Masters to compile the plan for their teams. From there, iterate. Take each instance of turnover (and hopefully there aren’t many!) as an opportunity to reflect on and improve the onboarding process, a perfect conversation for a sprint retrospective. And understand that the upfront costs associated with planning will yield dividends down the road.

In doing so, not only will the members of the team feel better cared for—especially new members backfilling open positions—but should turnover occur, velocity will be better maintained in spite of it.

And chances are you’ll see the value of that upfront investment in your teams jump across the balance sheet.