By: Marley Peters
When private equity firms conduct technical due diligence, they typically arrive with a checklist. How old is the codebase? How extensive is the backlog? What will it cost to modernize? The underlying assumption is that technical debt is a liability. It’s a number to be negotiated down, a problem to be cleaned up, a signal of organizational dysfunction.
Chief Data and Engineering Officer Michael Privat thinks that entirely misses the point.
“Tech debt isn’t just rot,” says Privat, a longtime engineering executive with decades of experience leading large-scale technology organizations. “It’s a fossil record.”
It is an unconventional take, and a strategically important one. While the industry grapples with the staggering scale of accumulated technical debt, the cost of poor software quality runs to $2.41 trillion annually in the US alone, with accumulated technical debt sitting at roughly $1.52 trillion, according to Accenture. Most executive conversations remain fixated on remediation costs. But Privat is more interested in what the debt reveals. And boy, can it reveal.
The Archaeology of Decision-Making
Privat’s framework begins with a deceptively simple premise: every architectural shortcut, every deferred migration, every system that should have been retired three product cycles ago is a data point. Not about code quality, but rather about organizational behavior.
“When investors walk into diligence, they often treat tech debt like a number on the balance sheet,” he explains. “But if you look closely, it actually tells you how the company has been making decisions.”
A monolithic architecture that was never decomposed might speak to a leadership culture that avoided disruption. A tangle of loosely connected platforms could be the footprint of an aggressive acquisition strategy that outpaced integration capacity. A brittle internal tool quietly keeping a revenue-critical process alive may point to years of engineering concerns being subordinated to short-term deadlines. What a museum.
“The systems tell you what the organization was afraid to change,” Privat says.
For M&A practitioners, this lens has tangible value. Technical debt is a historical record of how the company prioritized under pressure. And that pattern of prioritization, more than any polished investor presentation, tends to predict how leadership will behave going forward.
The Hidden Tax on Innovation
The operational consequences of unmanaged debt are well-documented, if still widely underestimated. According to McKinsey, technical debt accounts for approximately 40 percent of IT balance sheets at the average enterprise, a silent drag that compounds over time. The compounding effect is what makes the problem particularly dangerous. Features take longer to ship. Infrastructure becomes brittle. Developer morale erodes amid real downstream consequences, given that 62 percent of developers cited technical debt as their greatest source of frustration at work, according to the 2024 Stack Overflow Developer Survey. No amount of pizza parties can fix that.
“By the time companies start asking why everything is taking longer, the problem is already deeply embedded in the system,” Privat says. “Leadership experiences it as a sudden slowdown. The engineering team has been watching it build for years.”
The downstream impact on strategic capability is significant. Organizations carrying heavy technical debt are slower and increasingly unable to participate in the technology investments that will define competitive positioning tomorrow.
Kill the Factory, Not Just the Debt
The conventional response to a technical debt problem is a modernization initiative. Engineering teams are tasked with refactoring legacy systems. Budgets are allocated. Leadership announces the organization is “paying down the debt.”
Privat is measured in his assessment of these efforts.
“In my organization, engineers are responsible for removing technical debt,” he explains. “But my job is different. My job is to understand what produced that debt in the first place.”
The distinction matters enormously. Modernization efforts address symptoms. They improve specific systems, reduce maintenance costs, and, when executed well, can restore engineering velocity. But if the incentive structures, ownership gaps, and decision patterns that generated the debt remain unchanged, the same dynamics will reproduce themselves in the new architecture within a few years. Simply put, ignoring the history can be like slapping a Band-Aid on a gaping wound.
“You have to kill the debt,” Privat says. “But you also have to kill the factory that produced it.”
In most organizations, that factory is a system of misaligned incentives. Product teams rewarded purely for feature velocity will take shortcuts. Architecture decisions without clear ownership will drift. Engineering concerns consistently overruled by quarterly deadlines will compound into structural fragility. Technical debt, in this view, is less an engineering problem than a management one, feedback rendered in code, about how an organization actually operates.
A Counterintuitive Signal
There is a counterintuitive corollary to Privat’s framework that surprises some executives upon first encountering it. The complete absence of technical debt is not, in his view, necessarily a sign of organizational health. Absence is not evidence of greatness.
“In fast-moving markets, some technical debt is actually evidence that the company is making bets,” he says. Ward Cunningham, the software engineer who coined the term “technical debt,” made essentially the same observation: a little debt speeds development, provided it is repaid promptly.
Companies that have never incurred technical debt may simply not have moved fast enough to accumulate any, or worse, the software they can produce doesn’t stand the test of time, and they keep restarting from scratch. The question is not whether an organization carries debt, virtually all of them do, and global technical debt has roughly doubled since 2012, according to Oliver Wyman, but whether leadership understands why it exists and has a credible plan for managing it.
“The difference between strong engineering organizations and struggling ones isn’t whether technical debt exists,” Privat says. “It’s whether leadership understands why it exists.”
Reading the Record
For executives who want to apply this diagnostic lens to their own organizations, Privat recommends beginning with a pointed question: which parts of the system do engineers avoid touching?
The answer almost always identifies where the most consequential tradeoffs were made. From there, the exercise is to trace those systems back to the moment they were built and ask what pressure, what deadline, or what strategic priority demanded speed over structure.
The patterns that emerge are rarely about engineering. They are about leadership, incentives, and organizational culture. And once those patterns are visible, leaders can begin addressing the real issue, not just the code that reflects it.
In a market where technical debt costs US enterprises trillions of dollars annually and constrains the AI ambitions of a generation of would-be digital leaders, the ability to read those signals accurately may be among the most underrated skills in the executive toolkit.
“Technical debt isn’t just a problem buried in the codebase,” Privat says. “It’s a record of the bets a company made while trying to move forward. For leaders willing to read it carefully, that record may be one of the most honest insights into how their organization actually works.”
