The landscape
There are many types of debt org debt, process debt, management debt, the whole idea is that some form of decay has happened, either deliberately or accidentally, and you must invest in order to get rid of it, otherwise you will incrementally lose the ability to generate value.
In this article we cover how to elegantly and implicitly handle technical debt in your organization. Removing the need to debate the definition internally, have special meetings to handle technical debt, and demystifying the whole idea of technical debt.
Tech debt is changed assumptions, that can turn into decay
Defining tech debt is a hard exercise as the term has been misused so much, just like other ubiquitous industry terms like architecture and agile. The term technical debt has been violently overused it has become so vague it has ceased being useful.
Definition of technical debt: Since writing code requires making assumptions and assumptions about code changes over time, the delta between initial assumptions and current assumptions is technical debt. Building on that definition, we can add that if those changed assumptions risk reducing velocity, then that technical debt has an interest rate. For example that each new change must work around the outdated assumption, so the cost grows over time
To use the term, we also need to definitively describe what tech debt is not, and what it is.
| What is not technical debt | What is technical debt |
|---|---|
| Working code that looks ugly or uses an older programming style that a new hire dislikes. | Core workflows that lack automated test coverage, turning every release into manual QA roulette. |
| A framework that is one major version behind but receives security patches and performs reliably. | Architectural coupling that forces three teams to coordinate deployments for a single button change. |
| Features or scale the business might need two years from now (that is missing future-proofing, not debt). | Hardcoded business logic reflecting pricing models or constraints abandoned two years ago. |
| Outright defects or bugs in active feature logic (those are defects, not architectural debt). | Brittle, slow build pipelines that waste 45 minutes of developer time per pull request. |
Tech debt is similar to real debt
Technical debt is just like financial borrowing, not all debt is inherently reckless, but every loan carries an interest rate, repayment terms, and the non-negotiable requirement of making payments. The danger lies in failing to recognize which kind of debt you are taking on:
Low-interest debt
Deliberate, phased architectural compromises designed to hit a critical company milestone or capture an urgent market opportunity. You know you owe it, the risk profile is well-understood, and you have a realistic plan to service the balance over time.
High-interest debt
Fast, tactical shortcuts, such as intentionally doing things that don't scale, can be healthy when they are short-lived and exist to quickly validate a product hypothesis. It buys velocity, but carrying a balance from cycle to cycle or even worse, continually increasing it, causes interest to compound rapidly.
Pay the debt, or suffer decay
In finance, the fastest way to go bankrupt is to just stop making payments entirely. In tech, rot from the foundation will engulf and kill both your ability to innovate and team happiness.
We need to stop living in the two fantasies:
- That we just need to plan things better and build things perfectly the first time, and have it stay right forever.
- That tech debt does not carry a compounding interest rate, and can be handled "later".
Compounding interest doesn't wait. If you skip your monthly minimum payment, the interest is immediately compounded onto the principal. If you don't continually service tech debt as you go, by the time you finally dedicate time to it, all you end up making a dent in is the accumulated interest.
Give the tech lead a fixed, use-it-or-lose-it budget for tech debt
Give the tech lead full discretion over a set percentage of the team's time to spend on the most important technical debt.
It solves three problems:
- Eliminates engineering using "tech debt" as a vague catch-all excuse for slow delivery.
- Forces engineers to develop commercial discipline: once they own the budget, they have to decide what actually matters rather than demanding an unrealistic rewrite.
- When the wrong debt is prioritized, the accountability for a systems failure and the ownership around that problem space is actually clear.
The product or team lead should agree with the tech lead on a set percent, this is a collaborative effort, and should never be over 15% per sprint. If you have a huge amount of debt to be paid off, keeping it higher until it gets paid down is a good idea on the short term. This percentage is a strict use it or lose it expiration. This prevents capacity hoarding and guarantees product managers a stable, reliable cadence of feature delivery every cycle.
Consequence of prioritizing the wrong debt
Autonomy without accountability is indulgence; accountability without autonomy is micromanagement.
Giving the tech lead full autonomy over this budget means that they own the operational outcome of their choice.
If a tech lead spends three months of debt allocation migrating to a trendy new build tool for marginal DevEx gains while ignoring degraded database performance, the consequence is standing in front of the organization during the post-mortem when production collapses under peak load, explaining why vanity refactoring took priority over systemic stability.
True autonomy requires living with the blast radius of your decisions. Do not infantilize engineers by shielding them from that trade-off.