Technical debt: how to talk about it with your team and make decisions

Technical debt is a phrase developers use when they want to rewrite something, and founders hear as "we need money for something unclear". Between these two positions there is a gap that rarely gets closed.

I have seen both sides of this conversation enough times to have a view on why it does not work - and how to fix it.

Why the technical debt conversation does not work

Developers talk about technical debt in terms only they understand: "monolith", "spaghetti code", "outdated dependencies". For a non-technical manager, this sounds like a problem description without an understandable consequence.

Founders, in turn, treat technical debt as something abstract - until it appears as a concrete outage, a slow release, or the inability to add a feature. By that point the cost of fixing it has grown.

The problem is not that anyone is wrong. The problem is that the conversation is being held in two different languages.

A language that works

Technical debt makes sense when described in terms of business consequences rather than architectural problems.

Instead of "we have legacy architecture" - "any new change takes three times as long as it should, and every other change breaks something else".

Instead of "we have no tests" - "we cannot ship updates more than once a month, because there is no way to verify nothing broke without several days of manual testing".

Instead of "we have a monolith" - "adding a new development team does not speed up delivery, because everyone modifies the same piece of code".

This is not a simplification - it is a translation of a technical fact into a business consequence.

How to make decisions about technical debt

Not all technical debt is equally critical. A useful classification:

The first class - debt that is actively slowing down current work. This is a priority.

The second class - debt that creates risk: security, reliability, compliance. This is also a priority, but of a different kind.

The third class - debt that is theoretically bad but practically not blocking anything right now. This can be deferred.

The manager's job is to make sure the team draws these distinctions explicitly and does not lump everything into one category labelled "we need to refactor".

Practical questions

When developers raise technical debt, it is worth asking:

• What is concretely happening right now because of this debt? Slow releases, frequent bugs, inability to implement a specific feature?
• What will happen if we do not address this in the next three months? Nothing, things will get worse, or will it block something specific?
• What is the minimum amount of work that removes the main pain?
• How will we know the problem is solved?

These questions do not challenge the team's competence. They move the conversation from the plane of technical preferences to the plane of management decisions.