I once worked with a company just over 50 years old in Sarasota, Florida. They'd been trying to get a budget approved for cloud migration for years. Every budget cycle, same request. Every time, deprioritized.
We were on a call discussing upgrades to their technology stack when I discovered all of their data was still stored in a server bank on location in Sarasota.
I looked at the head of the department and said, bluntly: "You're one hurricane away from losing all of your data."
Something about that comment made a difference.
Why the Technical Case Didn’t Land
For years, they'd been presenting the technical case. Performance bottlenecks. Scalability concerns. Maintenance costs. Disaster recovery protocols.
All true. All important. None of it landed.
My comment landed because it translated technical risk into a reality they could visualize.
They understood catastrophic loss. They understood "everything we've built in 50 years could disappear."
The technical case was always sound. But it was presented in technical language to people who evaluate in business terms.
"We need to migrate to the cloud for better disaster recovery" sounds like an IT project.
"You're one hurricane away from losing 50 years of customer data, financial records, and operational history" sounds like an existential threat.
What Changed With One Sentence
- The technical case had been presented for years - performance, scalability, maintenance costs, disaster recovery.
- Every budget cycle, same data. Every time, deprioritized.
- Leadership would nod, ask questions, then say "let's revisit next quarter."
- The technical language sounded like excuses: "We don't have the resources" translated to "we're not capable."
- One sentence grounded in reality landed where years of technical documentation didn't.
This is a translation layer problem.
Why Constraints Sound Like Excuses
When you say "We need to upgrade the database infrastructure because performance is degrading," they hear "We want to spend money on something that currently works."
When you say "We don't have the resources for this," they hear "We're not capable."
Technical constraints sound like excuses when they're not translated into language leadership can act on.
It's not that they don't care. It's that they don't understand the constraints well enough to see them as valid.
How Executives Evaluate Reality
A CFO thinks in financial terms - conservatism, budget integrity, ROI, risk exposure. Technical debt means nothing to them. But "compound interest on a loan that's only being paid at the interest level, never touching principal" - that they understand.
A COO thinks in operational terms - uptime, capacity, throughput, bottlenecks. "Performance degradation" is vague. But "we're operating at 85% capacity with no room for growth without degrading service levels" - that's concrete.
The issue isn't your technical expertise. You're speaking SQL. They're deciding in P&L.
You feel like the only adult in the room. Like you're misunderstood, underappreciated. You start questioning whether they're listening or if they just don't get it.
But they're not stupid. They're operating in a different mental model than you are. And without translation, your technical reality doesn't map to their business reality.
Authority is created when complexity arrives compressed and translated into language they can act on.
"One hurricane away from losing 50 years of data" compressed technical risk into business language (catastrophic loss, existential threat, measurable impact).
That's why it landed.
The Translation Shift
After that call, I started paying attention to how different executives processed information.
The CFO responded to financial risk language - ROI, cost avoidance, exposure. The COO responded to operational language - capacity, throughput, service levels. The CEO responded to strategic language - competitive position, market risk, growth enablement.
When I needed budget for something, I stopped leading with the technical case. I started by understanding who I was talking to and what mental model they operated from.
Examples of Translation That Gets Funded
A security upgrade wasn't "implementing zero-trust architecture." It was "reducing our exposure to the kind of breach that cost [competitor] six figures in remediation and reputation damage."
A cloud migration wasn't "modernizing infrastructure." It was "eliminating the single point of failure that puts 50 years of business continuity at risk."
A refactoring project wasn't "addressing technical debt." It was "removing the bottleneck that's limiting our ability to ship features 40% faster than we do today."
Everybody loves percentages. Everybody loves to understand risk and probability - in terms they can relate to.
Catastrophizing doesn't work. Concrete risk does. Grounding it in something practical and measurable - "40% faster," "85% capacity with no headroom," — almost always gets their attention.
Same work. Different translation.
Some requests still got deprioritized. But when they did, it was because the business priority genuinely wasn't there - not because they didn't understand what I was asking for.
The technical case was always part of the conversation. But it became the supporting evidence, not the opening argument.
The Real Reason Budget Gets Stuck
When you can't get a budget for what you know needs to be done, it's rarely because leadership doesn't trust your judgment.
It's because the technical case isn't translating into business language they can act on.
Technical constraints sound like excuses when they're not grounded in terms leadership understands - risk, capacity, competitive position, ROI, measurable impact.
The issue isn't your expertise. It's the translation layer.
For tech leaders: before your next budget request, identify who you're presenting to and what mental model they operate from. Then translate your technical reality into their business language - percentages, probabilities, relatable risks.
The technical case still matters. But it's the supporting evidence, not the opening argument.
When complexity arrives compressed and translated into language they can visualize, budget conversations stop feeling like begging for table scraps and start feeling like strategic partnership.
