Every engineering organization I work with has a challenge: making the case for the work you need to do as an engineering team that doesn’t directly result in new or improved features.

This is work such as upgrading libraries, refactoring code to be easier to understand and maintain, moving to take advantage of changes in the technology landscape, and fixing the consequences of decisions you made in the past that you now realize weren’t optimal.

Mostly, this all gets described as “technical debt,” but this has moved far beyond the original metaphor from Ward Cunningham (which he describes in this video).

The problem is, to quote Kent Beck: “Many business folks hear ‘mistakes,’ ‘delay,’ and ’no progress’ when they hear ’technical debt.’” It can be very hard to get this work prioritized, and so teams end up moving further and further away from a habitable software system, one that’s nice to live and work in.

Kent suggests talking about reducing friction rather than about technical debt, and I like this idea, particularly for all that work that is about keeping your software estate up-to-date and in good nick.

However, I actually think there are three different things that all get lumped into “technical debt”:

• You aren’t keeping on top of support and maintenance. Your tech estate is a garden; you need to mow the lawn and weed.

• Realizing that you made a bad choice or that technology has moved on. If you want innovation, you need to be prepared to fail sometimes, and to have to backtrack or redo. And things change: otherwise I’d still be writing EJBs to run in an application server.

• True technical debt, as defined by Ward Cunningham. You take an approach that gets you to value quicker, but knowing that you are borrowing against your future velocity, because (a) you will have to pay back the loan and (b) in the meantime you have to keep paying interest.

Identifying this technical debt and paying it off is often the most valuable thing a Principal Engineer or Director of Engineering can do, but to do it effectively, you need to be able to translate it into language that makes sense to people outside of engineering: your executive leadership, or your product counterparts.

I would tackle explaining these three things in business terms in different ways.

The first challenge, ongoing support and maintenance, is part of building and running software systems, and so it should be part of the cost of doing business. I don’t think a product owner or stakeholder should be making prioritization decisions around this; don’t schedule this work in competition with features. All your estimates should, instead, leave time to be continually doing this. Start measuring whether delivery is slowing down, or whether you are seeing simple changes breaking systems and spending more time on fire fighting. The message to stakeholders is that you need to grease the wheels if you don’t want to slow down over time.

Tackling the second type of tech debt, around evolution, means doing a true cost-benefit analysis. Too often, people invest lots of time and effort in a migration, for only marginal improvements or cost reductions. I think you should do migrations either because you have to (for example where things are no longer secure or supported), or where you gain a significant benefit to the business. Frame the work in those terms.

And for the final type of technical debt, the original concept: ideally you should have the conversation before you incur the debt. When you look at the feature being requested and the timelines, be clear on how getting into production early will impact on the things that executives and stakeholders care about. As Nick Selby says in his Fast Company article, “executives speak in velocity and competitive advantage,” while engineers speak in systems and code quality. Do the translation.

And do remember that incurring technical debt isn’t about consciously writing code poorly. It’s accepting that the system you build reflects your current, partial understanding of the problem and being willing to ship it anyway. If hitting the deadline means skipping tests or writing insecure code, you are making risky decisions. Discuss the risk, and talk about the possible costs and available mitigations. That is definitely something executives will understand.

What about if you are mired in technical debt, of any or all kinds?

The first thing to do is to quite literally survey the landscape, to work out where your biggest pain points and opportunities are. At EPSD, we’ve seen anonymous surveys work here. Getting an aggregated view across all engineering teams can show you common challenges and frustrations. Once you have this overview, you can start to talk in terms of what these particular problems are costing the business.

If you can show that shipping that feature to deadline is adding $35K monthly to the customer support bill, it’s likely to be easier to get the sign-off on another iteration to deal with the worst issues.