Cracking the Code on Technical Debt

Have you ever found yourself grappling with systems or applications that just won't cooperate the way they're meant to? Perhaps you've noticed that applications are frequently down, or maybe you've found yourself relying on numerous workarounds just to complete everyday tasks. It's likely that each of us has our own choice phrases for these frustrating moments. But have you ever wondered if there's a term for these issues that you can actually say out loud? Well, there is – and it's likely what you're experiencing is the result of technical debt.

And the thing about technical debt is that it rarely shows up as one dramatic failure. It shows up as friction: little delays, “temporary” patches that become permanent, and the creeping feeling that every small change somehow breaks three other things. It’s not just annoying, it’s expensive.

In our latest podcast episodes, my two co-hosts and I dive into the concept of technical debt. If you haven't tuned into our podcast yet, now might be the perfect time to start (though I admit, I might be a little biased).

What technical debt actually is

Technical debt occurs when an organization opts for quick fixes or "good enough" solutions, instead of investing the time to address issues properly. It's the "this is good enough, we'll fix it later" mentality that might sound all too familiar. While the approach may save time in the short term, it often leads to more complex problems down the line, requiring even greater effort and resources to resolve.

Another way to describe it: technical debt is the interest you pay on past shortcuts. Every time you delay a fix, complexity grows. Then the next project takes longer, costs more, and carries more risk, not because the team is bad, but because the system is now fighting back.

The common signs (aka “this feels familiar”)

If you’re trying to spot technical debt in the wild, it often looks like this:

• Frequent outages or performance issues that keep “mysteriously” returning

• “Don’t touch that” systems where nobody wants to make changes

• Lots of manual workarounds to get basic tasks done

• Backlogs full of “we should refactor this” tickets that never rise to the top

• Projects that get slower over time, even when the team is working hard

None of these are just IT problems. They become business problems fast: missed timelines, frustrated staff, unhappy customers, and leadership making decisions with incomplete information because the systems can’t deliver what they need.

Why it matters beyond IT

In our discussions, we explore the implications of technical debt, how it accumulates, and most importantly, strategies for managing and reducing it. Understanding and addressing technical debt is crucial for enhancing efficiency, reducing downtime, and ultimately, for the smooth operation of our systems and applications.

The business impact is usually where the story gets real:

• Operational risk: More failures, more workarounds, more dependency on heroics

• Security risk: Legacy systems and patched workflows are easier to exploit

• Strategic risk: New capabilities take longer to deliver, so the organization falls behind

• People risk: Teams burn out when every task requires “creative” problem-solving

If you’ve ever wondered why “simple” changes take forever, technical debt is often the answer.

Paying it down takes alignment, not just effort

Addressing technical debt requires a collective commitment across the entire organization; it's a team effort that transcends individual departments or roles. From leadership down to the development teams, there needs to be a unified understanding that paying down technical debt is not just about fixing code, but about investing in the organization's future efficiency, reliability, and adaptability.

This is the part that gets overlooked: the fix isn’t just “work harder” or “hire one more developer.” Paying down debt requires prioritization, and that means leadership agreeing that reliability and maintainability are worth time and money, even when there isn’t a shiny new feature attached.

A practical starting point

If you’re not sure where to start, here’s a simple approach that doesn’t require a massive transformation program:

1. Name it. Put technical debt in plain language in the backlog and planning conversations.

2. Quantify impact. Track downtime, incident volume, workarounds, and cycle time.

3. Pick a “debt payment” model. For example: dedicate a small, consistent percentage of each sprint or project to debt reduction.

4. Target the repeat offenders. Fix the top issues that cause the most disruption, not the most interesting ones.

5. Create visibility. Report progress like you would any other business priority.

Where risk management becomes the superpower

And who better to connect those dots for the organization than your fellow risk management folks?

We should use those root causes - big picture view - ninja skills of ours and help grow an organizational culture that values foresight, discipline, and the courage to address issues before they escalate. 

Time to pay down that technical debt!

Listen in here!