We're All Racing to Prove AI ROI Before the Next Budget Cut—What Metrics Actually Convince Your CFO?

General
1

We’re all feeling it. The pressure is real.

63% of engineering firms have an AI strategy. But CFOs are cutting 25% of AI budgets. And the brutal truth? Only 14% of CFOs see measurable impact from AI investments. Only 29% of us can even measure ROI confidently.

I’m in this exact position right now. We pitched our AI strategy last year, got initial funding, championed tools like GitHub Copilot and Claude Code. My team loves them. But our Q3 review is coming up, and finance is skeptical.

The CFO Reality Check

Here’s what I’m learning the hard way: time saved doesn’t equal value created.

My engineers are shipping faster. Code reviews happen quicker. Documentation gets written. But when I tell our CFO “we’re 20% more productive,” the response is: “Prove it. And what are they doing with that saved time?”

What I’m Tracking (And Why It’s Not Enough)

I’ve been measuring what I thought mattered:

  1. DORA metrics for AI-touched PRs: We’re seeing 16% reduction in task size, 8% decrease in cycle times. Real numbers.

  2. New capabilities enabled: Features we shipped that wouldn’t have been possible without AI acceleration. Hard to quantify, but directionally true.

  3. Cost per capability delivered: Comparing AI-assisted development vs traditional approach. The math looks good, but attribution is messy.

But here’s the problem: these are engineering metrics. CFOs don’t think in DORA metrics. They think in dollars, revenue, and risk.

The $1:$20 Reality Nobody Talks About

And then there’s this uncomfortable truth I found in recent research: for every $1 spent on AI, we need $20 in data architecture investment to make it work properly.

Are we being honest about total cost of ownership? Are we accounting for the infrastructure, the data quality work, the integration effort? Or are we just reporting the tool subscription costs?

The Urgency

I have 8 weeks until our budget review. If I can’t demonstrate clear ROI, our AI budget gets cut. And I genuinely believe removing these tools will slow us down, accumulate technical debt, and hurt retention.

But belief isn’t data. And anecdotes aren’t ROI.

What I Need from This Community

What metrics actually moved the needle with your CFO?

Not what you wish worked. Not what should work in theory. What actually convinced your finance team to maintain or increase AI investment?

  • Are you measuring productivity? Revenue impact? Risk reduction?
  • What measurement overhead is acceptable? (Can’t spend more measuring than we save from AI)
  • How do you handle attribution? (How do you prove AI caused the improvement?)
  • What worked? What failed spectacularly?

I’ll share what works for us. Let’s figure this out before the next round of cuts.

Sources that informed this post:

2

This hits home, Michelle. We’re in the exact same position in financial services.

I’ve been wrestling with this for 6 months. Every exec meeting, our CFO asks the same question: “What’s the ROI on these AI tools?” And honestly, productivity metrics aren’t cutting it anymore.

What’s Working for Us: Risk Reduction Language

I stumbled into something that actually resonated with finance: framing AI as risk mitigation, not productivity enhancement.

Three weeks ago, our AI-powered code review caught a critical security vulnerability in a payment processing module. The engineer missed it. Our senior reviewer missed it. Claude Code flagged it.

I asked our security team: “What would this have cost us if it hit production?” Their estimate: $500K minimum in incident response, regulatory reporting, customer remediation. Potentially $2M+ if it led to actual breach.

Our AI tools cost: $120K annually for a team of 40 engineers.

That one catch? That’s 4+ years of ROI in a single incident prevention.

The Metrics That Matter to Finance

CFOs understand risk costs better than “productivity gains.” Here’s what I’m tracking now:

  1. Incidents prevented (quantified in dollar terms)

    • Security vulnerabilities caught before production
    • Compliance violations avoided
    • Breaking changes detected in code review

  2. Compliance cost avoidance

    • Faster implementation of regulatory requirements
    • Audit findings reduction (fewer remediation costs)
    • Time to respond to regulatory changes

  3. Speed to market for regulated features

    • Not “we’re faster” but “we can meet regulatory deadlines competitors can’t”
    • Competitive advantage in RFPs requiring compliance documentation

