"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 ...
For further actions, you may consider blocking this person and/or reporting abuse
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.
نعم