Technical Debt Is Not the Enemy

Every engineering team I've ever led has had a complicated relationship with technical debt. Engineers hate it. Product managers don't understand it. Executives think it's an excuse for slow delivery.

Here's my take after twenty years: technical debt isn't a bug in your process. It's a feature. The problem isn't that it exists — it's that most organizations don't manage it intentionally.

Debt as a Deliberate Choice

In finance, debt isn't inherently bad. Taking on a mortgage to buy a house is smart leverage. Taking on credit card debt for impulse purchases is not. The difference is intentionality and a plan to repay.

Technical debt works the same way. Choosing to ship a simpler implementation now because you need to validate a business hypothesis? That's smart leverage. Accumulating complexity because nobody ever refactors anything? That's the credit card kind.

The key is making debt decisions explicitly. When my teams take on technical debt, we document it: what we're deferring, why, and what the repayment plan looks like. It goes in the backlog with a clear trigger condition ("revisit when we hit X users" or "refactor before building feature Y").

The Three Types

I've found it useful to categorize technical debt into three types:

Deliberate and prudent. "We know the right way to do this, but we're choosing the faster path because we need to ship by Friday. We'll circle back next sprint." This is healthy and often the right call.

Deliberate and reckless. "We don't have time to do it right." This usually means you do have time, but someone is prioritizing the wrong things. Push back on this.

Accidental. "We didn't know enough about the domain when we built this, and now the model is wrong." This is inevitable and not anyone's fault. The best response is acknowledging it early and addressing it before it compounds.

Managing Debt as a Leader

As a director overseeing multiple teams, here's how I approach technical debt organizationally:

Allocate capacity proactively. I encourage teams to spend roughly 20% of their sprint capacity on debt reduction, tooling improvements, and developer experience. This isn't negotiable — it's the cost of maintaining velocity over the long term.

Make it visible. Debt that lives in engineers' heads doesn't get addressed. We track it in the backlog alongside features, with clear descriptions of the risk and cost of inaction.

Connect it to business outcomes. "We need to refactor the payment service" doesn't resonate with stakeholders. "If we don't address the payment service architecture, we can't support the new billing model the business needs by Q3" does.

Celebrate debt payoff. When a team ships a significant refactoring or pays down a long-standing debt, recognize it. The work isn't glamorous, but it's critical.

The Compound Interest Problem

The reason technical debt gets so painful is compound interest. A shortcut in your data model makes every subsequent feature that touches that model slightly harder. Those slight increases compound over months and years until your team is spending more time working around the debt than building new capabilities.

The organizations that handle this well are the ones that treat debt repayment as a continuous, ongoing practice — not as a periodic "tech debt sprint" that happens once a quarter when things get desperate.

Build it into the rhythm. Make it normal. Your future self — and your future team — will thank you.