"We need to refactor this code."
Blank stares.
"The architecture is getting messy."
More blank stares. (Even a hint of 'leave me alone, we have features to ship.')
"If we don't address this technical debt now, it'll slow us down later."
Polite nods. Then: "Can we just ship this feature first?"
I've had this conversation more times than I can count. And for years, I blamed the product managers.
They don't get it. They only care about features. They're ignoring the foundation while demanding we build another floor.
Then I realized: they weren't the problem. My communication was.
The Translation Gap
Here's what I was saying: "We need to refactor this code because the architecture is getting messy and technical debt is accumulating."
Here's what they heard: "I want to spend two weeks making things prettier instead of building what customers asked for."
We were speaking different languages. I was talking about code quality. They were thinking about customer value, revenue, and roadmap commitments.
Neither of us was wrong. We just weren't connecting.
The Moment Everything Changed
I was in yet another meeting trying to explain why we needed to pause feature work to address technical debt.
The product manager's eyes were glazing over. I could see her mentally calculating how to politely end this conversation.
So I stopped mid-sentence and tried something different.
"Imagine you just cut half your finger off. You could properly clean it and put on a bandage, or you could just ignore it. What happens if you keep ignoring half cut off fingers?"
She looked at me like I'd lost my mind. But then she got it.
"They get infected."
"Exactly. And eventually, you can't use that hand at all. That's what technical debt does to our codebase."
Suddenly, we weren't debating code architecture. We were discussing wounds that fester, infections that spread, and hands that stop working.
Technical debt became something she could visualize. And visualization creates urgency.
Why Technical Jargon Fails
- When we say "refactoring," non-technical stakeholders hear "optional polish."
- When we say "technical debt," they hear "developers want perfect code."
- When we say "architecture," they hear "abstract concerns that don't affect users."
We're not wrong to use these terms with each other. But with stakeholders who measure success in features shipped, revenue generated, and customer satisfaction scores, we need a different vocabulary.
Not because they're less intelligent. Because they're optimizing for different outcomes.
A product manager isn't ignoring technical debt out of malice.
They're focused on:
- Delivering promised features to customers
- Meeting revenue targets
- Staying ahead of competitors
- Keeping stakeholders happy
And "we need to refactor" doesn't map to any of those goals. So we need to show them how it does.
Building the Bridge
The change isn't about dumbing things down, rather it's about finding shared language.
Here are the metaphors that have worked for me:
The Band-Aid on an Infected Wound
Every quick fix is a band-aid over a cut we didn't properly clean. Every shortcut is like painting over a crack in the wall instead of fixing the foundation.
At first, it looks fine: the wall looks painted, the cut is covered.
But band-aids fall off. Paint peels. And what's underneath is worse than when you started.
Why it works: Everyone understands infections get worse when ignored. Nobody argues with "this will get infected."
The Cracked Foundation
You can keep building floors on a cracked foundation. And for a while, it'll hold. But every new floor adds pressure. The cracks spread. And one day, the whole thing collapses—right when you need it most.
Why it works: It connects technical decisions to risk management, something every business leader thinks about.
Speaking Their Language
Metaphors help, but you know what really works? Translating consequences into business language.
Instead of: "This code is hard to maintain."
Try: "Every new feature in this area takes 3x longer because of how it's structured. That's 20 extra hours per sprint we could be spending on new features."
Instead of: "We have technical debt here."
Try: "This is costing us $15,000 in developer time every quarter. If we invest two weeks now, we'll save that every quarter going forward."
Instead of: "The architecture is messy."
Try: "Our bug rate in this module is 4x higher than elsewhere.
Customers are reporting issues every week. We can fix that, but it requires addressing the underlying structure."
Hours lost. Money wasted. Bugs multiplying. Velocity decreasing.
These are metrics stakeholders understand. These create urgency.
The Conversation That Actually Works
Here's the framework I use now:
- Acknowledge their priorities: "I know we need to ship Feature X by end of quarter. That's important."
Don't start with opposition. Start with alignment.
- Connect technical debt to their goals: "The problem is, the area where we need to build Feature X is really unstable. We're seeing bugs there every week, and each change takes twice as long as it should."
Show how the technical problem affects their goals, not yours.
- Quantify the cost: "Right now, we're spending about 10 hours every sprint just working around the issues in that module. That's half a developer's time."
Make the invisible visible. Give them numbers.
- Propose the investment and ROI: "If we spend one week cleaning this up, we'll cut that time in half. Plus, Feature X will be faster and more stable to build."
Frame it as an investment with clear returns, not a cost.
- Give them the choice: "We can either address it now and move faster after, or keep working around it and accept that every feature in this area will take longer. What makes more sense given our priorities?"
Empower them to make the decision with full information.
🛠️ How to Apply This
Before the next technical debt conversation:
- Identify the business impact. What's the cost in time, money, or risk? If you can't articulate this, you're not ready for the conversation.
- Choose your metaphor. What will resonate with this specific person? Financial types respond to debt and interest. Product types respond to velocity and risk.
- Quantify everything you can. Hours, dollars, bug counts, velocity changes. Numbers create urgency.
- Prepare the ROI. What's the investment? What's the return? How long until it pays off?
During the conversation:
- Start with their goals, not yours. "I know shipping Feature X is critical..."
- Connect technical to business. Show how the technical problem blocks their goals.
- Give options, not ultimatums. "We can address it now and move faster after, or keep working around it. What makes sense given our priorities?"
- Be honest about trade-offs. Every choice has costs. Acknowledge them.
After you get buy-in:
- Deliver what you promised. If you said it would take one week, take one week. Trust is built through follow-through.
- Measure the impact. Did velocity improve? Did bugs decrease? Share these wins.
- Reinforce the connection. "Remember when we cleaned up Module X? That's why we shipped Feature Y so fast."
The Deeper Skill
Here's what I wish someone had told me earlier: Cross-discipline communication is a core engineering skill.
Not a soft skill. Not a nice-to-have. A core skill.
The best engineers I know aren't just technically excellent. They can translate technical concerns into business value, design implications, or user impact.
They understand that:
- Backend engineers need to talk to frontend in terms of API contracts and data flow
- Frontend engineers need to talk to designers in terms of interaction patterns and constraints
- Everyone needs to talk to product in terms of customer value and business outcomes
Finding the bridge between disciplines isn't about compromising your expertise. It's about making your expertise relevant to people who optimize for different outcomes.
🤔 Questions to Reflect On
When's the last time you tried to explain a technical problem and got blank stares? What language were you using?
What metaphors resonate with your specific stakeholders?
Are you quantifying the business impact of technical decisions, or just hoping people trust you?
How often do you start technical debt conversations with stakeholder goals vs. engineering concerns?
The Bottom Line
Technical debt will bite us in the ass. But saying that to stakeholders won't create urgency.
Band-aids on infected wounds will. Credit card interest will. Cracked foundations will.
Every quick fix is a band-aid over a cut we didn't properly clean.
Every shortcut is like painting over a crack in the wall instead of fixing the foundation.
At first, it looks fine. But band-aids fall off. Paint peels. And what's underneath is worse than when you started.
Your job isn't just to identify technical debt. It's to make non-technical people care about it as much as you do.
And that starts with speaking their language.
Photo by charlesdeluvio on Unsplash
Top comments (17)
Well, yeah, speaking to business stakeholders about the cost of technical debt will sometimes get a reaction. Unfortunately, those who recognize technical debt when they see it rarely get to speak with business stakeholders. Instead they talk to middle managers who do not know, do not want, or are afraid to talk to business stakeholders about technical debt in a language they will understand.
The sad truth is that no one talks about technical debt, disaster recovery exercises, monitoring, or "high availability" until something happens.
"Nothing good happens...until something bad happens."
@rob_lauer_d8a575ed546516e You're describing the real problem: the translation gap happens at multiple layers.
I can speak business language to stakeholders all day, but if middle management filters everything through "don't make waves" or "I don't understand this enough to champion it," the message dies there.
A few things I've seen work:
You're right that most places wait for the disaster. But the teams that don't? They've built the communication bridge at every level, not just the top.
What's worked for you when middle management is the blocker?
Haha, 100%! I even wrote about it yesterday on my page: dev.to/sylwia-lask/its-not-the-pro...
I agree — communication is the key here.
Awesome, thanks for sharing @sylwia-lask I will definitely read it!
Just bundle everything into feature estimate.
If you are discussing whether they will "allow" You to address technical debt, You are either being micro-managed or You are inviting them to micromanage You.
My approach is to bring the complete package (refactoring included) to the discussion on budget and deadlines. If someone even bothers to scrutinize it (which is not the usual case), I have a followup question about expected failure rate and SLAs...
Smart approach @peter_truchly_4fce0874fd5 !
Building it into the estimate treats quality as part of delivery, not an optional extra. That SLA question cuts through the noise—it makes the tradeoff explicit. They can have it faster with higher failure rates, or invest the time upfront for stability.
How do stakeholders typically respond when you frame it around failure tolerance? Do they engage with the question, or does it usually just validate your original timeline?
I think it is mostly hidden that way. We are mostly talking about people who are going from one meeting to the next, all they want to hear is whether it will be done and at what cost/timeframe. If it is not way over budget it will pass. IMO this kind of professionalism in IT is often questioned and downplayed (or even absent sometimes?), but nobody is going to question legal, HR or a doctor when they are following their best practices and standard procedures.
Great article. I have also had this discussion many times and thought I was explaining it as best as I could, but tech jargon does not resonate with the decision makers.
I recently found this image and it also helps a lot to describe the lasting effects of technical debt.
Thanks for sharing @tinussmit , this is really valuable!
Great breakdown love how you turn technical debt into something tangible and relatable. Clear, practical framing that actually bridges the communication gap.
Most people outside engineering don’t ignore technical debt on purpose—they just can’t see the pain we see every day. What actually works for me is skipping all the fancy jargon and talking in simple, practical terms they already care about: time, money, bugs, and delivery speed.
Exactly @carl231! That's the whole point: translate the invisible into what they already measure.
The hardest part isn't finding the right words, but it's remembering to use them consistently instead of defaulting to developer speak when we're frustrated.
How do you gather and use those metrics (time, bugs, etc.)?
Really on point here. I’ve learned the hard way building AI‑orchestrated systems that technical debt isn’t just a dev problem, it’s a systemic risk. When agents rely on brittle interfaces, sloppy abstractions, or unclear data flows, you don’t just break a module, you break the orchestration layer, and then you’re paying in reliability, auditability, and cost.
Getting non-technical stakeholders to care means translating that risk into something tangible: higher latency, more failures, more support incidents, and ultimately slower feature delivery. When they understand that “refactor now” isn’t a selfish developer ask, but a way to protect the whole system’s agility, they become your ally.
At the end of the day, debt is a bet, but one you don’t want to lose when your AI agents are supposed to be doing the thinking for you.
@guypowell You've hit on something crucial with AI-orchestrated systems: the "blast radius" of technical debt expands dramatically.
In traditional systems, messy code slows down one team. With AI agents relying on those interfaces and data flows, the fragility compounds across every orchestration layer. One brittle abstraction doesn't just break a feature, it cascades through every agent interaction that depends on it.
The business case writes itself: higher support volume, unpredictable latency, debugging that takes days instead of hours, and agents that can't be trusted because the foundation underneath is unstable.
What's interesting is how quickly this becomes visible. Traditional tech debt can hide for years. With AI orchestration, it surfaces immediately in reliability metrics and agent behavior.
Are you finding stakeholders respond differently when the failure shows up in agent performance versus traditional system performance?
Makes Sense.
نعم
Some comments may only be visible to logged-in visitors. Sign in to view all comments.