Technical debt as a management concept
How to think about technical debt not as engineers complaining, but as a real asset with interest payments - and what to do about it.
"Technical debt" is a term engineers use in conversations with management and often do not get the reaction they hoped for. The manager hears something abstract about code quality. The engineer means accumulated decisions that slow down every new thing - and that pattern shows up as clearly in data pipelines as in application code.
The debt metaphor is more precise than it seems. And when you understand it correctly, it changes the conversation.
What it actually is
Technical debt is the accumulation of technical decisions that were made quickly or cheaply in the past, but which now require extra effort every time the system needs to change.
The examples are mundane: code written so that adding one feature requires changes in ten places; data stored without structure so that every analyst exports it differently; integrations built as point-to-point connections so that no change can be made without breaking something nearby.
This is not abstract. These are specific things that can be listed, prioritised, and measured in units of slowdown - how much longer development takes because of each one.
Why the debt metaphor works
Debt has principal and interest. Technical debt works the same way.
The principal is the work that needs to be done to "pay off" the debt: rewrite the component, unify the integration, clean up the data.
The interest is the extra cost the company pays every time it works with that part of the system. Every new release costs more, every incident takes longer to resolve, every new developer takes longer to get up to speed.
Some debt is taken on deliberately. "We need to ship by the deadline - we'll deal with it later" is an explicit decision to borrow. The problem arises when "later" never comes and the interest keeps accumulating.
How this affects decisions
Managers are often surprised that development slows down even though the team is the same size or larger. Accumulated technical debt is one of the main reasons.
When debt is significant, every new feature takes longer than the last. Fixing one bug creates two others. Estimates are missed not because the team works poorly, but because the real complexity of the tasks is higher than it appears from the outside.
Ignoring this means making decisions about development speed without a full picture.
What to do practically
The first step is to make the debt visible. Ask the team to list specific items of technical debt with an estimate of their impact. This is not a complaint - it is a risk inventory.
The second step is to understand the cost. How much time is spent each month working around each problem? Multiply by the developer rate - that is an approximate cost in money.
The third step is to make an explicit decision. Fully ignoring debt or paying it all off at once are both wrong extremes. The normal practice is to allocate a portion of team capacity to debt work on a consistent basis. The commonly cited figure is ten to twenty percent of sprint time.
The fourth step is to connect debt decisions to business priorities. Not "let's rewrite this module because it is ugly", but "this component sits on the path of three key initiatives next quarter - it is worth fixing before we start."
Technical debt is a management decision, even when the manager does not know it is being made. What technical debt means specifically for non-technical founders - and how to have a productive conversation about it with the board - is a separate problem that starts with the right framing.