Technical Debt Is Not the Enemy

"We need to stop everything and pay down tech debt."

I've heard this a hundred times. Usually from engineers frustrated with messy code. Sometimes they're right. Usually they're not.

Technical debt isn't inherently bad. It's a tool. Like actual debt — sometimes it makes sense to take it on, sometimes it doesn't.

What Technical Debt Actually Is

Ward Cunningham coined the term. His original meaning: shipping something you know isn't ideal to learn faster, then coming back to fix it once you understand the problem better.

That's strategic debt. You're trading future cleanup for present learning.

What most people call tech debt:

• Code someone wrote badly
• Systems that grew organically without design
• Old patterns nobody wants to maintain
• Anything the current team didn't write

Some of this is debt. Some of it is just... code. Old code isn't automatically debt.

Good Debt vs Bad Debt

Good debt:

• Deliberate tradeoff with known cleanup cost
• Enables faster learning or time-to-market
• Documented so future team knows it exists
• Has a plan for eventual paydown

Bad debt:

• Accumulated accidentally through neglect
• Nobody knows why things are the way they are
• No visibility into the cost
• Compounds silently until crisis

The first kind is a business decision. The second kind is dysfunction.

When to Take on Debt

I've intentionally shipped suboptimal code in these situations:

Racing a competitor. Being second to market with perfect code is worse than being first with decent code.

Validating an idea. Building a polished system for a feature nobody wants is waste. Build ugly, learn if it matters, then polish.

Regulatory deadline. Ship the compliant version now, refactor later.

Team capacity crunch. Sometimes you need to get through the quarter with what you have.

The key: know you're taking on debt and plan to pay it.

"We'll clean this up later" without a plan is not strategy. It's denial.

When to Pay Down Debt

Not "whenever engineers want to." That's how you end up with perpetual refactoring that ships nothing.

Pay down debt when:

It's actively slowing you down. Can't add features without breaking things? Debt is costing more than paydown would.

It's causing incidents. If the same janky system causes outages repeatedly, fix it.

You're about to build on top of it. Taking new debt on top of old debt compounds the interest.

You have natural downtime. Between major initiatives, use the slack for cleanup.

How to Prioritize Debt

Not all debt is equal. I use a simple framework:

Debt Type	Priority	Reason
Causing incidents	High	Direct business impact
Blocking features	High	Slowing roadmap
Increasing dev time	Medium	Indirect cost
Aesthetically annoying	Low	Not actually hurting anything

That last category is important. Code that's ugly but working is not urgent. Engineers hate hearing this, but it's true.

"This code is embarrassing" is not a business justification.

The 20% Rule

Some teams do "20% for tech debt." It sounds nice. In practice:

Problems:

• Becomes a dumping ground for random refactoring
• No prioritization — whatever engineers feel like
• Hard to measure impact
• Can become entitlement rather than investment

What works better:

• Specific debt items on the roadmap, prioritized like features
• Clear outcomes ("reduce deploy time from 20min to 5min")
• Measured impact after paydown
• Engineers propose, product/leadership approves

Debt paydown should be treated as seriously as feature work. That means planning, justification, and measurement. (This is essentially Developer Experience as Product Work.)

The Strangler Pattern

My favorite approach for big debt: don't rewrite, strangle.

Instead of replacing the old system wholesale:

1. Build new thing alongside old thing
2. Route some traffic to new thing
3. Gradually migrate more
4. Eventually turn off old thing

Lower risk. Incremental progress. You can stop halfway if priorities change.

Big bang rewrites fail constantly. Strangler pattern works.

Having the Conversation

When engineers say "we need to address tech debt," I ask:

1. What specifically is the problem?
2. What is it costing us? (time, incidents, velocity)
3. What would we do differently?
4. What's the paydown cost?
5. What's the business case for doing it now vs later?

If they can't answer these, it's not a proposal. It's a complaint.

When the answers are solid, I prioritize it against other work. Sometimes debt wins. Sometimes features win. That's normal.

The Real Problem

Most debt conversations are actually about something else:

• Engineers feeling unheard
• Frustration with pace or direction
• Desire for technical autonomy
• Burnout from working in messy systems

These are real problems. But "rewrite everything" isn't the solution.

Listen to what engineers are actually saying. Address the underlying issues. The debt conversation often resolves itself.

---

Technical debt is a tool, not a sin. Take it deliberately, track it honestly, pay it strategically. The goal isn't zero debt — it's debt that's serving business goals rather than accumulating invisibly.