The Attribution Challenge

But here’s where I’m stuck: How do you quantify “what AI enables” without it sounding speculative?

When I say “AI caught 3 critical issues,” the CFO asks: “Would your senior engineers have caught them in code review anyway?”

I don’t know. Maybe? How do you prove a counterfactual?

The best answer I have: historical data. Before AI tools, we had X incidents per quarter. After AI tools, we have Y incidents per quarter. The delta is our risk reduction.

But that requires 12+ months of data. And if your CFO wants proof now, you don’t have 12 months.

Question for You

Your point about “new capabilities enabled” - can you give a concrete example? I’m struggling to articulate this to non-technical executives without sounding like I’m making excuses for not measuring properly.

What does “capability” mean in a way a CFO understands?

3

I’m going to offer a different perspective that might be controversial:

We stopped trying to prove AI ROI in isolation.

And it completely changed the conversation with our CFO.

The Realization That Changed Everything

About 4 months ago, I was preparing yet another “AI productivity metrics” presentation. And I had this thought: We don’t measure Slack ROI. We don’t measure Figma ROI. We don’t measure our CI/CD pipeline ROI.

Why? Because they’re infrastructure. They’re enablers of work, not products themselves.

AI is the same thing. It’s infrastructure for knowledge work.

The Strategy That Worked

Instead of defending “AI budget” as a line item, we bundled AI investment into broader engineering effectiveness initiatives.

Here’s what that looked like:

Organizational OKR: Reduce time-to-market by 30% in 2026

Key results:

  • Ship 2 major features per quarter (up from 1)
  • Reduce bug escape rate by 20%
  • Improve developer satisfaction scores to 8+/10

Investments to achieve this:

  • AI coding assistants and tools
  • Improved CI/CD pipeline
  • Developer experience improvements
  • Better documentation practices
  • Team training and development

AI became one tool in a portfolio of investments aimed at a strategic outcome.

What Changed in CFO Conversations

Before: “Justify this $400K AI budget.”
After: “We’re investing $1.2M to accelerate time-to-market. Here’s the portfolio of initiatives.”

Finance stopped questioning the AI budget specifically. They started asking: “Are we hitting the 30% time-to-market improvement?”

And the answer is yes. We’re at 26% improvement after 6 months. AI is a major contributor, but it’s not the only factor.

The Trade-off: Executive Alignment First

This approach requires something most of us don’t have: executive alignment before the budget fight.

You can’t reframe AI as strategic infrastructure during a budget defense. You need to establish the strategic priority first, then position AI as a tool to achieve it.

If your CFO is already skeptical and cutting budgets, this reframing might not save you. It’s a proactive strategy, not a reactive defense.

The Question I’d Ask This Group

Has anyone successfully defended standalone “AI budget” as its own category?

Or is embedded approach the only way forward?

Because I worry we’re all fighting the wrong battle. The battle isn’t “prove AI ROI.” The battle is “establish engineering effectiveness as a strategic priority.”

If you win the second battle, the first one becomes easier.

4

Product perspective here, and I think we’re all measuring the wrong thing.

CFOs trust customer impact metrics, not engineering productivity claims.

The Pitch That Didn’t Work

Six months ago, I sat in a budget review where our VP Engineering presented beautiful charts about developer velocity, cycle time reduction, and code quality improvements from AI tools.

Our CFO’s response: “That’s interesting. But how does this impact revenue?”

Crickets.

We didn’t have an answer.

The Approach That Actually Worked

Three months ago, we ran a different experiment. We surveyed 50 enterprise customers and prospects about AI-enhanced features.

The data was striking:

  • 42% said they would pay a 15% premium for AI-enhanced features in our product
  • 8 out of 10 recent enterprise RFPs specifically mentioned AI capabilities
  • 3 existing customers were evaluating competitors specifically because we didn’t have AI features

