Technical Debt Is a Leadership Problem

I’ve been on both sides of the tech debt conversation. As an engineer, I complained about it. As a manager, I created it. Neither side has the full picture, and that’s exactly the problem.

Tech debt gets treated as a technical issue. Engineers identify it, engineers want to fix it, and engineers get frustrated when they can’t. But the decisions that create tech debt and the decisions about when to pay it down are leadership decisions. They involve trade-offs about time, risk, team morale, and business priorities that are fundamentally outside the scope of any single codebase.

How Tech Debt Actually Gets Created

The standard narrative is that tech debt comes from bad engineering decisions. Cutting corners. Not writing tests. Choosing the quick fix over the right fix. And sure, some of it does. But in my experience, most meaningful tech debt comes from perfectly reasonable leadership decisions made under real constraints.

“We need to ship this feature by the end of the quarter.” That’s not an engineering decision. That’s a business decision that creates engineering consequences. The team does the best they can in the time they have, and the shortcuts they take are rational given the constraints they were given. Blaming the engineers for the resulting tech debt is like blaming a carpenter for using nails instead of joinery when you gave them a two-hour deadline.

Other common sources that are really leadership decisions in disguise:

Hiring timing. You hired three junior developers at once and they all wrote code before anyone could mentor them properly. The code works but it’s inconsistent and doesn’t follow the patterns the rest of the codebase uses. The root cause is a leadership decision about hiring pace and onboarding.

Architecture without authority. Nobody was empowered to say “we’re doing it this way” so three different teams solved the same problem three different ways. Now you have three authentication systems. The root cause is a leadership decision about organizational structure and technical authority.

Strategic pivots. The company changed direction and the code that was built for the old strategy doesn’t fit the new one. That’s not debt from bad engineering. That’s debt from a business decision, and it was probably the right business decision.

Why Engineers Can’t Fix It Alone

When engineers identify tech debt, their instinct is to propose a fix. “Let’s refactor the payment system.” “Let’s migrate to the new framework.” “Let’s rewrite this service.” These are all technical solutions to what is partially a technical problem.

But here’s what the engineer typically can’t answer: Is this the most important thing we could be doing right now? What’s the cost of not fixing it? What’s the risk of fixing it? How does this compare to the other ten things we could invest this time in?

These are prioritization questions, and they require context that individual engineers usually don’t have. How much runway does the company have? What does the sales pipeline look like? Are we about to hire five more people who will need to work in this codebase? Is there a compliance deadline that changes the risk calculus?

I’ve seen well-intentioned tech debt cleanups that consumed months of engineering time and delivered zero business value because the part of the system they cleaned up was about to be deprecated anyway. I’ve also seen teams refuse to address tech debt that was actively costing the company money in production incidents. Both failures were leadership failures, not engineering failures.

A Framework for Tech Debt Decisions

Here’s how I think about tech debt decisions as a leader:

1. Categorize by Impact, Not Severity

Engineers tend to categorize tech debt by how bad the code is. Leaders should categorize it by impact. I use three buckets:

• Slowing us down. This debt makes every feature take longer to build. It’s the crud in the gears. Examples: poor test coverage that makes changes risky, tangled dependencies that mean touching one thing breaks another, unclear APIs that require reading source code to understand.

• Creating risk. This debt could hurt us if something goes wrong. Examples: no monitoring on a critical path, a single point of failure with no failover, security vulnerabilities in dependencies we haven’t updated.

• Annoying but harmless. This debt offends engineering sensibilities but doesn’t actually cause problems. Examples: inconsistent naming conventions, an older framework that still works fine, code that could be more elegant but does its job.

Most tech debt lives in that third bucket. Most engineering energy for fixing tech debt is also directed at that third bucket. A leader’s job is to redirect that energy toward the first two.

2. Make the Cost Visible

One of the hardest things about tech debt is that the cost is invisible. Features that take two weeks instead of one. Bugs that take a day to diagnose instead of an hour. On-call rotations that are miserable instead of manageable. None of this shows up in any dashboard.

As a leader, part of your job is making these costs visible. Track cycle time. Track incident frequency and resolution time. Ask your team to estimate how much faster they could move without specific pieces of debt. These numbers are imprecise, but imprecise data is better than no data when you’re making prioritization decisions.

3. Budget for It, Don’t Sprint for It

The “tech debt sprint” is a popular approach and I think it’s usually wrong. You spend two weeks aggressively paying down debt, feel great about it, and then go back to feature work and accumulate debt just as fast. It’s the engineering equivalent of a crash diet.

What works better is a consistent budget. We aim for roughly 20% of engineering capacity going to debt reduction, infrastructure improvements, and developer experience work. It’s not a hard rule, and it flexes based on what’s happening, but it means debt never gets completely ignored and never completely takes over.

4. Own the Debt You Created

If you made the decision that created the debt, own it. Don’t let your engineering team believe they screwed up when in reality you gave them an impossible timeline. Saying “we chose to take on this debt to hit the launch date, and here’s when we’ll pay it down” is dramatically better for team morale than letting engineers feel like they’re drowning in their own mistakes.

The Reality of it all

Some tech debt is the right call. If your startup has six months of runway and you need to close a deal to survive, you should absolutely cut certain corners. If you’re entering a new market and need to learn fast, shipping rough code and iterating is better than building a cathedral that nobody wants.

The skill is knowing how much you can carry, when to pay it down, and being honest with your team about the trade-offs you’re making. It’s fundamentally a leadership skill.

The best engineering leaders I’ve worked with treat tech debt the way a CFO treats financial debt. They understand it’s a tool with a cost. They track it. They make deliberate decisions about when to take it on and when to pay it off. And they never pretend it isn’t there.