The technical debt remediation cost line item in any technical diligence report is problematic on several fronts. It’s the blue-book value of all technical debt remediation without nuance. Often without prioritization. Sometimes it includes things that aren’t technical debt at all.

The term is the defect

At some point, I started asking my engineers to define “technical debt” for me, and to nobody’s surprise, almost everybody makes an answer up on the spot. I’ve heard them all. “Libraries that are past end of life” or “code written in a way that makes maintaining it difficult” or “code shortcuts to get to market”. In aggregate, what they mean is “Longstanding, unfixed things”; what investors hear is “debt,” and they think “financial debt.” The history of the word started out meaning “shortcuts to ship now instead of waiting until we know everything we need to know,” but has mutated so much since then I vote we throw it out and start over.

It is not like financial debt

The name aside, discovering and estimating technical debt isn’t a science. Creating a technical debt register isn’t like creating a QoE report where a team reviews largely hard data and removes anomalies to get to a defensible base number; these are estimates built on gut feel. Commercial and financial diligence are more rigorous because their inputs are auditable.

For any type of debt, there’s a borrower and a lender. The borrower holds a liability, and the lender holds an asset. If a business causes an engineering team to take shortcuts (product prioritization, short staffing, lack of investment), the business caused the technical debt, meaning it’s the borrower. The business has a liability; Engineering has an asset.

Engineering is owed that debt

Then the question becomes “How much?” and the answer is “we don’t know; we have to ask.” Because the truth is, nobody knows, and it’s not knowable until it’s researched and summed up. So, who is asked to find the amount of debt owed? The only group that is qualified to know it: Engineering.

This creates an asymmetric situation that doesn’t exist in financial transactions: the people owed the debt are the only ones who can decide how much is owed.

More feels better

The debt sizing task incentivizes engineering to collect everything possible to stuff into that number, and they will. It’s natural, not greed. They look around at all the things that have been nagging at them for years and collect them into a list, maybe for the first time ever, and it feels good. Engineers like to be productive. Squashing all that work and having a budget for it feels like progress, freedom even.

Engineers seek chaos and leave order. It’s innate. It’s what they were born to do. Unremediated technical debt is a job left undone and a persistent, nagging cognitive load that can eat its way through an engineering organization.

“You’re asking me to add that up so we can quantify its remediation? We thought you’d never ask!”

With a sizable budget possible, the potential to crush technical debt feels GOOD. So they dig around, add what they can find and remember.

Then a technical diligence consultant prices that, padded with a contingency.

A note on zero tech debt

You never want to have zero tech debt. Zero technical debt is like zero body fat: impossible, and if you try, you are optimizing for the number, not the outcome. A business that claims it has no technical debt feels suspicious. If it is actually true, which is rare, it signals that it doesn’t innovate or can’t because it’s run out of ideas.

Isolate technical debt by defining it

Technical debt is a hot-button word in any diligence report. Regardless of my ranting about how technical debt is not financial debt, deal partners will forever have a visceral reaction to it. An explosive term like that should be used carefully. With the ambiguity around what technical debt means, and its explosive nature, there is an opportunity to define it clearly internally and disclose that when asked. Do so by introducing a sister term, “deferred maintenance,” like so:

• Deferred maintenance: Known maintenance, upgrades, patching, replacement, or lifecycle work that has not yet been performed, but whose remediation path is reasonably understood.
• Technical debt: A past technology decision or shortcut that makes future change more difficult, expensive, risky, or slow than it otherwise would be.

Or even simpler:

• Deferred maintenance has a known remediation path: We know how to fix these things; we can likely even outsource them because they are a common problem many companies have.
• Technical debt requires engineering discovery: To understand the problem, we’ll need a deep dive, and engineers who know the system are preferred because this is a problem only we have.

The estimate and potentially even the final price of those two things may be the same, but the second one is much riskier. Knowing the difference and documenting them this way adds value and isolates risk in a way a buyer would find reassuring.

The specific buyer matters

Know what’s included and excluded in the technical debt findings through a single lens: what a specific buyer of the exact business will care about. Not what “buyers” will care about, but what the right buyer will care about. There’s nuance here. Here are a couple of generic examples:

• Strategic: If a strategic buyer approaches, they may not care about remediating technical debt at all. They may be replacing that functionality anyway. The register prioritizes likely redundancies so they can be struck out in one go. The remaining items are estimated in dollars, not hours.
• Platform: If a fund looking to acquire a platform approaches, the technical debt register is prioritized by how likely each item is to constrain growth. In this case, the remaining items are put into tranches and are estimated in dollars to remediate.

In both of those cases, some technical debt remediation will get deprioritized. If you forged ahead and remediated all of it because it was on a list, you would have wasted money and time fixing ‘nice-to-haves’ for purity instead of returns at exit. Include a cost, in dollars, to control that narrative.

Mastery over the size and cost to remediate technical debt puts you in the driver’s seat here.

Decide and document the ideal buyer persona; think through what they care about, likely identified in their investment thesis. Reiterate that to the team, framing a potential acquirer’s mindset and what they care about from a tech perspective. With that in mind, list what they will want fixed. Then section off deferred maintenance and price what’s left in terms of time and budget.

Now, a technical debt cost that is appropriately sized, priced, and prioritized will anchor the discussion on your terms.