I took this data to our CFO with a different pitch:

“We’re not asking for AI tools to make engineering faster. We’re asking for AI tools to build AI features that customers will pay for. And here’s the revenue projection.”

The Business Case That Got Approved

Investment:

  • AI tools and infrastructure: $600K annually
  • 2 engineers dedicated to AI features: included in existing headcount
  • Total incremental: $600K

Revenue projection:

  • AI-enhanced SKU priced at 15% premium
  • 30% of enterprise customers upgrade (conservative based on survey)
  • Expected incremental revenue: $3-5M in 18 months

CFO’s response: “Approved. What do you need to get started?”

No questions about productivity metrics. No debate about measurement methodology. Just a straightforward revenue case.

The Insight: Flip the Conversation

Engineering efficiency is an internal metric. Revenue is external and measurable.

When you position AI as:

  • “Makes engineers more productive” → CFO skepticism
  • “Enables features customers will pay for” → CFO interest

The mental model shift: AI as product differentiator, not cost center.

The Hard Question

This approach only works if you CAN productize AI. If your business doesn’t sell software, or if AI doesn’t enhance your product in a way customers value, this strategy falls apart.

But I’d argue: Are we measuring the wrong thing by focusing on internal productivity at all?

What if the real ROI conversation should be about market positioning, competitive differentiation, and customer value - not about how many minutes we save in code review?

Food for thought.

5

Design systems lead here, and I’m going to tell you something simpler that might hurt:

Are people actually using it?

The Red Flag Moment

Last quarter, our engineering director proudly showed leadership the new AI tools we’d purchased. GitHub Copilot for everyone. Claude Code. Full suite.

Budget: $180K annually for team of 35.

I asked a question nobody else was asking: “What’s the adoption rate?”

Turns out: 30%.

We were paying for tools that 70% of the team wasn’t using, or was using minimally. Not because the tools were bad. But because:

  • Some engineers didn’t trust AI suggestions
  • Some found it slowed them down
  • Some never finished the onboarding
  • Some tried it once and abandoned it

We were hemorrhaging money on unused tools because someone checked a box that said “AI strategy.”

What I Track Now: The Simplest Metric

Weekly active users of AI tools.

That’s it. Not productivity. Not velocity. Not ROI.

If people aren’t using it, there is no ROI to measure. Period.

My dashboard:

  • Week 1: 12 active users (34%)
  • Week 4: 18 active users (51%)
  • Week 8: 25 active users (71%)
  • Week 12: 27 active users (77%)

The adoption curve tells me if the investment has a chance of working.

The Hard Truth from My Startup Failure

I co-founded a startup that failed. We raised money for “innovative technology” that our target customers… didn’t really want.

We had great technology. Impressive demos. But low adoption. And low adoption became no revenue became company death.

The lesson I learned: Usage metrics predict ROI better than capability metrics.

You can have the most powerful AI tools in the world. If your team doesn’t use them consistently, you’re burning money.

My Challenge to Michelle (and Everyone Here)

Before you go into that CFO meeting with DORA metrics and productivity gains:

What’s your team’s adoption rate?

If it’s below 70%, you have a different problem. You don’t need better ROI metrics. You need better change management.

And if it’s high? Then dig into why people are using it:

  • “It makes me faster” → productivity case
  • “It helps me learn” → training/ramp time case
  • “It catches my mistakes” → quality/risk case
  • “It’s fun to use” → retention case

The usage pattern tells you which ROI story to tell.

The Practical Suggestion

Start with adoption metrics. They’re easy to collect:

  • Tool dashboards show usage analytics
  • Weekly surveys (2 questions, takes 30 seconds)
  • Standup check-ins (“Who used AI tools this sprint?”)

If adoption is low, no other metric will save your budget.

If adoption is high, then you have evidence to build your ROI case on.

Don’t skip this step.