How to Discuss Technical Debt in a Meeting

Technical debt is one of the most important topics a development team can discuss — and one of the hardest to communicate clearly, especially in English. The challenge is twofold: the concept itself is abstract, and the conversations often involve both technical and non-technical stakeholders. Getting the language right means the team can make informed decisions instead of deferring problems indefinitely.

What Is Technical Debt and Why Does Talking About It Matter?

Technical debt refers to the implied cost of rework caused by choosing an easy, short-term solution over a better, longer-term approach. It accumulates gradually, and if never discussed openly, it quietly slows down delivery, increases bug rates, and demoralises engineers.

Raising the topic effectively in English requires you to be precise, constructive, and outcome-focused. Vague complaints like “the code is bad” rarely lead to action. Specific, structured observations do.

Key Vocabulary

• Technical debt — the accumulated cost of shortcuts in code or architecture
• Interest — the ongoing slowdown caused by existing debt (borrowed from finance)
• Refactoring — improving internal code structure without changing external behaviour
• Legacy code — older code that is difficult to maintain or extend
• Code smell — a symptom in code that suggests a deeper problem
• Hotspot — an area of the codebase that is frequently changed and prone to bugs
• Accrued debt — debt that has built up over time without being addressed
• Paying down debt — the act of refactoring or replacing poor solutions

Raising Technical Debt in a Sprint Planning Meeting

Sprint planning is one of the most natural places to bring up technical debt. You need to frame it as a business risk, not just a technical concern.

Opening the Conversation

Use these phrases to introduce the topic without sounding like you are just complaining:

• “Before we commit to this sprint, I want to flag some technical debt that could slow us down.”
• “There’s accrued debt in the payment module that’s starting to affect our velocity.”
• “I’d like to propose we allocate some capacity this sprint to address a hotspot in the authentication layer.”
• “We’ve been carrying a short-term solution in this area for three sprints now — it’s generating more bugs than expected.”

Quantifying the Impact

Abstract debt is easy to dismiss. Concrete numbers are much harder to ignore.

• “We’re spending roughly 30% of our debugging time on issues that originate in this module.”
• “Every time we touch this service, we introduce at least two unintended regressions.”
• “The current architecture means adding a new payment provider takes four days. With the refactor, it would take under half a day.”

Discussing Technical Debt With Non-Technical Stakeholders

Product managers and business stakeholders often struggle to understand why invisible code problems deserve time on the roadmap. You need to translate technical reality into business language.

Using the Financial Metaphor

The “debt” framing was designed precisely for this. Use it explicitly:

• “Think of it like a loan we took out to ship faster. Now we’re paying interest every sprint in the form of slower development and more defects.”
• “We borrowed time by cutting corners six months ago. We’re now repaying that loan at a higher rate than expected.”
• “If we don’t pay down this debt now, the interest will compound and make future features significantly more expensive.”

Proposing a Concrete Plan

Stakeholders respond better to proposals than to problems. Always pair the problem with a solution:

• “I’d suggest dedicating 20% of each sprint to debt reduction over the next quarter.”
• “We’re proposing a one-week refactoring sprint before we begin the new feature track.”
• “The ask is two developer-days to clean up the data layer. The payoff is that the next three features in this area will be delivered significantly faster.”

Handling Pushback

Not everyone will welcome the news that technical work needs to slow down. Prepare for resistance.

Common Objections and Responses

“Can’t we just do it later?” “We’ve said that for the last three sprints. The debt is now actively slowing us down. Later is now.”

“How much will it cost?” “The refactoring itself is estimated at five story points. Continuing without it will likely cost us fifteen or more points of rework over the next two sprints.”

“Is it really that urgent?” “It’s not an emergency today, but it is a risk. If we leave it another month, we’re looking at a significant rewrite rather than a targeted fix.”

Useful Phrases for Technical Debt Conversations

Keep these phrases ready for different meeting contexts:

• “I want to surface a risk before we plan this feature.”
• “This is an area of the codebase we’ve been avoiding — it needs attention.”
• “The technical cost here is higher than the story points suggest.”
• “We need to have an honest conversation about sustainability.”
• “I’d recommend we treat this as non-negotiable capacity in the next sprint.”

After the Meeting: Following Up

Once you have secured agreement to address debt, document it clearly. A written record prevents the commitment from disappearing.

• Write a brief summary of what was agreed: “Team agreed to allocate 15% of Sprint 34 to refactoring the order service.”
• Add a ticket or epic to the backlog so it remains visible.
• Review progress at the next retrospective with language like: “We committed to reducing debt in this area — let’s check whether that’s reflected in our defect rate.”

Talking about technical debt fluently and confidently is a professional skill. The teams that do it well deliver more consistently, build more trust with stakeholders, and create healthier engineering cultures.