I once spent forty minutes explaining cyclomatic complexity to a VP of Sales. He nodded politely, then asked if we could just hire more offshore developers to "type faster." That's when I realized the problem wasn't him, it was me.
The project was a legacy order management system. Every release took six hours because of brittle database migrations. On-call engineers spent weekends restarting services that died under modest load. We estimated the team lost fifteen hours a week to incidents, but when I asked for a code freeze to pay down debt, the CFO asked what features we'd ship instead. I said none immediately. She said no.
I stopped using the phrase technical debt altogether. Instead I mapped every piece of debt to a business outcome. Not "we need to refactor the payment module" but "if we don't replace this thirty-year-old credit card integration by March, the bank is ending support and we'll lose the ability to process renewals." Suddenly the conversation was about revenue at risk, not code quality.
In another case, I framed the debt as an insurance premium. Every week spent on manual fixes was money we weren't investing in the roadmap. I showed them a simple chart: hours spent fighting incidents over the last quarter against hours spent building features. The dip was undeniable. They approved a two-month stabilization sprint, not because they cared about clean architecture but because they saw the cost of not doing it.
The hardest part was avoiding the urge to be right. I wanted to convince them that good engineering mattered. Instead I learned to ask what they were afraid of. A director of operations once told me she didn't care about the codebase but she did care about not getting paged at 3 a.m. when the warehouse scanners went down. So I tied the debt to her pager. That worked.
Now when I sit across from a stakeholder, I don't talk about debt at all. I talk about the risks they'll feel, the quarter they'll miss, the customer call they'll have to make. It's not lying, it's translation. And honestly, the best engineers I know are the ones who can do both.