What the hell is "Technical Debt"!?

It’s the most overused phrase in tech: "technical debt." You hear it in sprint retros, roadmap meetings, and frustrated hallway chats. It sounds serious. It sounds like something you can measure (and we try or at least sonarqube does). It even borrows from finance, so it must be logical right? The metaphor works like this: you make a conscious decision to take a shortcut, like building a quick-and-dirty solution to meet a deadline. This shortcut is the "principal" of your debt. The "interest" is the ongoing cost you pay for that decision, every time you touch that code, you're slowed down by its complexity, you introduce new bugs, or you spend extra time trying to understand it. Over time, this interest accrues, making future changes slower and more expensive.

But here’s the truth: "technical debt" is a fuzzy, misleading term that hides more than it reveals. What's more, it rarely, if ever, relates back to a conscious decision someone made (making the original metaphor somewhat redundant). And I think we should stop using it altogether.

The Problem with the Debt Metaphor

Ward Cunningham first coined the term back in 1992. The idea was that taking shortcuts to ship faster was like borrowing money: you’d have to “pay interest” later when the codebase became harder to change.

It was a clever metaphor and useful for its time but over the years, it’s been twisted into a giant, catch-all bucket for anything we don’t like about our code or systems:

• "Legacy code" = technical debt
• "That thing no one understands" = technical debt
• "Stuff that slows me down" = technical debt
• “Technology we don’t want to use” = technical debt

The problem? When everything is "technical debt," nothing is.

My Experience

In my own career, "technical debt" has rarely been used as a neutral, objective term. More often, it’s been a convenient excuse (sometimes justifiably just not concisely) :

• An excuse to avoid working on difficult parts of the system
• An excuse to justify costly full rewrites instead of targeted fixes
• An excuse for delivery delays
• An excuse for poor quality in new features
• And sometimes, an excuse for not having a clear technical strategy.
• And the most annoying one of all, when MVPs that were built years ago are now "tech debt" because of missing capability.

When “technical debt” becomes the magic phrase that explains away any problem, the real issues get buried.

How It Warps Developer Culture

The word "debt" has become a cultural poison, infecting how teams think and build. It instills a genuine fear in developers, who often pad their time estimates when a task involves "debt-ridden" code, not because the work is complex, but because they are terrified of the unknown “debt” awaiting them and being blamed for a bugs they didn't create. In turn, managers might schedule a "Tech Debt Sprint" to tackle the problem, but without a specific, measurable goal, it often devolves into pointless refactoring with no real impact. This cycle of fear and avoidance is so powerful that it begins to dictate architecture. To escape the perceived "debt," teams will over-engineer new features in isolation, creating separate, rigid systems that refuse to interact with the older codebase, introducing layers of avoidance. This creates new silos and brittle designs, turning the term "technical debt" into something that actively undermines good design and paralyzes constructive problem-solving.

The Real Picture: Two Different Problems

When you strip away the metaphor, what people call “technical debt” usually falls into two very different categories and they need two very different strategies.

1. Cycle Time Lag

This is the hidden delay slowing down your ability to deliver value right now. It's the extra drag on every sprint, every story, every change. Examples:

• Fragile code that breaks easily
• Missing or flaky tests creating long QA cycles
• Slow build and deployment pipelines
• Environment problems
• Missing Design
• Missing documentation.

Cycle Time Lag is a speed problem. You can measure it, see it in your metrics, and fix it with targeted improvements. Think of Lag like a golfers handicap, its the increased time to deliver that we constantly try to reduce.

2. Product Risk

This is the looming threat that could cause expensive, painful disruption later. It’s not hurting today’s delivery, but it’s a ticking time bomb. Examples:

• Outdated frameworks with no upgrade path
• Unsupported vendor systems
• Critical knowledge trapped in one person’s head

Product Risk is a resilience problem. It requires foresight, planning, and usually investment before it becomes urgent.

Why Ditching "Technical Debt" Matters

Using one catch-all label for both a speed problem's and a resilience problem has real consequences:

• It creates a false equivalence, making it impossible to prioritize.
• It creates an ownership problem!
• It creates a feedback loop of avoidance, preventing any real improvement.

By separating the two, you get clarity and control:

• Fix Cycle Time Lag to ship features faster today. (Engineering teams own this, only go after things that make you faster!)
• Manage Product Risk to build a more resilient system for the future. (PM and Architecture own this)

Final Thought

Most of what we call “technical debt” isn’t debt at all, its a normal part of software development inherent in every system I've ever seen, I have never once been able to find the guy that made the decision to take the shortcut! What we call debt today is either a speed problem or a resilience problem. The sooner we stop using this "walking, talking meme" and drop the vague metaphor, the sooner we can have clear, measurable, productive conversations about where our time, money, and energy should go.