Technical debt: how to talk about it with non-technical leadership
Why technical debt is not just a technical problem, and how to discuss it with boards and owners in a way that leads to decisions rather than defensiveness.
Technical debt is one of the hardest topics to communicate from a CTO or IT director to a board or business owners. Technical people understand what is meant. Non-technical executives hear either "we need more money for development" or "your developers did poor work before." Neither interpretation leads to good decisions.
I want to suggest a way of talking about this that helps make decisions rather than creating a defensive conversation.
What technical debt actually is
The debt metaphor is precise. When you take a loan, you get money now in exchange for a commitment to return more later. When a company makes technical decisions for speed - "let's do it quickly now, we'll do it properly later" - it takes on technical credit. The problem is that "later" often never arrives, while debt service runs continuously: in the form of slowed development, more frequent failures, and difficulty integrating new things.
Important point: technical debt is not always the result of poor work. Sometimes it is the result of correct decisions at the time. A startup that got to market quickly with an MVP made the right decision. That same company five years later, still running on that MVP without refactoring, pays for it every day.
What debt looks like in business terms
Instead of technical explanations, translate into business consequences:
Development speed. A team of ten developers ships one feature every three weeks. Two years ago, the same team shipped three features a month. The difference is the cost of debt service. The developers did not all suddenly get worse.
Cost of change. Adding a new payment type takes two months because payment logic is embedded in fifteen different places. Every change requires changes everywhere.
Risk of failures. The number of production incidents per quarter, their resolution time, the cost of downtime - these are measurable numbers that are often directly linked to accumulated debt.
People dependency. If a system is understood only by two specific individuals, the company carries the constant risk of their departure. That is also debt.
Three types of debt and different responses
Not all technical debt is the same. There are three fundamentally different situations:
System growth outpaced the architecture. The system was designed for load X and now runs at 100X. Response: methodical incremental work, embedded in the normal development process.
Accumulated obsolete technology. A 2010 framework with no support, a platform that is hard to hire for. Response: a prioritised migration plan with time horizons.
Fast decisions made the code unreadable. Without understanding what the code does, any change is risky. Response: regular improvement work - not "stop everything and rewrite", but keeping the debt at a manageable level.
How to turn this into decisions
The question for leadership is not "how do we eliminate technical debt" but "what level of debt are we prepared to service and which parts are most risky right now."
Specific questions for a conversation with the IT team:
- Which parts of the system slow down development most - in measurable terms?
- Where is the greatest failure risk concentrated right now?
- Which components make the company dependent on specific individuals?
- What needs to change to make next year faster than this year?
- What percentage of engineering time actually goes to debt service - and what is the target?
Technical debt is a manageable reality, not a sword hanging overhead. Companies that talk about it honestly and regularly manage it. Companies that ignore it pay an unpredictable price.