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 demystefying the whole idea of technical debt.
Tech debt, is changed assumptions, that can turn into decay
Defining tech debt is a hard excercise as the term has been misused so much. Just like other ubiquitous industry terms like architecture and agile. The term technical debt has been so violently overused it has become so vague it has seized being useful.
But since writing code requires making assumptions, assumptions about code change over time, the delta in assumptions is technical debt. Building on that definition, we can add that if those changed assumptions risk reducing velocity, then it is technical debt.
In order 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 dont scale can be healthy when short lived and is there 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.
You 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 stary 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.
The solution
By giving the tech lead full discretion to allocate the capacity of a set percentage of time for the team to prioritize and spend time on the most important techincal 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 allocation of 15% per sprint needs to have 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.