Upcoming Webinar: Becoming a Manager of Engineering Managers Register Now

The Value of Quantifying Technical Debt


The Value of Quantifying Technical Debt

Software teams do not tend to self-deploy optimally.

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.

How most teams self-deploy when they're not thinking about it

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.

Spread out refactoring and strengthen the team

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. 1

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.


  1. GitPrime quantifies engineering progress and can help with things like measuring the cost of paying down technical debt. 



Travis Kimmel is the CEO, co-founder of GitPrime, the leader in data-driven productivity reporting for software engineering teams. He is experienced in building high-performing teams, and empowering people to do their best work of their careers. Follow @traviskimmel on Twitter.

Get Engineering Impact: the weekly newsletter for managers of software teams

Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.