Technical debt is a toxic asset: how tech leaders must renegotiate the contract with the business

Have you ever tried explaining to the Board of Directors why it is necessary to slow down development to "fix the code"? In that moment, the CEO's eyes glaze over, exactly like during the mid-August holidays when nobody bills and everyone is away. Opposite him, the CFO sighs, mentally calculating the ROI of an invisible job that will waste time instead of implementing those features that customers are desperately searching for.

Not knowing how to describe the problem, searching for the right words, you try pronouncing the magic formula:

technical debt

If you are convinced that this financial metaphor will finally create a bridge with the business, I will let you in on a secret: it has not worked, it will never work, and it is largely our fault.

The problem is not the business's lack of interest, but the use of an inadequate vocabulary to describe a real risk. For a software engineer, technical debt is tangible: obsolete libraries, tight coupling, absence of automated tests, and code lacking documentation. How do we explain that something cannot be built because the company supplying that critical component has shut down? Or that the programmer from Bangalore who produced the open source product we loved so much was hired by a Big Tech company, leaving a backlog of updates as long as a train to Rimini on an August weekend?

For a budget-focused manager, it sounds like a request to clean a room: a useful activity, but postponable indefinitely until an emergency arises.

It is time to change the frame, not the message. The tech leaders who secure budget, alignment, and respect are those who translate engineering reality into the language of corporate assets, operational risk, and "TCO". It is not about simplifying, but about speaking the same language as the business.

Low-quality code is not a manageable debt: it is a toxic asset that generates negative externalities on the entire company balance sheet.

From "debt" to toxic asset: the vocabulary shift worth millions

When Ward Cunningham coined the term "technical debt" in 1992 (the original explanation of which can be read on the C2 Wiki), he had a specific goal: explaining to managers that releasing imperfect code to speed up delivery is equivalent to taking out a financial loan. The metaphor was brilliant for its time, but today, in front of a CFO managing real investments, it risks backfiring on the tech team.

The reason is subtle: in the financial world, debt is often a strategic and useful tool. Without debt, companies cannot finance expansion, acquire competitors, or enter new markets. A manageable debt allows the company to expand much faster than without it.

When a CTO declares they want to pay off technical debt, the business implicitly hears: "we want to repay a loan that allowed us to accelerate and for which we are paying interest." The board's obvious reaction will be immediate: "why do it right now when there are more important business requests?"

Low-quality code is not a manageable debt

In financial terms, it is a true "toxic asset": a balance sheet item that depreciates and generates negative externalities on the entire corporate ecosystem. We are talking about an unhedged risk that grows silently within the company's technology assets. Over time, its effect is to slow down every feature release, increase the onboarding time for every new developer, and make every new change a maze of growing compromises.

When a financial institution discovers it has toxic assets in its portfolio, it acts quickly because it knows the market will demand accountability for the risk. Software is no exception. The market, in the form of faster competitors, demanding customers, and departing developers, will eventually present the bill. And it will be a much steeper bill than expected.

I still remember when a client asked me to make some changes to a software because the previous developer was no longer with the company. The problem was not implementing the changes themselves, but the fact that the code had suffered years of disorganized technological layering without any common criteria.

It was a labyrinth riddled with "ad hoc" conditions for no longer active clients, lacking automated tests, and with colliding logical flows. In such contexts, every intervention is a gamble: the cost and the risk of regressions are extremely high. Even a change that is trivial on paper can turn into a massive commitment.

Even modern AI assistants struggle in such scenarios. Without underlying structural coherence, no digital copilot can work miracles or find logic where chaos reigns.

There is also a modern paradox: these same AI coding assistants, if used without strict governance criteria, are acting as formidable technical debt multipliers. Generating lines of code now takes milliseconds, but validating, understanding, and maintaining that code takes just as long as before, if not longer. Without control, we risk flooding our repositories with synthetic code not understood by those who release it.

The Spoon River of code: when debt turns into collapse

There is a case study that every CTO should know by heart for its surgical precision in demonstrating the danger of a toxic asset. On August 1, 2012, Knight Capital Group lost 440 million dollars in just 45 minutes.

