Southwest Airlines designed its crew scheduling system in the 1990s to run lean with high aircraft utilization. A winter storm in December 2022 brought it down, and the airline couldn't reassign crews as flights cascaded. Other carriers recovered in days; however, Southwest had to cancel 16,700 flights over ten days, taking a $825 million writedown.Southwest's December 2022 meltdown: 16,700 cancelled flights, $825M writedown, and Congressional testimony. CEO Bob Jordan called the systems "antiquated." The Board approved a $1.3B modernization program.
Southwest Airlines CEO Bob Jordan called the systems "antiquated" before Congress. Shortly after, his Board approved a $1.3 billion technology modernization program.
The $825 million was not a freak accident. It was the carrying cost of technical debt that had accumulated for three decades without appearing on any balance sheet. No one had assigned it a dollar figure until the storm did it for them.
What Happens When You Can't See The Problem §
Knight Capital Group designed its systems for automated high-frequency market-making, complete with algorithmic safety controls. But during a routine software deployment, dead code from a 2003 version was accidentally reactivated. That dormant trading logic accumulated $7.65 billion in unwanted stock positions across 154 stocks in 45 minutes.Knight Capital: dead code from 2003 reactivated during deployment. No pre-deployment testing protocols existed. No kill switch for the legacy code path. $440M loss in 45 minutes, following SEC enforcement action.
There were no pre-deployment testing protocols. No kill switch for the legacy code path. Within 45 minutes, that added up to a $440 million loss, prior to value following SEC enforcement action.
The broader picture comes into focus through statistics: a $1.52 trillion accumulated liability (CISQ 2022), 20-40% of technology estate value with 30% of new product budgets diverted to debt issues (McKinsey), 124% longer time-to-market for new features where low code quality systems show 15x higher defect rates (Code Red). Conversely, high code health correlates with 43% faster feature delivery.CISQ 2022: $1.52T accumulated liability in the US alone. McKinsey: 20-40% of technology estate value, 30% of new product budgets diverted. Code Red: 124% longer time-to-market, 15x defect rates in low-quality codebases. What often gets lost in the numbers is the implicit message: we should measure this because it prevents collapse.
The Measurement Standard §
The type of failure we discussed above is avoidable if you're willing to treat technical debt as something measurable rather than metaphorical. The steps are straightforward: Align your stakeholders on the structural weaknesses you've accumulated. Derive your remediation roadmap based on quantifying those weaknesses. Periodically revisit your debt position to make sure it is still accurate.
Most codebases carry technical debt that lives in three variables: structural weaknesses multiplied by standard repair time multiplied by fully loaded developer cost. In 2024, the Object Management Group codified this as the Automated Technical Debt Measure.The OMG's ATDM standard (2024) codifies the formula: structural weaknesses × repair time × loaded developer cost. It makes technical debt assessable the same way a financial audit assesses accounts receivable.
These failure repositories are auditable, and you can build a prioritized list of problems directly from them.
Consider this: A codebase with 2,000 structural weaknesses at an average repair time of 4 hours and $150 per hour loaded cost carries $1.2 million in technical debt. That is not an engineering metaphor. It is a balance sheet liability that can be calculated, audited, and compared against reserves.
When Strategic Becomes Reckless §
Strategic technical debt prioritization is notoriously fraught in industry, largely because engineering leaders struggle to articulate a basic distinction: why some debt is acceptable while other debt is dangerous.
Not all technical debt is reckless. Some is strategic, and the distinction actually matters.
Shipping faster to capture a market window is a conscious trade-off with a payoff timeline. Engineering teams take on debt to beat competitors to market, with a clear plan to pay it down once market position is secured. The real danger is when deliberate strategic debt becomes forgotten operational debt that no one tracks.
Measurement must distinguish between the two, or the metric penalizes speed. A single dollar figure without the distinction misleads.
Marriott's $52 million settlement shows what happens when that line blurs. When Marriott acquired Starwood, it inherited a compromised security infrastructure that attackers had been inside for four years.Marriott-Starwood: 344 million customer records exposed. Attackers had been inside Starwood's infrastructure for four years pre-acquisition. FTC-mandated security overhaul followed. The liabilities sat untracked until they detonated post-acquisition.
Three hundred forty-four million customer records were exposed. An FTC-mandated security overhaul became the real cost of technical debt that had become forgotten operational debt. Those liabilities sat on the books untracked until they detonated post-acquisition.
What To Do Now §
Here's something we've learned the hard way: when you're taking over a system, don't go looking for trouble in the codebase first. Go talk to the people who've been fighting it every day. In the enterprise infrastructure projects we've delivered, the most expensive technical debt was the organizational knowledge gap between the team that built the system and the team maintaining it.
Debt doesn't really compound in lines of code. It compounds in loss of institutional understanding. Once the original architects leave, what remains is a system that works but cannot be safely changed.
If you're leading M&A due diligence, you require an ATDM assessment as a standard diligence item alongside financial and legal reviews. Acquirers routinely assess financial, legal, and environmental liabilities, yet technical debt receives a cursory architecture review at best.
The ATDM standard makes technical debt assessable the same way a financial audit assesses accounts receivable. The Marriott-Starwood case shows what happens when this liability goes unexamined.
And if you're a CFO looking at where the money goes, try this framing. Two kinds of debt live in your technology estate. Strategic debt—the kind you took on intentionally to win a market, with a timeline and an owner. And operational debt—the kind that just sort of accumulated and nobody remembers why. The only question worth answering is which one you're actually carrying.