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.

Navigating Complexity: A Practical Approach to Technical Debt Discussions

Technical debt discussions can often feel fraught with emotion – a perceived judgment on past decisions, anxieties about future impact, or simply difficulty articulating the value of addressing it. The key is shifting from “who’s to blame” to “how do we move forward constructively.” Framing technical debt not as a failure but as an investment opportunity – recognizing that short-term expediency often leads to long-term cost – significantly alters the dynamic. Instead of accusatory language (“You left us with this”), focus on collaborative problem-solving (“How can we best address these accumulated complexities?”) and quantifying potential risks.

Specifically for non-native speakers, mastering phrases related to prioritization and trade-offs is crucial. Instead of directly translating a potentially negative statement like “this code is messy,” consider phrasing like “This area presents some technical complexity that warrants further investigation” or “We’ve identified areas where refactoring could enhance maintainability and reduce potential future risk.” Similarly, when discussing scope creep, avoid simply saying “this isn’t the right priority.” Instead, frame it as: “Given our current sprint goals and resource constraints, prioritizing this feature would require a significant shift in focus and potentially introduce technical debt into other areas.” Active listening and paraphrasing are also essential – ensuring you fully understand the concerns of others and clearly articulating your own perspective. Don’t be afraid to ask clarifying questions (“Could you elaborate on what aspects you find challenging?”) to demonstrate engagement and understanding. Remember, clear communication reduces misunderstandings and fosters a more productive discussion.

Furthermore, introduce the concept of “technical debt repayment” as a strategic investment rather than an admission of fault. Frame it as proactively mitigating future risks – just like financial investments, addressing technical debt now can prevent significantly larger problems down the line. This reframing helps to normalize the conversation and encourages stakeholders to see it as a valuable contribution to the project’s long-term success. Finally, consistently use data – metrics around bug frequency, code complexity, or developer time spent on rework – to support your arguments for addressing technical debt. Numbers speak louder than opinions.

# Example: Using `SonarQube` CLI to analyze code quality and identify issues

sonar-scanner -Dsonar.projectKey=my_project -Dsonar.sources=. -Dsonar.hostUrl=http://localhost:9000

This simple command demonstrates a tangible approach – using a tool (SonarQube) to objectively measure the technical debt and provide concrete evidence for prioritization decisions. It shifts the focus from subjective judgments to data-driven recommendations, which is universally understood and appreciated within professional settings. Remember to always tailor your language and approach to your specific audience – adapting your communication style based on their background and level of technical understanding will significantly improve the effectiveness of your discussions around technical debt.