I've mentioned my approach to technical debt often, but I've never actually written it down. Here's the framework I use.
Technical debt is most typically brought up from individual engineers or the engineering department. If not attended to, technical debt can slow down future product development and reduce the developer experience.
To me, technical debt is simply technical work we choose to postpone, focusing on something that currently has higher priority.
I am not going to get into why it is bad, but how it is created and what you might do to reduce it.
The following is the model I use to split technical debt into three classes.
On the smallest scale it is in the individual work, where shortcuts are taken
Medium scale is the project / product level, where product work take priority over technical work
The biggest level are migrations, for example version upgrades to systems
Smallest Scale: Individual Level
Make quality part of every story.
This is the easiest to address by the engineers, as it is fully in their hands.
They might decide to take a shortcut, by writing fewer tests, not spending time on refactoring, or ignoring agreements about code style or quality.
This could be due to pressure from the product side, or sometimes from taking the path of least resistance, or from wanting to focus purely on functionality.
If the pressure comes from the product side, make sure that the time required for proper testing, refactoring, and code quality is included in the feature estimate. This isn’t extra work — it’s part of delivering the feature itself.
You need a team agreement about the minimum quality that is expected, and then it is part of each task.
You don’t create extra tasks for this, you don’t reserve extra time, you don’t add it to the task specification, instead it is included in the feature work.
At the same time, the team has to hold everybody responsible for this.
If the team isn't holding people accountable, no one gets to complain about quality later.
Medium Scale: Project Level
Agree as a team when to defer, and track it explicitly.
At the project level — whether you call it an initiative, epic, cycle, or sprint — technical debt often appears when product delivery takes priority over internal improvements.
If you work in an agile environment, you want to deliver iteratively to the user as fast as possible. On the product side, it might be an MVP, or individual experiments.
The faster you learn, the faster you can decide if further investment is worthwhile
In this case, it might be valuable to delay technical investment to a later part of the project. You would create separate tasks to work on once the results of the experiments are clear.
This requires trust in the product planning process. If these tasks consistently end up in the forever backlog, the team will stop agreeing to defer them.
Big Scale: System Level
Plan migrations early, budget them like real projects.
System-level debt typically builds up quietly over time. A few examples:
A large system, like a database, needs an upgrade
One of the libraries or frameworks in use deprecates the version you are using
A dependency of your system is abandoned
You need to change a third-party system because of a change in costs
You inherit a system that has different quality standards as yours
All of these will require not only operational work, but also changes to existing systems, and code bases.
These will be large migrations, that often require multiple people, a team, or even teams to work on them.
They have to be handled as proper projects and will take time that would normally be reserved for feature projects.
In most cases, they will just cost money and not bring any new one in. Occasionally, they can even save money, especially if the new system brings performance improvements you can leverage.
This makes it often difficult to justify the work.
On the positive side, they are typically not urgent. For most of these, you will know about the changes in version or support very early. You can plan them well in advance.
The key is to treat these migrations as part of your long-term product strategy — planned, visible, and funded like any other project.
Summary
No matter the scale, managing technical debt is about conscious trade-offs and shared accountability. What matters most is that these decisions are made transparently, understood by everyone involved, and revisited regularly.
What doesn’t work is pretending technical debt doesn’t exist, or treating it as purely an engineering problem. It’s a product and business decision as much as a technical one.
And there will always be some technical debt, it is just important to make sure that it has the lowest impact on future development.
