October 23, 2022

How to talk about Tech Debt

Sometimes it’s hard to convince a manager to pay back a Tech Debt of a project, even just a little. I’m sure you know what I’m talking about. Maybe it’s a matter of using good arguments?

First of all, I don’t think using statements like I believe… or I hope… is a good idea, even if the manager really respects and trusts you. Remember, hope is a project killer. And as long as we aren’t in church and don’t practice any religion, we should focus solely on doing business.

For almost all organizations these days, it is crucial to make well-informed, data-driven decisions. Thus, we should use the language understood well by managers - the data language.

One of the things you can do is to refer to some business measures, like Time to Market or First Response Time, and say things such as this is going to reduce Time to Market by approximately 20%, or by doing this and that, we can significantly improve First Response Time.

If you follow Scrum, you probably produce a lot of data, so you could verify and state: last X weeks / months we spent around Y% of time and money in fixing quality issues.

One of the indirect costs of high Tech Debt is the turnover. It is very expensive to replace a leaving developer, and so your manager definitely doesn’t want to do that. Just let them know that, for instance, spending 10% of the time on fixing quality issues can reduce the turnover.

The less money and time it takes to produce a new feature the better; so by doing this and that, we can reduce the variability in Marginal Cost of Production which is another important business concept.

Remember, “customers and managers don’t expect software teams to slow down with time. Rather, they expect that a feature which took two weeks at the start of a project will take two weeks a year later. They expect productivity to be stable over time” [Clean Agile]. It’s impossible without addressing code quality issues, so in case your manager doesn’t understand the consequences of keeping code’s bad quality, just explain it to them (preferably using data).