Most executives hear about technical debt the way they hear about deferred maintenance on a building: at the moment it becomes an emergency. This is a playbook for handling it before that, written for the person who owns the budget rather than the person who writes the code.
Make it visible
You cannot manage what nobody has written down. The first step is a list.
Ask your team, or your firm, for a written inventory of the shortcuts in the system: what was skipped, why, and what it costs. Not a technical document, a business one. Each item should answer three questions in plain language: what happens if we leave this alone, what does it cost to fix, and what does fixing it unlock. If nobody can produce that list, that is the first finding. An independent System Evaluation produces it in one to four weeks for a system you did not build or do not understand.
Keep the list alive. Every time a shortcut is taken on purpose, it goes on the list with a reason and a trigger for revisiting it. Debt that is chosen and recorded is a business decision. Debt that is discovered is a liability.
Decide how much of every release goes to the foundation
The number we plan against is a share of each cycle, not a separate project. On a healthy system it is small: enough to keep dependencies current, add tests where they are missing, and clean up the piece of code the team touched this week. On a system carrying a lot of debt, it is larger for a while, and it is still paid from every release rather than saved for a big repayment that never comes.
The way to hold a team to it without becoming an engineer is to ask one question in the weekly review: what did we pay down this cycle? If the answer is nothing three weeks running, the foundation is being traded for features, and you will pay for it later at a worse rate.
Fix in this order
Not all debt is worth paying. Prioritize by what it is costing you and what it blocks.
- Anything that threatens continuity. Single-person knowledge, no source control, credentials in the code, no backups. These are not technical debt so much as unexploded risk, and they come first regardless of what else is on the list.
- Whatever slows every change. The tangled module everyone touches, the missing tests that make each release a gamble, the manual deploy. Fixing these pays back on every future feature.
- Whatever blocks the next thing you want to build. If the integration you need is impossible because of a decision made three years ago, that decision is now on the schedule.
- Everything else, as you touch it. Code that works and that nobody needs to change can carry its debt indefinitely. Fix it when you are in there for another reason.
Leave alone the debt in parts of the system that are stable, rarely changed, and scheduled for replacement. Paying it down is waste.
Where AI fits
AI coding tools are good at some of this work and dangerous at the rest. They are useful for writing tests against existing behavior, for explaining code nobody understands, and for the mechanical parts of a refactor. They are not a substitute for the judgment about what to fix, and a tool that refactors without tests and review can create more debt than it retires. Senior engineers direct the work and review all of it. That is not a slogan. It is the difference between a system that gets healthier and one that gets larger.
What it looks like when it is working
- Estimates get more accurate, because the team knows the system.
- Bugs stop recurring, because the fix addressed the cause.
- New people become productive in weeks.
- The list of debt gets shorter, and the items on it are choices rather than surprises.
- Nobody says “we need to rewrite it.”
If you are already behind
Most companies reading this are. The instinct is a rewrite, and it is usually the wrong one. Modernizing in slices behind the running system, paying down the debt that matters while the business keeps operating, is slower on paper and faster in practice, because it does not stop everything for a year and it does not gamble the company on a big-bang launch. When your custom software stops working for you covers that approach. Technical debt in the AI era covers why the problem is arriving faster than it used to.
The first step is the same either way: find out what you are carrying. Here is how getting started works.