How to Talk About Technical Debt So Your Boss Says, "Let's Do It Now!"

In a weekly meeting, I told my boss, “This interface has too much logic piled up. It needs refactoring.”

My boss frowned. “Have users reported any issues?”

“Not yet, but it’s bound to blow up sooner or later,” I said.

He paused for two seconds. “Let’s put it aside for now.”

If you’re carrying a pile of technical debt in your project, this scene is all too familiar.

We know a certain module is risky, and the person who wrote it left long ago. We know every release involves last-minute patches and frantic scrambling. We know the system is getting harder to extend, and refactoring is long overdue…

But one question—“Does this affect users?” “What’s the concrete loss?” “What happens if we don’t refactor now?”—squashes your technical debt anxiety into “next time.”

Technical debt isn’t something you can’t talk about; you just need to talk about it differently.

In this article, we’ll break down how to present technical debt so your boss nods and says, “Let’s do it now.”

1. Technical debt isn’t a technical issue; it’s an organizational issue We often think of technical debt as a pile of code problems, but its essence is organizational decisions.

Projects rush to meet deadlines and choose shortcuts.

People leave, and no one maintains the old code.

Only before launch do we realize the data structure can’t handle business changes.

Sometimes it’s even process gaps: code review is just a formality, testing doesn’t leave time for staging…

It’s not that a particular piece of code is badly written; it’s that during a certain period, we actively sacrificed system health for business growth or delivery speed.

Martin Fowler once used a quadrant diagram to define different types of technical debt:

Reckless / Deliberate: We know the consequences but still choose to do it, e.g., “No time to design, just hack it together first.”

Prudent / Deliberate: We know we’re incurring debt, we’ve assessed the risk, and we plan to pay it back later.

Inadvertent: We didn’t even realize it was technical debt until problems surfaced and we suddenly understood.

[[techDebtQuadrant.png]] Different types of technical debt require different handling strategies: reckless debt needs urgent repayment, prudent debt can be planned.

Understanding the causes of technical debt is the first step in communication. But to actually make progress, you need to know how to talk about it, how to choose what to fix, and how to change the system.

2. How to talk about it: Don’t talk about debt; talk about risk avoidance Many engineers describe technical debt by saying: “This logic is too old and needs refactoring”;

“The framework used here has been unmaintained for ages”;

“Performance is terrible; every peak period is a gamble.”

The boss’s first reaction is: “Can you stop scaring me?”

The second reaction is: “I don’t understand it, I can’t see the impact, so let’s not touch it for now.”

So when talking about technical debt, don’t start from a technical angle; start from organizational risk. Explain why it should be done and what benefits it brings.

Here are a few examples.

Instead of saying “This logic is too tightly coupled,” say: “Changing one field in production requires touching seven or eight modules, regression testing takes two days, and the change window keeps shrinking. If we decouple, field changes will be limited to one module, unit tests can cover most scenarios, and regression testing can be done in half a day.”

Replace “This library is outdated” with: “Official support has ended. If another security vulnerability appears, we’ll have no patch to apply and will have to patch manually. The new library has an active community, recent versions, and wide adoption. It not only eliminates security risks and avoids compliance issues but also offers many improved features.”

Another one: don’t use “The current implementation isn’t elegant” to show off your technical purism. Instead, say: “Every release requires manually changing configuration, and we’ve almost made mistakes twice. If we switch to an automated process, we can reduce this manual dependency and integrate it into the pipeline, so deployment is one click.”

We’re not exaggerating the consequences of technical debt; we’re translating “engineering pain” into “organizational cost.”

Let your boss see: “This isn’t about you being dissatisfied with the code; it’s about the company taking unnecessary risks.” Then he’ll naturally listen to how to solve it.

3. How to choose: Not everything, but prioritize high risk + high return Technical debt can never be fully paid off.

So what you repay isn’t the most annoying debt, but the one most likely to blow up and with the biggest payoff once fixed.

You can evaluate technical debt priority using two dimensions:

The first is the technical debt quadrant mentioned above (Martin Fowler’s model).

This helps clarify responsibility and governance: Was it a conscious trade-off or a lack of awareness? Can it be planned for repayment, or is it only temporary patching?

The second is the practical Effort × Impact tool (x-axis is Effort, y-axis is Impact) (thanks to @Angeline for providing this framework).

[[Effort-Impact 工具.png]] Judgment criteria can include: Does someone step on this landmine every month? (Repeated real-world cost) Does every release require changes here? (Directly affects development efficiency) Would fixing it unlock engineering bottlenecks? (Makes the system more extensible or testing simpler) Is it likely to cause security or data issues? (Uncontrollable negative organizational impact) The truly high-priority technical debt is often the kind where:

Resolution cost is low, but risk is huge and benefits are obvious.

The technical debt that really convinces your boss isn’t the one you can’t stand looking at; it’s the one that will cause trouble if not fixed soon.

4. How to change: Don’t rely on individual heroics; rely on mechanisms Some teams have technical debt piled up for three years with no one touching it, while others make refactoring a regular process.

What’s the difference?

It’s whether debt repayment has become an organizational mechanism rather than relying on someone’s conscience.

You can create a technical debt register. No fancy tools needed—a shared document is enough. Write clearly: problem description; risk level (high/medium/low); whether a workaround exists; recommended resolution time and potential benefits.

Hold a debt review meeting with your boss. Just as product teams set roadmaps, technical teams can do a monthly engineering health review, focusing on only 1–2 points most likely to cause problems.

Use a debt sprint mechanism. Make debt repayment a predictable, supported development cycle, such as scheduling 1–2 weeks per quarter for dedicated debt repayment, or doing one or two cards per sprint. As long as it’s done rhythmically, bosses generally won’t object.

You can also include technical debt in performance metrics. Many bosses don’t support debt repayment because they can’t see results. If you can quantify it—e.g., “reduce ticket handling time,” “lower feature error rate,” “improve release efficiency”—you can gradually build organizational trust.

5. You’re changing the system, but also the culture Technical debt won’t disappear overnight, but how a team treats it reveals the organization’s engineering maturity.

Do they turn a blind eye and take the blame when something breaks?

Or do they continuously review and institutionalize debt repayment?

Is it “whoever finds it is responsible”?

Or is engineering quality the responsibility of the whole team?

Change is never about slogans; it’s about whether we move from writing code to building systems.

Even if today we can only repay one debt, as long as its value is recognized by the organization, tomorrow it will be easier to repay one more.

When your boss can say, “This risk should be addressed,”

and when product managers proactively ask, “Will this release increase technical debt?”

we have truly moved from fixing bugs to managing systems.

Next time you talk about technical debt, try a different approach: This isn’t my personal dissatisfaction; it’s a risk the organization is facing. We can control it with more robust methods. It’s not about complaining; it’s about building mechanisms. It’s not about repaying everything; it’s about selective repayment. It’s not about waiting for a blowup; it’s about proactive governance. You’ll find that the wall between engineers and bosses can actually be dismantled.