A useful metaphor, taken seriously
Technical debt is the term for the gap between how a piece of software is actually built and how it would be built if there had been no time pressure, no shifting requirements, and perfect hindsight. Every real system has some. The phrase is borrowed from finance, and the borrowing is more exact than it first appears.
Some technical debt is deliberate. A team takes a known shortcut to hit a deadline, fully aware it is a shortcut, because shipping on time is worth more than shipping perfectly. That is a reasonable, even shrewd, decision, the software equivalent of taking a loan to seize an opportunity.
Other debt is incidental. A design that was perfectly sensible three years ago slowly stops fitting as the product grows in directions nobody predicted. Nobody made a bad call; the world simply moved. Either way, the financial metaphor holds, and it holds in a specific way: debt itself is not the problem. Borrowing to move faster is often correct. The danger is debt that is never tracked and never deliberately repaid.
The interest rate is real
The cost of technical debt is paid the way interest is paid: a recurring tax on every future change made anywhere near it. In a part of the system carrying heavy debt, every new feature takes longer to build than it should. Every change risks breaking something unrelated, because the parts are tangled together. Every estimate carries more uncertainty, because no one is quite sure what a change will disturb.
This is why a business can feel its software growing harder to change without anything ever visibly breaking. The product still works. Customers still use it. But altering it costs steadily more in time, in risk, and in nerve than it used to, and because new work is built on top of the shaky foundations, the interest does not stay flat. It compounds.
Why it stays invisible until it is expensive
Technical debt has a peculiar and dangerous quality: it is almost completely invisible. It does not appear on a balance sheet. It is not a line in the budget, an item on the roadmap, or a number on a dashboard. There is no monthly statement that arrives to remind anyone it exists.
It surfaces only indirectly, in symptoms that are easy to attribute to something else. Features that take surprisingly long for what they are. Bugs that keep clustering in the same few areas of the product. Experienced engineers who go quiet, or visibly tense, when asked to change a particular part of the system.
Because it is invisible, technical debt loses almost every prioritization argument it is entered into. A new feature has an obvious champion, a clear benefit, and someone who wants it. Paying down debt has none of those; its benefit is the absence of future pain, which is hard to put in a slide. So it is deferred, again and again, and the interest keeps quietly accruing, until the system is finally slow enough to change that the business cannot ignore it any longer.
Not all debt is the same
Treating technical debt as one undifferentiated mass leads to bad decisions, because not all of it is worth repaying. Debt in a part of the system that almost never changes is like a loan on an asset nobody touches: technically owed, but costing very little, because the interest is only charged when that code is worked on. Rewriting it can be pure waste.
Debt in the parts of the system that change constantly is the opposite. That is where the interest rate is genuinely high, because the tax is paid on every single change, and changes are frequent. The useful question is therefore never just how much debt exists, but where it sits relative to where the work happens. High-interest debt in a busy area deserves urgent attention; low-interest debt in a quiet corner can often be left exactly where it is.
The cost of never paying it down
Left entirely unmanaged, technical debt eventually reaches a point where it stops being a tax and starts being the main event. New work slows to a crawl. Good engineers, who can feel the friction every day, grow frustrated and leave for somewhere the work is less painful, taking their knowledge of the system with them. And the business starts seriously discussing a full rewrite, the most expensive and most dangerous option on the table, and very often itself the eventual result of debt that was ignored for too long.
The opposite extreme is also a real mistake, and worth naming. A team that becomes obsessed with perfectly clean code, that refuses to ever take a shortcut, ships too slowly to compete and loses for a different reason. The goal was never zero debt. Zero debt is its own form of waste. The goal is debt that is known, chosen on purpose, and actively serviced.
Managing it like the liability it is
Managing technical debt well is unglamorous and entirely achievable. It means making the debt visible: keeping a plain record of where the significant debt is and roughly what it costs, so it stops being folklore and becomes something a team can point at. It means factoring that cost into estimates honestly, so that work in a debt-heavy area is not mysteriously, repeatedly late. And it means steadily allocating a portion of capacity, not a heroic quarter-long project, but a routine slice, to repaying the highest-interest debt in the busiest areas.
The aim is steady servicing rather than dramatic rescue. A modest, continuous investment in the parts of the system that change most often keeps software cheap to change, and software that is cheap to change is the entire reason the asset is valuable in the first place. Carrying some debt is fine, and often smart. Pretending it is free is the habit that eventually becomes very, very expensive.