I remember the exact moment I lost a negotiation about technical debt. It was a steering committee meeting, and I had prepared a beautiful slide deck explaining why our legacy order processing system needed a major refactor. I used words like monolith, coupling, cyclomatic complexity. The VP of Sales interrupted me halfway through and said, look, I don't care about your code words. Can we launch the new discount engine next month or not? I said yes, we could, because I didn't want to be the blocker. Six months later, the system crashed on Black Friday. That was a hard lesson.
What I didn't understand then is that non-technical stakeholders don't see technical debt as a problem to be solved. They see it as an excuse for not shipping features. And honestly, sometimes we engineers hide behind jargon to avoid making hard calls. The turning point for me came when I started translating technical debt into three things every business person understands: speed, risk, and money.
Speed is the easiest to explain. I stopped saying refactor and started saying this part of the codebase is like a road with twenty traffic lights. Every new feature has to stop at each one. If we take a week to remove some of those lights, future features will ship twice as fast. I had a real example from a billing module we were working on. Adding a simple field to an invoice used to take two days because the logic was tangled across three services. We spent five days untangling it, and the next field took four hours. I showed that graph to our product owner. She got it immediately.
Risk is the next lever. I once told a CFO that technical debt is like driving with bad brakes. You can ignore it for a while, but eventually you'll hit something expensive. The company had just survived a production outage caused by a single line change in a fragile authentication service. That outage cost us about forty thousand dollars in lost orders and support time. When I framed the cleanup as an insurance policy against the next outage, suddenly the budget conversation changed. We didn't get everything we asked for, but we got enough to start.
The third lever is people. I've seen good developers quit because they were forced to work in a codebase that felt like a swamp. I told our leadership that every month we delay paying down debt, we add two weeks to the onboarding time for a new hire. That's a cost they can calculate. We had a junior developer spend three weeks trying to understand a legacy module that should have taken three days. That story landed better than any architecture diagram.
I still lose negotiations sometimes. The business will always want features over maintenance. That's their job. My job is to make the cost of ignoring debt visible in a language they can hear. I don't talk about clean code anymore. I talk about delivery speed, outage risk, and employee retention. Those are numbers on a spreadsheet. And numbers don't need a computer science degree to understand.