Making the Case for Technical Investment to Non-Technical Execs

I've sat in probably 200 executive meetings where an engineering leader tried to get budget for technical work. Refactors. Infrastructure upgrades. Paying down tech debt. Platform migrations.

About 80% of those pitches failed. Not because the work wasn't needed, but because the engineer spoke engineer and the exec spoke business. Different languages. Same room. Zero comprehension.

I've been on both sides of that table. Here's how to actually win these conversations.

# Why Most Technical Pitches Fail

Engineers make three consistent mistakes when presenting to non-technical executives.

Mistake 1: Leading with the problem. "Our database is on Postgres 12 and it's end-of-life." The exec hears: "Something I don't understand needs to change for reasons I don't understand." Their default response is "Is anything broken right now?" and when you say no, the conversation is over.

Mistake 2: Using technical jargon as evidence. "We need to refactor our monolith into microservices because our deployment coupling is creating release bottlenecks." Every word after "refactor" was noise to a non-technical exec. They don't know what coupling means. They don't care.

Mistake 3: Asking for time without promising outcomes. "We need two sprints for tech debt." What outcome? What changes? What gets better? If you can't answer those questions in business terms, you haven't made a case. You've made a request.

# The Contrarian Take

Here's the uncomfortable truth: it's not the exec's job to understand technical problems. It's your job to translate technical problems into business problems. If you can't do that, the pitch should fail.

I know that stings. But every dollar spent on infrastructure is a dollar not spent on features, marketing, or hiring. The exec's job is to allocate resources for maximum business impact. If you can't demonstrate impact, you deserve to lose the budget.

The good news: translation is a learnable skill. And once you learn it, you'll never lose a technical investment pitch again.

# The RICE-T Framework

I adapted the standard RICE prioritization framework for technical investments. The T is for Technical Risk.

R - Revenue Impact: How does this technical work affect revenue? Be specific. "Reducing page load time from 4.2 seconds to 1.8 seconds. Based on Google's data and our own A/B tests, every 100ms of improvement increases conversion by 0.3%. For our current traffic of 2M monthly visitors with a 2.4% conversion rate and $85 average order value, a 2.4-second improvement translates to approximately $146K in additional annual revenue."

That's a number an exec can evaluate. Compare it to "we need to optimize performance."

I - Impact on Velocity: How does this work affect the team's ability to ship features? "Our current deployment takes 45 minutes and fails 18% of the time. Engineers spend an average of 3.2 hours per week dealing with deployment issues. That's 3.2 hours x 14 engineers x 50 weeks x $85/hour fully loaded = $190K/year in lost productivity. The CI/CD upgrade reduces deployment time to 8 minutes with a 2% failure rate."

C - Customer Impact: How does this affect customers directly? "Our API p95 latency is 1.8 seconds. Our three largest enterprise clients have contractual SLAs requiring sub-500ms response times. We're at risk of $2.1M in contract penalties if we don't improve this by Q3."

E - Engineering Retention: This is the one most people miss. "We've lost two senior engineers in the last six months who cited technical debt as a factor in their exit interviews. Replacing a senior engineer costs $180K in recruiting, onboarding, and lost productivity. If our technical environment continues to degrade, we estimate losing 2-3 more engineers this year."

T - Technical Risk: What happens if you don't do this work? "Our Postgres 12 instance reaches end-of-life in November 2026. After that date, we receive no security patches. A security breach on an unpatched database would trigger mandatory breach notification to our 340K users, estimated remediation cost of $800K-$1.2M, and potential regulatory fines."

You don't need all five for every pitch. Pick the two or three that are strongest for your specific situation.

# How to Structure the Conversation

I use a three-act structure. Seriously. Storytelling works on executives the same way it works on everyone else.

# Act 1: The Business Problem (2 minutes)

Start with something they care about. Not technology. Business.

"We're losing 12% of checkout sessions to timeout errors. That's $2.3M in abandoned revenue per year at current traffic levels. Our competitors' checkout completes in under 2 seconds. Ours takes 6.8."

Notice: no mention of technology. No mention of databases, APIs, or architecture. Just a business problem with a dollar amount.

# Act 2: The Cause and Solution (3 minutes)

Now connect the business problem to the technical cause, briefly.

"The timeout happens because our checkout process makes 14 sequential API calls when it should make 3. Fixing this requires restructuring the checkout service. It's 4 weeks of work for 3 engineers."

Simple. Cause and fix. No deep technical explanation.

# Act 3: The Return (2 minutes)

Show the math.

"4 weeks x 3 engineers x $85/hour = $40K investment. The fix recovers approximately $2.3M in annual revenue. Even if we capture 30% of abandoned sessions, that's $690K. That's a 17x return."

Execs understand ROI. Give them ROI.

# The One-Pager Template

Every technical investment pitch should have a one-page brief. Here's the template I use:

Problem Statement: One sentence. Business impact. Dollar amount.

Root Cause: Two sentences. Simplified technical explanation.

Proposed Solution: Three sentences. What you'll do, how long it takes, how many people.

Cost: Engineer-hours x loaded rate. Tool costs. Any other expenses.

Expected Return: Revenue recovered, costs saved, or risks mitigated. Dollar amounts.

Timeline: Start date, milestones, completion date.

Risk of Inaction: What happens if you don't do this work. Specific consequences.

# Stealable Framework: The 60-Second Elevator Pitch

If you can't make the case in 60 seconds, you can't make it in 60 minutes. Practice this:

"We're losing [dollar amount] because of [business problem]. The cause is [simplified technical issue]. Fixing it takes [time and people]. The ROI is [multiple]x. If we don't fix it, [consequence]."

Fill in the blanks. Say it out loud. If any blank doesn't have a specific number, go find the number first.

# Common Objections and How to Handle Them

"Can't we just do it in between feature work?" "We could, but it would take 4 months instead of 4 weeks because context switching reduces engineering productivity by 40%. The delayed timeline means we'd lose an additional $575K in revenue during those months."

"Is this really necessary right now?" "Every month we wait costs us $190K in [lost revenue / wasted productivity / contract risk]. The total cost of waiting until Q4 is $760K. The cost of doing it now is $40K."

"What if we just hire more engineers instead?" "Hiring an engineer takes 3-4 months and costs $180K in year one. The technical fix costs $40K and starts delivering value in 4 weeks. We should do both, but the fix comes first."

Notice the pattern: every answer includes a number. Numbers are the language of executive decision-making. Learn to speak it fluently.

The engineers who get technical investment funded aren't the ones with the most urgent technical problems. They're the ones who translate technical problems into business terms that executives can't ignore.