Managing Technical Debt as a Leadership Problem

---

"We need to halt all feature development for two months and rewrite the backend. If we don't do this now, the company is going to fail."

I've heard this speech. I've probably given a version of it early in my career. And I've watched business stakeholders roll their eyes, nod politely, and then put the request at the bottom of the backlog where it quietly rots for another year.

Here's the uncomfortable truth: they weren't wrong to ignore it — not because the technical debt wasn't real, but because we framed it wrong.

Technical debt is not a technical problem. It is a business risk management problem.

When you approach it as "messy code that annoys me," you'll never secure the resources to fix it. When you approach it as "this is a compounding liability that will cost us more to carry next quarter than to address now," you'll find the conversation goes differently. A CFO understands compounding interest. They speak that language every day.

Your job as a tech lead is to translate.

The Language Translation

Engineers speak in terms of elegance, clean architecture, and best practices. Business leaders speak in terms of cost, risk, and velocity. These are not the same conversation.

Engineer's version: "The payment service is a monolith with massive God classes and 40% test coverage. We need to extract it into a service with clear boundaries because the coupling is unsustainable."

Business translation: "The payment service takes four days to safely deploy any change. Every time we touch it, we run a statistically significant risk of breaking the checkout flow. We've had two revenue-impacting incidents from it in the last six months. This is costing us both engineering velocity and introducing ongoing revenue risk that compounds every sprint we delay."

Same problem. Completely different reaction. The first version sounds like an engineer asking for time to clean their room. The second version sounds like a risk mitigation strategy.

When you learn to speak this language, technical debt stops being a pet project and starts becoming a strategic initiative. That's when the calendar opens up.

The Four Classic Types of Technical Debt

Not all debt is created equal. The way you treat a hastily written migration script is completely different from how you treat a fundamentally flawed database schema. Confusing them is how teams spend engineering cycles in the wrong places.

1. Deliberate Debt

You knowingly take a shortcut to hit a critical market window. You decide the business risk of missing the date outweighs the technical risk of the shortcut.

Example: Hardcoding configuration values that should be dynamic because the product launch is in 48 hours and building the admin UI properly would take two weeks.

Strategy: Pay this down immediately after the deadline. Mark it explicitly in the code with a TODO and a date. Log it in your debt backlog. If you treat this like a payday loan — high interest, immediate repayment — it's manageable. If you pretend the debt doesn't exist after the launch, you're lying to yourself about the interest.

2. Accidental Debt (Structural Drift)

The system was designed well for the requirements you had two years ago. The business model evolved. The system didn't. Now you're fighting your own architecture to deliver what the business actually needs.

Example: You built a clean multi-tenant SaaS application. Then the enterprise sales team closed three huge deals that require fully isolated on-premise deployments. The architecture doesn't support the new reality.

Strategy: This requires a dedicated roadmap initiative, not a sprint's worth of refactoring. Write the One-Pager, get leadership alignment, and treat it as a proper project with resources and milestones. You cannot bolt-on architectural changes like you can clean up a bad function.

3. Bit Rot

Libraries age. Frameworks get deprecated. Security vulnerabilities accumulate. Standard practices evolve while your codebase stays still.

Example: You're running a version of your frontend framework that's been unsupported for three years. The ecosystem has moved on. Your team spends time fighting integration issues instead of building features.

Strategy: The Boy Scout Rule — leave the campground cleaner than you found it. Every time an engineer touches a file, they make one improvement: update a dependency, add a test, replace a deprecated API call. Build this into your definition of "done." It doesn't require sprints; it requires professional discipline applied consistently.

4. Reckless Debt

Code written without any consideration for maintainability, scalability, or future modification. No tests. No comments. No design. Copy-pasted from Stack Overflow, or now from AI assistants, without understanding what it does.

Example: A 4,000-line script that processes payroll, written under pressure by someone who no longer works at the company, that everyone is terrified to touch.

Strategy: Quarantine and replace. Do not refactor this. Treat it like a hazardous material — build a new, properly tested system alongside it, migrate the traffic gradually, and decomission the old one only when you're certain the new one is stable. Refactoring reckless debt is how you convert one unstable system into two.

The Fifth Type: AI-Generated Debt (New in 2026)

I'll be direct: this is the debt type that keeps me up at night, and most engineering leaders aren't talking about it yet.

AI coding tools have dramatically increased the volume of code being produced. Teams are shipping more, faster, and with less friction than ever before. That's genuinely valuable.

But volume without judgment creates a new kind of recklessness. Engineers accept AI-generated implementations they don't fully understand. Architectural patterns get copy-pasted from AI suggestions without evaluating whether they fit the system's actual constraints. Tests get generated to hit coverage numbers without anyone asking whether they test the right things. Code that works right now gets merged without anyone considering what happens when requirements change.

I've started calling this AI-generated debt: technically functional code that nobody fully owns or understands, accumulated at a pace no previous team could have managed.

Strategy: Two things, consistently.

First, code review in an AI-augmented team must shift from "does this work?" to "does the author understand why this works?" If someone can't explain their own PR at the design level — not the line level — it doesn't merge. This isn't punitive. It's the only way to ensure the team is building knowledge, not just building features.

Second, the same debt tax approach (see below) applies — but with AI-generated debt, you need to be more aggressive about the repayment rate because the accumulation velocity is higher.

The Tech Debt Tax: The Only Sustainable Strategy

The worst way to pay down technical debt is the Big Bang Rewrite.

I've seen three Big Bang Rewrites in my career. I believe exactly zero of them delivered the promised outcome on the promised timeline. They always take twice as long as estimated. They require pausing feature development, which infuriates stakeholders. By the time you finish, the business requirements have shifted enough that your shiny new system is already accumulating its own debt.

The sustainable alternative is the Tech Debt Tax.

Allocate a fixed percentage of every sprint's capacity — I recommend 15-20% — specifically to paying down debt and improving system health. Then do not ask for permission to do this.

You do not ask the product manager whether it's acceptable to write unit tests. You do not ask whether it's okay to use version control. These are professional standards of the craft. Maintaining the health of the codebase is the same — it's the cost of running a software system responsibly.

If your team has a velocity of 100 story points per sprint, communicate to the business that your feature velocity is 80 points. The remaining 20 points are maintenance tax: the fixed cost of keeping the factory floor clean enough to keep running.

When the business pushes back — and they will — you explain it once: "We are dedicating 20% of our time to ensuring the platform remains stable enough to continue shipping at this pace. The alternative is that we ship faster for two quarters and then spend an entire quarter unable to ship anything because the system has become too fragile to touch safely."

Most stakeholders, once they understand the compounding nature of deferred maintenance, will accept this. The ones who don't will eventually force your hand in the worst possible way.

Key Takeaways

• Speak the language of the business. Quantify debt in terms of velocity lost, risk carried, and financial cost. Engineers who speak in code smell metaphors get ignored.
• Know your debt type before choosing your strategy. Deliberate debt requires timely repayment. Structural drift requires a proper initiative. Bit rot requires the Boy Scout Rule. Reckless debt requires replacement, not refactoring.
• Watch for AI-generated debt. Volume without understanding is a new form of recklessness. Code review must evolve to catch it.
• Never bet on the Big Bang Rewrite. It almost never delivers. The debt tax — consistent, sustainable, non-negotiable — is the professional approach.
• Your next step this week: Pick the top three items in your team's technical debt backlog and translate each one into business language. Then share that translation with your product manager or engineering manager and see how the conversation changes.