Selling the Invisible: How to Make Technical Work Impossible for Executives to Ignore
- Darren Emery
- 3 days ago
- 6 min read
There’s a line often attributed to Bill Curtis, a leading authority on software process and maturity models:
“If you think good architecture is expensive, try bad architecture.”
Every technology leader hears it and nods.
Every executive hears it and wonders ‘Okay, but how much will it cost me?’
This is the tension at the heart of modern engineering leadership - especially in mid-to-large organisations with legacy platforms, regulatory pressure, and customers who don’t tolerate downtime.
The work that makes systems faster, safer, more scalable, and more sustainable is rarely the work that appears in a quarterly OKR or investor update.
Yet it’s the work that determines whether you can ship new products in weeks… …or spend eight months negotiating with a 20-year-old monolith for the privilege of deploying a button.
In the last decade, I’ve seen CTOs in financial services, betting & gaming, and insurance all face the same challenge:
How do you sell the value of technical work: debt, enablers, platform modernisation, to an executive team who can’t “see” the value until something breaks?
The answer isn’t better acronyms. It’s better evidence, better framing, and better ways of turning “invisible” work into a tangible business case.
This article is your playbook.
Why Execs Struggle With Technical Work (And Why It’s Not Their Fault)
Executives think in systems: revenue systems, cost systems, risk systems, market systems.
Technical work only enters their worldview when it causes one of three things:
A revenue blockage
A cost explosion
A regulatory or operational risk event
So when tech leaders talk about “refactoring” or "modernisation" or “upgrading Kubernetes clusters,” here’s what the executive brain actually hears:
“You want me to spend money… to stay in the same place… with no new features… and no guaranteed benefit… in a time-frame you can’t predict?”
And when you phrase it like that, they’re right to push back.
But the business reality is this:
Legacy platforms double lead times every 2–3 years
70% of companies say tech debt directly blocks innovation
30% of IT budgets in mature enterprises go towards keeping the (legacy) lights on
Tech debt often represents 20–40% of total tech asset value in banks
Cleaning it up can increase feature delivery capacity by up to 50%
In other words:The business is already paying for technical work - it just shows up as slower delivery, higher costs, and rising operational risk rather than a specific line on the budget.
And as Geoffrey Moore puts it, tech debt behaves like cholesterol - silent, invisible, and only noticed once it causes a stroke.
Your job isn’t to frighten executives.Your job is to help them see the system that’s already failing them.
The Real Problem: Technical Friction is a Business Problem Wearing a Technical Hat
When a COO asks, “Why can’t we ship features faster?”
Or a CFO asks, “Why did this outage cost us £180k?”
Or a CEO asks, “Why is our competitor launching products four times faster?”
The cause is rarely talent, process, or tooling.
It’s almost always hidden friction:
fragile integrations
ancient data pipelines
thousands of lines of untested business logic
manual release processes
tightly coupled systems nobody remembers building
environments that require 'sacrificial goats' before each deployment
In my experience, organisations spend more money avoiding the underlying technical issues than fixing them - through reorgs, consultants, new tools, and “agile transformations” that often spread friction faster.
Most organisations optimise for “busy”, not “throughput”.
And legacy complexity kills both speed and predictability.
Why Most Technical Pitches Fail
When technical leaders pitch debt reduction or enabler work, they almost always fall into one of these traps:
1. Talking about the work, not the outcome
Execs don’t care about logging frameworks, database patching or server migration cycles.
They care about cutting incident resolution by 40%.
2. No financial anchor
“Reduce complexity” means nothing.
“Save £800k annually in maintenance drag” means everything.
3. No competitive framing
Features delight customers.
Faster platforms outpace competitors.
4. No time-bound payoff
Without clear payback windows, everything looks like a cost.
5. No risk framing
Risk is the language of CFOs, COOs, Infosec, and regulators.
Legacy systems are a risk multiplier.
If you want to win executive buy-in, your message must be reframed.
How to Make Technical Work “Executive Obvious”
1. Translate It Into Business Metrics Executives Already Use
The four metrics that work every time:
a. Cost of Delay
Quantify how much every week of inaction costs in lost productivity, revenue, or customer churn.
Executives understand time as money - use it.
b. Incident Cost
Map outages or performance issues to real financial impact.
“Each hour of downtime costs £45k in lost transactions.”
Now modernisation looks cheap.
c. Delivery Throughput
Show how legacy code reduces feature capacity.
“Refactoring the payment service frees 30% developer time = 6 more features per quarter.”
d. Risk Avoidance
Tie legacy technology to compliance and operational exposure.
“Running an unsupported database increases regulatory and security risk by X%.”
This is the difference between telling and selling.
2. Use Geoffrey Moore’s “Cholesterol Metaphor”
Executives understand risk compounding.
Explain tech debt like this:
“Every month we don’t address this, the risk compounds and the cost increases. This isn’t maintenance - it’s removing systemic friction so the business can scale, compete, and respond faster.”
Moore’s framing works because it’s tangible, risk-focused and unambiguous.
3. Use the 10–20% Continuous Investment Rule
Emphasise managing flow over managing projects.
Recommend a simple rule:
10–20% of capacity reserved for platform improvement
Tracked with before/after metrics
Reviewed quarterly to demonstrate ROI
It’s pragmatic, small-batch, and immediately implementable.
Executives love “predictable small bets” over “heroic big bets”.
4. Adopt the “One-Page Business Case” Format
You can sell 80% of technical work with a single page:
Headline
“£X per year lost due to [problem]. Estimated payback: Y months.”
1. The Current Cost
Quantified using real numbers.
2. The Opportunity
What becomes possible if friction is removed.
3. The Investment
Duration, cost, team needed.
4. The Payback Window
The date the project becomes ROI-positive.
5. The Competitive Angle
“Competitor X ships new features in 4 weeks. We take 16.”
Want attention? Do this.
This is empowerment through clarity - not more governance.
A Simple Framework: The “3-Lens Model for Technical Investment”
This is a model your audience can take straight into their boardroom.
Every piece of technical work should be evaluated through three lenses:
Lens 1: Performance (Speed & Capacity)
Does this work help us deliver more value, faster?
Examples: refactoring services, automating pipelines, improving environments.
Impact Metric: Delivery throughput / lead time
Exec Language: “This unlocks capacity equivalent to 3 more feature teams.”
Lens 2: Protection (Risk & Stability)
Does this work reduce exposure to outages, breaches, or regulatory failures?
Examples: upgrading unsupported components, modernising data pipelines.
Impact Metric: Incident cost avoided
Exec Language: “This cuts operational risk by 70% and reduces regulator exposure.”
Lens 3: Potential (Strategic Enablement)
Does this work unlock future products or capabilities?
Examples: modularising a monolith, building event-driven architecture.
Impact Metric: Revenue unlock / time-to-market reduction
Exec Language: “This reduces new product lead time from 6 months to 6 weeks.”
When these three lenses align, you’re not asking for permission - you’re presenting an unavoidable strategic investment.
The Real Mindset Shift: You’re Not Selling Technical Work. You’re Selling Capability.
Executives don’t fund code.They fund capability.
Faster delivery capability
More resilient operational capability
Lower-cost scaling capability
Better customer experience capability
Faster innovation capability
Technical work is simply the mechanism.
Or to put it bluntly:
The fastest way to win executive buy-in is to stop talking about code and start talking about capability, capacity, and competitiveness.
Executives don’t care about frameworks; they care about outcomes.
They don’t care about architecture diagrams; they care about friction.
They don’t care about tech debt; they care about growth, risk, and speed.
Your job is to empower them with clarity - not overwhelm them with complexity.
Closing Thought
Technical debt is not a technical problem. It’s a commercial tax masquerading as an engineering concern.
And as Mik Kersten says:
“Tech debt is taking a loan against next month’s income to buy a feature today.”
So the question for executives isn’t “Should we pay down the debt?”
The question is much simpler:
“How much longer can we afford not to?”
Because in modern organisations, the real cost isn’t the technical work - it’s the compounding friction of avoiding it.
