How I Decide Which Technical Debt to Fix

Early in my management career, I treated the list of engineering complaints as a backlog and worked through it in order. The ugliest module got a refactor, then the next ugliest, and I felt productive every week. Two years in, I noticed something uncomfortable: the code looked cleaner, the incident count had not moved, and the systems that kept me up at night were exactly the ones nobody had complained about, because nobody touched them.

I have spent 25 years in infrastructure, from Windows servers and Cisco data centers to large banks, and both seats taught me the same lesson. Debt has a principal, which is what it costs to fix, and an interest rate, which is what it costs to leave alone. Some debt carries brutal interest. Some costs almost nothing, because we will never enter that corner of the system again. A sensible person does not repay every loan the moment they can. They repay the expensive ones first and leave the ones with an effective rate of zero alone.

When a piece of debt lands on my desk, I score five factors. Low, medium, or high is usually precise enough; anything finer is false confidence. The goal is a consistent conversation, not a spreadsheet.

The first question I ask about any debt is what happens if we leave it exactly as it is for another year. Most debt answers with nothing much. Some answers with an outage. The second kind goes to the top of the list, even when the code itself is not particularly painful day to day. Operational risk outranks every other factor because the cost of failure is the largest, and because it is the factor engineers are least positioned to see: they feel the debt they work in, not the debt that sleeps.

Security debt gets separated from the stack because it does not follow normal cost-benefit behavior. A messy module might stay messy for years and cost nothing. A known vulnerability gets cheaper to exploit every year, and someone is out there looking for it. The downside is asymmetric: the cost of a breach dwarfs almost any remediation effort, so the usual question of whether the work is worth it answers itself.

That does not mean panic-patching everything a scanner prints. Triage is the job. The same critical CVE is a different problem in an internet-facing component than in an isolated internal tool nobody can reach. Exposure and exploitability matter more than the label, and severity ratings are the beginning of the conversation, not the end of it.

In a regulated enterprise, some of this debt is not really optional. End-of-life software inside an audited scope is an audit finding waiting for a date, and findings arrive with remediation deadlines we do not control. Where we cannot fix immediately, I formalize the exception: compensating controls, a named owner, and an expiry date. Banks already have the machinery for this in their risk registers, and a documented exception is the difference between a governed decision and a surprise. I cover how to present these cases in the language auditors and executives already use in my guide to explaining engineering trade-offs to executives.

Some debt never causes an outage and never shows up in a scan. It just makes everything slower. Slow pipelines, flaky tests, environments that drift apart, the module where a small change breaks three distant things. The cost is distributed across hundreds of small daily moments, so no single incident justifies action. The sum does. If a team loses thirty minutes a day to tooling friction, that is real engineer-weeks per quarter, spent on nothing anyone would put in a status report.

I measure friction the boring way. During planning I ask how much longer tickets in this area took because of this code, and how confident people are that a change will not break something else. When engineers consistently estimate thirty to fifty percent overhead in one module, that is a tax on every feature that touches it, and it compounds quietly, because it slows down the fixes too.

This is where I think about leverage. Debt work that speeds up every future delivery can out-earn a feature project, which is not a sentence engineers are usually allowed to say in planning. The numbers make it sayable: time per release, incident rate, cycle time. When the case is framed as capacity bought back per month, it competes for budget like anything else, and the evidence comes from the same delivery metrics I use to measure engineering team performance.

Some systems are expensive even when nothing is happening. A deprecated runtime we special-case in the infrastructure. A database that needs a human to babysit migrations. A service nobody can safely modify, so every incident drags in the one person who understands it. This cost shows up as toil, and toil is invisible in any plan, because it disguises itself as normal work.

Every enhancement takes longer. Every incident takes longer. Every onboarding takes longer. I have inherited systems where a one-line change needed weeks of analysis, and the team had normalized that as simply how the system is. Naming the cost is simple and effective: roughly one engineer-day per week of toil and incident response is a much stronger sentence in any budget conversation than the code is messy, and it converts cleanly when I translate it for executives.

The factor most teams skip is often the deciding one. Cost alone does not set priority. Cost multiplied by the likelihood we will need to change the system does. Debt on a road we travel every week gets repaid almost as a side effect of normal work. Debt in a quiet corner costs nothing, sometimes for years. It is a messy room we never enter.

Consider two systems with equally tangled internals. System A sits on the critical path of next quarter’s roadmap, changes weekly, and grows with the product. System B is a batch pipeline that has not changed in two years and is scheduled for retirement next quarter. Same ugliness, opposite decisions. I would clean up A and refuse to spend an hour on B, not because B is less ugly, but because we are about to stop paying interest on it permanently.

I run the check explicitly against change history: git, tickets, incidents, and the roadmap. The corollary is the roadmap gate. Before we commit next quarter’s plan, I check it against the debt register. If the plan walks straight through the most debt-laden module we own, that is not a discovery for week six. It is the trigger to fix or fund around the debt before the features land. Roadmaps and debt strategy are the same plan seen from two angles.

After scoring, every item lands in one of three buckets. The buckets matter less than the honesty of the reasoning, so each one comes with its own discipline.

None of this needs heavy process. The goal is better decisions, not more ceremony. What holds it together is asking for debt in a particular language, then running the same small loop every time.

The last step is the one managers skip, and it is the one that keeps the system credible. Silence reads as dismissal, and dismissal turns the next genuine warning into a complaint nobody believes. A one-page inventory of the important open debt items, reviewed quarterly, is enough to carry all of this. I resist turning it into more than that, because the ceremony is where these systems go to die.

Here is how three typical items land in one quarter. The examples are composites; the shapes are real.

Engineers who point at debt are usually right about the problem and sometimes wrong about the priority. Both halves deserve respect, because the pushback is where most managers either lose trust or build it. The scoring has to survive disagreement, not avoid it.