Software teams do not tend to self-deploy optimally.

Fun fact: senior engineers spend the largest percentage of their time paying down technical debt. While this may seem intuitively true, talking with our users has revealed how uniform this is across the industry.

In fact, “person who cleans up the most old code” tends to be a simple but accurate predictor of seniority for teams.

Unfortunately this isn’t necessarily the best case scenario for the team, as it can lead to an undesirable state of affairs: slow but steady snowballing of technical debt.

Why does this happen?

1. When a particularly nasty and long overdue refactor rears its ugly head, it often comes with lots of time pressure.
2. The work is nearly always high risk, since modifying poorly architected bedrock code can cause the software to break in ways that are costly and embarrassing.

This creates a coordination problem not unlike the Prisoner’s Dilemma. The rational move here is almost always to let a Senior Engineer handle it. While this is a rational decision for every instance of overdue refactoring, or critical bug, it’s not actually the best outcome for the team as a whole, and this leads to the vicious cycle above. Chances are that your team does this too: the Senior-most engineers spend the most time refactoring legacy work.

A better way

The ideal scenario is a workflow where Senior Engineers are freed up to establish patterns for the rest of the team and each engineer becomes stronger and trains up to become a domain expert.

How to correct it

Measure it: The first step is seeing it. Without a feedback loop for how much work is being sunk into refactors on a weekly (or sprint-ly) basis, deciding to spread the load is impractical: there’s no way to measure success. ¹

Be proactive: Incorporating this as a core metric into your team retrospectives and planning meetings, and encourage Junior engineers to take on important refactors before they come to a head and create time pressures in lieu of sticking to blue sky implementations & new features.

Look Forward: Set specific goals for upcoming development cycles and set up concrete goals for spreading the refactor load. Encourage new engineers to take ‘ownership’ of old areas of the codebase that have been neglected, which will help them build up their domain knowledge on the product.