I used to think technical debt was a universal language. I was wrong.

Early in my career, I walked into a quarterly planning meeting with a beautiful spreadsheet. I had rows and rows of code quality metrics, cyclomatic complexity scores, test coverage percentages, and a color-coded risk matrix. I was proud of it. I presented it for ten minutes. The VP of Product nodded politely, then turned to the next agenda item — a feature request from the biggest customer.

That feature shipped two months late. Not because the team was slow, but because we spent half that time fighting a brittle authentication system I had flagged in that same meeting. When I brought it up afterward, the VP said something I've never forgotten: "You showed me a lot of numbers, but you never told me it would delay the customer feature."

That was the moment I realized technical debt isn't a technology problem. It's a communication problem.

The trick isn't dumbing things down. Non-technical stakeholders are smart — they run P&Ls, negotiate contracts, and make billion-dollar decisions. The trick is translating technical risk into business vocabulary. Instead of saying "we need to refactor the payment module," say "the payment module has a 30 percent chance of failing during Black Friday traffic, and fixing it costs one sprint." Instead of "our test coverage is low," say "every deploy has a one-in-five chance of breaking the checkout flow, which means we can't ship that new pricing page without hiring a QA contractor."

I started building what I call a debt register — a simple spreadsheet with three columns: what breaks if we don't fix it, how much that break costs in lost revenue or support tickets, and how many engineering days the fix requires. No architecture diagrams. No code smells. Just cause, effect, and cost.

The first time I presented this, the CFO asked one question: "If I give you two sprints to fix this, what's the guarantee it won't break again?" I didn't have a good answer. I learned to add a fourth column: how long the fix lasts. Some debt is one-and-done. Some buys you a year of stability. Being honest about that builds trust.

Here's what still surprises me: sometimes the hardest sell is a small, cheap fix. I once spent an hour convincing a product manager to let us spend two days upgrading a library that had a known security vulnerability. She pushed back because the feature she wanted was three days of work. I finally asked her: "If this gets exploited, how many weeks will we spend firefighting instead of building your feature?" She approved it immediately.

I've made plenty of mistakes along the way. I've overestimated how long a refactor would take and lost credibility. I've underestimated the cost of a quick hack and watched it compound for years. I once sold a six-month rewrite as "eliminating technical debt" — that project was cancelled after three months because we couldn't show any user-facing value.

The best lesson I've learned is to never lead with the word "debt" in a meeting with non-technical stakeholders. That word implies obligation and negativity. Instead, I lead with the business outcome: "I want to make sure we can ship features faster next quarter, and there's a bottleneck in our data pipeline that's adding two days to every release." Framed that way, we're not arguing about whether to pay down debt. We're deciding how to invest in speed.

And honestly, that's the whole game. Not convincing people to care about code quality. Just showing them how it affects the things they already care about.