The cause? An obsolete fragment of code left behind in a trading router, not removed because "it wasn't being used anyway."

The lack of code reviews, verified deployments, and real-time monitoring pushed one of Wall Street's largest market makers into bankruptcy. It was not a hacker attack, but forgotten code that no one had the courage or competence to touch.

Knight Capital shows how ignored technical debt can turn into a systemic financial crisis

This scenario is repeating globally with growing impact. On July 19, 2024, a single faulty update from CrowdStrike blocked hospitals, airports, and banks worldwide, crashing 8.5 million Windows systems.

For Fortune 500 companies alone, the financial damage exceeded 5.4 billion dollars. The cause? A memory access error that escaped automated testing and rigorous validation processes.

The result was the largest IT outage in history, leading to billion-dollar lawsuits like the 500 million dollar one filed by Delta Air Lines.

The most emblematic case for traditional enterprises remains Southwest Airlines. In December 2022, the airline canceled over 16,000 flights during the peak holiday season, leaving 2.5 million passengers stranded.

The cost? Over 800 million dollars in losses and a record 140 million dollar fine. The crew management software, which was twenty years old, had been updated in a fragmented way despite operating volume growing by 69%.

Management had preferred to invest in the frontend, neglecting the core infrastructure despite warnings raised by the union as early as 2015. At the first weather disruption, the system collapsed.

If these cases seem far from our reality, let us remember that for European and Italian SMEs, technical debt rarely manifests as multi-million dollar fines, but rather as a more insidious sentence: operational paralysis. In small and medium enterprises undergoing digital transition, the toxic asset translates into an incredibly slowed-down time-to-market, the inability to scale, and hidden vendor lock-in.

How many times have we seen companies held hostage by local vendors or external software houses that unilaterally dictate rates and delivery times because no one else can understand the code they wrote? Without internal technology governance and documented quality standards, the company effectively cedes its digital sovereignty to the supplier of the day. It is a silent loss of margins that erodes competitiveness day after day.

In all of these scenarios, the problem was not the tech team's ignorance of the risk, but the inability to translate that risk into understandable and quantifiable metrics for the Board, which consequently did not prioritize funding its resolution.

Translating silicon into finance: DORA metrics for the board

There is a category of metrics that developers monitor closely, but that business leaders ignore: code coverage, number of resolved bugs, SonarQube reports, or automated test percentages.

In some teams, there are specific tasks in the pipeline whose sole purpose is to reduce SonarQube alerts. In others, the development team meets weekly to discuss reducing the "Technical Debt Ratio". All of these data are valuable to engineers, but have zero strategic value for the business.

Presenting them to the Board to justify a refactoring budget is equivalent to showing turbine bolt wear rates to the shareholders of an airline: a correct technical detail, but completely devoid of strategic value in that setting.

The DORA (DevOps Research and Assessment) framework represents the ideal bridge between code health and business goals. Validated on a global scale, it directly correlates the efficiency of technology processes with corporate performance.

• The Change Failure Rate, which represents the percentage of releases that cause incidents in production. This metric defines the product's reliability in the eyes of the board. A high value indicates that every new feature released is a risky gamble that undermines customer trust and increases churn.
• The Mean Time to Recovery, which calculates the average time needed to restore service after an outage. This represents the company's resilience index: the faster the recovery, the lower the direct financial losses and brand image impact.
• The Lead Time for Changes, which measures the time required to take a single line of code from conception to production. This indicator coincides with time-to-market, determining the company's competitive responsiveness.
• The Deployment Frequency, which indicates the frequency of stable releases. Releasing continuously and smoothly demonstrates an agile production process that reduces deploy sizes and eliminates the systemic risks typical of large cumulative releases.

If you present data with this approach, you are not asking for a budget to "clean up the code":

You are presenting an investment plan, not asking to clean up

You are proposing a strategic investment with a quantifiable ROI and clear timelines. This is the fundamental difference between asking and convincing: presenting the data as measurable improvements in business resilience and responsiveness, not as ordinary maintenance.

