Technical debt isn’t a bug—it’s a FinOps feature in 2026. Time to treat it as strategic sabotage.
Nobody wakes up and decides to build a slow, expensive system. I mean that. In twenty-plus years of working with enterprise technology teams, I have never once met a group that said, “Let’s build something that breaks constantly, costs a fortune to run, and makes everyone miserable.” It doesn’t work that way.
Here’s what actually happens. I tell this story all the time because it plays out in every organization I’ve ever worked with.
Two teams get greenlit to build new applications. Same company. Same budget class. Same caliber of talent. Day one, both teams are fired up. They design the architecture. They pick their stack. They staff up. They have the same intention—build something amazing. High performance. Five nines. Scales beautifully. The kind of application you’re proud to put your name on.
Both teams start building. Both promote to production.
And then, somewhere around month six, the stories diverge.
One application is humming. Daily releases. Scaling smoothly. The infrastructure footprint is lean—maybe half of what was originally forecasted. The team is engaged. People want to work on it. It becomes the reference project inside the company. “Why can’t everything run like App A?”
The other application? It’s a different world. Release cycles are slow and painful. Outages creep in. Stability is a constant conversation. Performance degrades as load increases. The on-call rotation becomes a punishment. Engineers start asking to transfer off the team. Nobody wants to own it. And leadership starts asking hard questions about why this thing costs so much to keep alive.
Here’s what kills me. Both teams started with the same intentions and the same talent. So what happened?
The difference isn’t the people. It’s the thousands of small decisions made under pressure between day one and production—and every day after. One team had discipline around design reviews, code quality gates, and performance testing before deployment. The other team—maybe they were under more deadline pressure, maybe they had a PM who pushed “just ship it,” maybe they cut corners on the data layer because it was “good enough for now”—made compromises. Small ones. Reasonable ones, even, in the moment.
But those small compromises compound. Fast. A query that runs fine with 10,000 rows becomes a disaster at 10 million. A shortcut in the data model that saved two weeks of development creates years of workarounds. A missing index that nobody notices until Black Friday. One percent of the code ends up consuming ninety percent of the resources and costs. Not because anyone planned it that way. Because nobody was measuring it along the way.
This story plays out everywhere. SQL Server, Postgres, Oracle, cloud-native, hybrid, on-prem—doesn’t matter. The technology changes. The pattern doesn’t.
The Treadmill Nobody Sees
Everyone sees the problem. The engineers know. The DBAs know. The infrastructure team definitely knows—they’re the ones getting paged at 2 AM. But when it comes time to actually fix it, the conversation stalls.
Why? Because fixing the past doesn’t look like progress to the people who control the budget.
The CFO and the executive team are focused on this year’s ROI. This quarter’s numbers. That’s their job, and I don’t fault them for it. But when a technical leader walks into that room and says, “We need to invest in refactoring legacy code,” what leadership hears is: “We want to spend money on something that won’t generate revenue.” And honestly, the way most of us frame it, they’re not wrong.
Nobody wants to touch an application unless it’s broken, out of capacity, or can’t scale to support the business. If it’s running, it’s “fine.” Except it’s not fine. It’s expensive, it’s fragile, and it’s getting worse every single day because data grows, transactions increase, and that quick fix from 2019 is now operating in a completely different world than the one it was built for.
So teams just keep running on the treadmill. They spend 400 hours fixing a critical performance issue caused by years of accumulated tech debt. They celebrate. They move on. And then the next sprint, a new feature goes live with the same lazy patterns that caused the problem in the first place—and they’ve just offset everything they fixed. No gates. No guardrails. No one asking “what does this cost to run at scale?” before it hits production.
The tech debt you just paid down gets replaced by new tech debt before the invoice is even dry.
Stop Speaking Technical. Start Speaking Money.
The reason this cycle never breaks isn’t technical. It’s linguistic. We are talking to business leadership in a language they do not speak.
We say, “This query is doing 2 million logical reads per execution.” They hear nothing. That sentence has zero meaning to a CFO. Zero meaning to a product leader. Zero meaning to anyone who isn’t elbow-deep in execution plans.
But what if we reframed it? What if instead we said: “Three issues in your core transaction system are costing you $500K this year in excess infrastructure and lost throughput. Give us 400 hours to resolve them, and you recover that in year one. In year two, because of transactional and data growth, the savings compound to $600K-plus. And you unlock 40% more processing capacity—which means you can handle more revenue without a hardware refresh or a cloud spend increase.”
That’s a different conversation. That’s not an engineering request. That’s a business case. That’s something a CFO can approve before lunch.
The technical problem didn’t change. The language did. Milliseconds became dollars. Query plans became ROI. And suddenly, fixing the past looks like an investment, not a cost.
This is why I keep beating the drum on FinOps for data. Not because it’s a buzzword. Because it’s the only framework that forces us to translate technology problems into the one language every single person in the organization understands—money.
We all understand the value of a dollar. Nobody outside of IT understands the value of a CPU cycle. And yet we keep presenting our biggest challenges in technical terms and then acting surprised when leadership won’t fund the fix.
The business drives decisions on features, product roadmap, and priorities. That’s how it should be. But if we can show them—clearly, in simple terms—the capacity, the health, and the financial opportunities sitting inside their systems, the entire dynamic changes. We stop begging for refactoring budget and start presenting investment cases with measurable returns.
“You want to reduce COGS by 15%? Here’s the path. Three issues. 400 hours. Half a million back in year one. More in year two. And enough headroom to support your growth plan without adding infrastructure.”
But here’s the thing—and this is where I’ll challenge the “shift left” crowd a little bit. Yes, absolutely, shift left. Catch problems early. Build efficiency into the design phase. Gate bad code and bad designs before they hit production. All of that matters, and we should be doing more of it.
But most of the damage is already done. The biggest costs sitting in your environment right now aren’t from code you haven’t written yet. They’re from decisions made years ago that compound daily. Shifting left solves tomorrow’s problem. You still need a strategy for yesterday’s. And that strategy has to be financially framed, or it will never get prioritized.
The two-teams story I started with? The struggling application doesn’t have to stay that way. But it will—as long as we keep treating tech debt as a technical problem instead of what it actually is: a financial problem with technical symptoms.
The organizations that figure this out will pull ahead. Not because they have better engineers. Because they have better visibility into what their technology actually costs, and they can make decisions accordingly.
Everything has a cost—from code to data. The question is whether you’re measuring it, or just hoping for the best.
I know which one most enterprises are doing today. And that’s exactly the trap.
About the Author
Ben DeBow is the CEO and Founder of Fortified and the author of “End of Abundance in Tech” (Forbes Books, 2023). He speaks regularly on FinOps for Data and the financial impact of technology decisions across enterprise environments.
Learn more at BenDeBow.com