Skip to main content

Managing technical debt like financial debt

Yesterday on my way home, I was listening to the SoftwareCaptains podcast episode with Mathias Verraes (sorry, the episode is in Dutch). One of the topics discussed was technical debt and the  question was raised why (most) organizations manage very carefully their financial debt, they don’t apply the same rigor for their technical debt.

This triggered a train-of-thought that resulted in this post. Financial debt is meticulously tracked, reported, and managed. CFOs provide regular updates to boards about debt levels, leveraging ratios, and debt servicing costs. Detailed financial statements outline current liabilities, long-term obligations, and repayment schedules. Financial debt is visible, quantified, and actively managed.

Yet technical debt—which can be just as crippling to an organization's future—often exists as an invisible, unquantified burden until it's too late.

What if we managed technical debt with the same rigor as financial debt?

The hidden cost of technical debt

Technical debt accumulates when development teams make implementation choices that prioritize short-term goals over long-term system health. Like financial debt, technical debt isn't inherently bad—it can be strategically leveraged to deliver value quickly. The problem arises when it remains invisible, unmanaged, and ultimately unpaid.

 

The consequences are real and severe:

  • Decreased development velocity as teams navigate increasingly complex systems

  • Rising maintenance costs that steadily eat into innovation budgets

  • Increased system failures and outages impacting customer experience

  • Higher employee turnover as engineers burn out working with problematic codebases

  • Inability to respond quickly to market changes or competitive threats

Yet unlike financial debt, technical debt rarely appears on executive dashboards or board reports. It accumulates silently until it reaches crisis levels that can no longer be ignored.

As a venture capitalist you will probably not invest in a company that is knee deep in financial debt. But can you just ignore the accumulated technical debt?

The role of the CTO

Every company has a CFO who tracks financial obligations and ensures they remain manageable. Where is the equivalent role for technical debt?

I think this should be a responsibility of the Chief Technical Officer (CTO). He or she should be accountable for:

  1. Quantifying existing technical debt across systems and applications
  2. Tracking debt accumulation through development activities
  3. Establishing repayment strategies and prioritizing debt reduction efforts
  4. Reporting technical debt metrics to executive leadership
  5. Setting sustainable "debt policies” for the organization

The CTO shouldn't prevent all technical debt—just as CFOs don't prevent all financial debt. Rather, they would ensure debt is intentional, visible, and managed within sustainable boundaries.

Making technical debt visible and manageable

Financial debt isn't managed through vague conversations or individual awareness—it's tracked through formal processes, reported regularly, and managed strategically. Technical debt deserves the same treatment.

By establishing explicit technical debt management practices and assigning clear accountability through expanded CTO responsibilities, organizations can transform technical debt from an invisible threat to a managed resource.

The companies that thrive in the coming decade won't be those that avoid technical debt entirely—that's unrealistic. The winners will be those that make technical debt visible, intentional, and strategically managed just like any other business liability.

More information

Podcast: Mathias Verraes: software design voor startups en scaleups — SoftwareCaptains — Lead your tech team through your growth

Understanding Technical Debt

Labels:

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...
Read more

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...
Read more

A complex system designed from scratch never works

A few years ago, I worked as an architect on a big mainframe rewrite. I still count it as one of my failures. Not because the technology was wrong, but because I couldn't convince the management team to simplify the approach. Years later, the organization is still struggling to get the new system up and running. I left the project at the time, because I couldn't put my name behind an approach that would take very long and cost a lot of money without a working system to show for it along the way. Gall’s Law That memory keeps coming back to me, because it's a textbook case of Gall's Law playing out in real life. Gall's Law , from John Gall's Systemantics , states it plainly: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works, and it cannot be patched to make it work. You have to start over with a simple system that works. What does that mean in practice,...
Read more