Imagine the scene. You speak passionately about "refactoring the checkout module" and the CFO, in their head, only hears: "they are asking for money to rewrite something that works, and this will lower profits by 10%". Try changing perspective: explain that this intervention extends the useful life of the platform by five years and increases its book value, and the CFO's eyes will light up: "so I can have another five years of recurring revenue from this software without having to replace it?".

You have just transformed an expense into a capitalizable asset, amortizable over multiple years. You are not cleaning up; you are renovating the foundations of the company building.

The software factory: beyond code aesthetics

A CTO's role is often misunderstood: their main mission is not to be the most talented developer in the team, but to design a "sustainable software factory". It is about building a production system capable of delivering value predictably, scalably, and resiliently over time.

Code quality is not an aesthetic whim, but a governance choice.

Large open source projects, like OpenJDK, prove a counterintuitive truth: strict standards and severe processes do not slow down development. On the contrary, they are the only condition that allows hundreds of developers to collaborate safely.

In the TCO of low-quality code, there is an invisible cost: onboarding. Adding new resources to a codebase lacking documentation or code reviews increases complexity without increasing productivity.

I have experienced firsthand managers asking: "Why can't we just add more people to the team to speed up development?". As a consultant, I was always torn on how to present this clearly and convincingly: the project was extremely complex, and adding people would increase regression risks and slow down the release. But how do you explain this concept to someone who has never written a single line of code in their life?

A story has circulated for years illustrating this concept: a development team of ten people takes ten days to complete a software module. Adding ten more people, the time required to complete the same module does not drop to five days, but rises to fifteen. Why? Because the code is so complex and unreadable that the new resources spend more time figuring out what to do and how to do it than actually coding.

The inevitable outcome of accumulated debt is rewriting from scratch, which is often seen as the only possible solution. In reality, rewriting is the exception, not the rule, and if processes do not change within the company, the new software is destined to become a new toxic asset in a few years.

I remember a company that had layered changes for years. To update the product, it became necessary to rebuild everything from scratch because languages and dependencies were obsolete and insecure. A job of years was condensed into six months, keeping only the necessary and adopting a scalable architecture.

But this is the exception. Often, the financial strength to do so is lacking, and patches continue to be applied hoping the castle won't collapse. The final costs of delay, as Southwest teaches us (which spent a billion dollars to remediate), are three to five times higher than routine maintenance.

The core problem was not the lack of budget or skills, but a translation defect: the operational risk was known but was not communicated with the response-making level's proper vocabulary.

Audit, measurement, and strategy for your organization

As tech leaders (CTOs or tech leads), you have three non-delegable responsibilities that define your role in a managerial key, transforming you from operational heads to strategic risk managers. The first is enforcing high quality standards as a precondition for the development team's scalability, since every shortcut is a hidden cost the company will pay in the future. The second is the systematic adoption of code reviews as a tool to share knowledge and mitigate "Key Person Risk", considering each review as a preventive business continuity measure. The third is reporting on the health status of the software through metrics aligned with corporate goals: concrete indicators linking architectural choices to business outcomes.

When you present a budget request to refactor a legacy application, avoid promising "cleaner code". Commit to halving the CFR or contracting the Lead Time for Changes by 30%, bringing data to support your case.

Tomorrow morning, or at least within this week, try taking these concrete actions within your IT department:

• Launch an internal mapping: identify the critical software module that constitutes a potential Single Point of Failure (SPOF) and the flow with the highest Lead Time.
• Estimate the economic impact: calculate the cost of a prolonged downtime on that component, translating it into lost revenue and recovery costs.
• Prepare the presentation: show the management these precise data instead of the classic technical debt.
• Establish a Software Risk Ledger: create a formal ledger of technical debt and associated technological risks, integrating it directly into the company's Corporate Risk Register. Treat architectural vulnerabilities exactly like legal, cybersecurity, or compliance (GDPR) risks, quantifying their probability and expected financial impact.

Stop asking for permission to do your job well

Instead, demonstrate that development stability and quality are exactly the goals the business expects from you, even when the executives are not yet fully aware of it.