25% of AI Investments Deferred to 2027 Amid CFO-Led ROI Demands—Are Engineering Teams Still Optimizing for Velocity While Finance Demands Results?

General
1

Last week, our CFO asked me a question I wasn’t prepared for: “Michelle, we’ve been using AI coding assistants for nine months. Engineering says productivity is up 40%. Great. Now show me the ROI.”

I pulled up our DORA metrics dashboard—deployment frequency up 35%, lead time cut in half, change failure rate down 12%. I thought these numbers spoke for themselves.

She said: “I see faster deployments. What I don’t see is faster revenue growth, lower customer acquisition cost, or improved gross margins. Engineering is shipping more code. Is that making us more money?”

I didn’t have a good answer. And based on recent data, I’m not alone.

The CFO Reality Check of 2026

According to Waydev’s 2026 Tech Trends report, enterprises will defer 25% of planned AI investments to 2027 amid CFO-led demands for tangible ROI. Fewer than one-third of decision-makers can currently link AI adoption to financial growth.

Meanwhile, engineering culture in 2026 has doubled down on velocity metrics. CircleCI’s State of Software Delivery reports that AI-assisted development drove a 59% increase in average engineering throughput last year.

We’re celebrating deployment frequency. CFOs are asking about revenue per engineer.

We’re tracking lead time. They’re tracking gross margin.

We’re measuring change failure rate. They’re measuring customer lifetime value.

We’re speaking different languages.

The Gap I’m Seeing at My Company

Here’s what the disconnect looks like in practice at my 120-person SaaS company:

What engineering reports:

  • 40% more features shipped per quarter (with AI coding assistants)
  • Deployment frequency: 15 deploys/week → 23 deploys/week
  • Mean time to recovery: down 18%
  • Developer satisfaction: up 22 points

What the CFO asks:

  • Did revenue per employee improve? (Answer: flat)
  • Did feature adoption rate change? (Answer: we don’t track that)
  • Did customer churn decrease? (Answer: actually up 3%)
  • Did support ticket volume drop? (Answer: up 8%)

The brutal truth: we shipped 40% more features, but customer outcomes didn’t improve. We optimized for speed, not value.

The 2026 Measurement Challenge

The LeadDev 2026 predictions article nails the core problem:

“2026 demands dashboards tying DORA metrics to revenue. Teams must pivot sharply from activity-based metrics (how much code is pushed) to outcome-based metrics (how much customer value is delivered, and how efficiently).”

But how? That’s the question I’m wrestling with.

What I’m Trying (And What’s Not Working Yet)

Attempt 1: Direct attribution
Tried linking deployments to revenue. Failed. Too many variables between “code shipped” and “money made.”

Attempt 2: Leading indicator mapping
Hypothesis: deployment frequency → faster feature iteration → better product-market fit → revenue growth.

Problem: Assumes all features are equally valuable. They’re not. We shipped 40% more features, but only 15% meaningfully moved the needle.

Attempt 3: North Star + Technical Enablers
Current experiment: Define business North Star (e.g., “customer time-to-value”) and map technical metrics as enablers.

Still figuring out the right business outcome to own.

Questions for This Community

I’m curious how other technical leaders are navigating this:

  1. What business outcomes should engineering own? Revenue per engineer? Customer satisfaction scores? Net retention? Or should we resist being measured on business metrics at all?

  2. How do you translate technical velocity to financial impact? Is there a framework that bridges the DORA world and the CFO world?

  3. What happens when velocity gains don’t yield business gains? If we’re shipping 40% faster but customers aren’t happier or revenue isn’t growing, what does that tell us?

  4. Is the problem the metrics or the work? Are we measuring wrong, or are we optimizing for the wrong things?

The Engineering Leadership Blind Spot of 2026 article argues that “more code, fewer releases” is a symptom of prioritization failure, not a technical problem. Maybe the real issue is that we’re building the wrong things faster.

I don’t have this figured out. But with 25% of AI budgets being deferred, I know this conversation is urgent.

What’s working for you? What have you tried and abandoned? How are you making the CFO case for engineering productivity investments?

2

I’m living this tension right now at our Fortune 500 financial services company.

My team of 40+ engineers has been using AI coding assistants for about 15 months. Our throughput metrics look incredible—PR velocity up 30%, deployment frequency nearly doubled, incident response time down 25%. The team is proud of these gains, and honestly, I was too.

Then last quarter, our VP of Engineering asked me to present our AI productivity story to the CFO org. I walked in confident with my dashboards.

The CFO’s first question: “Luis, that’s a 59% throughput increase according to CircleCI industry data. Did revenue per engineer go up 59%?”

Answer: No. Revenue per engineer was basically flat.

Second question: “Did customer acquisition cost decrease since engineering is faster?”

Answer: Actually went up 8% because we expanded sales, but engineering velocity didn’t translate to CAC improvement.

Third question: “Did NPS improve with all these new features?”

Answer: NPS dropped 4 points. More features ≠ better product apparently.

I got absolutely demolished. My DORA metrics meant nothing in that room.

The Harsh Reality I’m Facing

Michelle, your “quality-adjusted velocity” question hits hard. Here’s what I’m realizing:

We’re measuring engineering activity, not engineering value.

When I dug into our 30% PR velocity increase, here’s what I found:

  • 40% of merged PRs were refactoring or tech debt (good for long-term, doesn’t move business needle short-term)
  • 25% were infrastructure improvements (necessary, but invisible to customers)
  • Only 35% were customer-facing features

And of that 35%:

  • Feature adoption rate averaged only 18% (meaning 82% of users never touched most new features)
  • Support tickets increased 12% because some AI-generated code had edge case bugs we didn’t catch

So yes, we shipped more code. But we didn’t ship more value.

What I’m Trying Now: Feature Validation Rate

I’ve started tracking what I’m calling “Feature Validation Rate”:

(Features with >20% adoption in 30 days) / (Total features shipped)

Before AI tools: 8 features shipped per quarter, 5 validated → 62.5% validation rate

With AI tools: 14 features shipped per quarter, 6 validated → 42.8% validation rate

We’re shipping 75% more features but validating only 20% more. Our “hit rate” actually got worse because we’re moving too fast to validate properly.

The CFO’s point: If I can ship garbage 75% faster, that’s not productivity—that’s waste at scale.

The Question That’s Keeping Me Up

Michelle, your question #4 hits hardest: Is the problem the metrics or the work?

I think it’s the work. Specifically, it’s the prioritization.

AI coding assistants make us incredibly efficient at building whatever we decide to build. But they don’t help us decide what to build. If anything, the velocity pressure makes it harder to slow down and ask “should we build this?”

Product discovery hasn’t accelerated. User research timelines haven’t changed. But engineering execution is 59% faster. So we’re building 59% faster based on the same (potentially flawed) assumptions.

We’ve optimized the wrong part of the value chain.

What I Think We Actually Need to Measure

Instead of raw velocity, I’m proposing to my VP:

  1. Quality-Adjusted Velocity: Features shipped × Validation rate × (1 - Defect rate)
  2. Time-to-Customer-Value: Not time-to-deploy, but time from idea to measurable customer outcome
  3. Waste Ratio: Features shipped but never adopted / Total features shipped

And the hard one:
4. Revenue per Validated Feature: Did this feature actually contribute to business growth?

The CFO doesn’t care if we deploy 23 times per week. She cares if those 23 deploys made the company more valuable.

The brutal question I’m asking myself: If our AI-boosted velocity is building the wrong things faster, would we be better off going back to slower, more deliberate execution?

I don’t have answers yet. But I know our current measurement approach is lying to us about what “productive” actually means.

3

Michelle, your CFO is asking the right questions. And Luis, your Feature Validation Rate metric is closer to what product teams have been screaming about for months.

I’m going to say something controversial: CFOs might understand product-market fit better than most engineering leaders right now.

Here’s why.

The Product Perspective: Engineering Is Outrunning Discovery

At my Series B fintech startup, I’m VP of Product working with a fantastic engineering team. Last year we adopted AI coding tools across the board. Engineering velocity went through the roof—40% more PRs merged, 2-week sprint estimates now done in 8-9 days.

My initial reaction: “This is amazing! We can iterate so much faster!”

Reality check after 6 months: Engineering is shipping 40% faster, but product discovery velocity is exactly the same.

  • Customer interviews still take 2 weeks to schedule and synthesize
  • Usability testing still takes 3-4 weeks from prototype to insights
  • Market research cycles haven’t changed
  • A/B test statistical significance still requires the same sample size and time

The bottleneck shifted from “can we build it fast enough?” to “do we even know what to build?”

And here’s the scary part: the velocity pressure is real. When engineering can ship in 8 days instead of 14, there’s implicit pressure to fill those sprints. We’re building more because we can, not because we should.

What Your CFO Is Actually Asking About

When your CFO asks “did customer churn decrease?”, she’s not being difficult. She’s asking the fundamental product question: Did we build the right things?

All the DORA metrics in the world can’t answer that question because they measure execution quality, not decision quality.

Here’s the framework I use with my engineering partners:

Engineering Excellence = Decision Quality × Execution Quality

  • Decision Quality: Are we building the right things? (Product’s domain)
  • Execution Quality: Are we building things right? (Engineering’s domain)

AI coding assistants improved Execution Quality by ~40-60% across the industry. That’s incredible.

But Decision Quality? Unchanged. Or possibly worse, because the velocity pressure is making us skip validation steps.

If Decision Quality = 50% and Execution Quality = 100%, you’re still only achieving 50% of potential value. And you’re wasting the other 50% very efficiently.

The Gap Luis Identified Is Real

Luis’s data is devastating:

  • 75% more features shipped
  • Only 20% more features validated
  • Hit rate dropped from 62.5% to 42.8%

As a product person, this is my nightmare scenario. We’re building faster, learning slower, and shipping more things that nobody wants.

The industry data backs this up. According to various product research:

  • 60-70% of features get little to no usage
  • Only ~10-20% of experiments produce meaningful positive impact
  • Feature bloat is the #1 complaint in SaaS product reviews

AI-accelerated engineering just lets us create bloat 59% faster.

What I’m Proposing: Velocity-Matched Discovery

Here’s what I’ve started implementing with my engineering partners:

Rule: Discovery capacity must match execution capacity.

If AI tools give us 40% more engineering capacity, we need 40% more discovery capacity to feed it properly. Otherwise, we’re just building faster based on the same (often wrong) assumptions.

Practical implementation:

  1. Ratio rule: For every 2 engineers, 1 product person doing active discovery (interviews, research, validation)
  2. Validation gates: Features can’t enter sprint planning without validated customer problem + success criteria
  3. Adoption tracking: Every shipped feature gets tracked for 30-day adoption. <15% adoption triggers a retrospective

My controversial take: If you can’t do proper discovery to match your new engineering velocity, you should slow engineering down.

Shipping the wrong things 40% faster is worse than shipping the right things at normal speed.

Metrics That Bridge Product and Finance

To Michelle’s question about translating technical velocity to business impact, here’s what’s working for us:

North Star Metrics (Business Outcomes):

  • Customer Time-to-Value (how fast do new users reach “aha moment”)
  • Feature Adoption Rate (% of users actually using what we ship)
  • NPS / Customer Satisfaction
  • Net Revenue Retention

Leading Indicators (Product + Engineering):

  • Experiment Velocity (validated experiments per quarter, not just features shipped)
  • Learning Velocity (insights per sprint that change our roadmap)
  • Deployment Frequency (yes, still matters for iteration speed)
  • Time-to-Feedback (how fast we learn if something works)

The difference: We measure learning not just shipping. The CFO doesn’t care how much code we wrote. She cares how much we learned about what customers will pay for.

The Hard Truth About “Productivity”

Michelle, your CFO asked: “Is engineering shipping more code making us more money?”

The answer is: Only if product knows what code to ask for.

Engineering productivity without product-market fit is just expensive waste. AI coding tools are incredible accelerators—but they don’t steer. They accelerate whatever direction you’re already going.

If you’re going the wrong direction, acceleration is catastrophic.

Luis’s question about whether we should go back to slower, more deliberate execution? I don’t think we need to slow down engineering. I think we need to speed up learning.

The real productivity challenge of 2026: How do we make discovery as fast as execution?

Until we solve that, CFOs are right to question our velocity metrics. Shipping fast means nothing if we’re shipping the wrong things.

4

Great discussion here. The insights about 25% of ai investments deferred to 2027 amid cfo-led roi demands—are engineering teams still optimizing for velocity while finance demands results? really resonate.

I’m curious - has anyone implemented something similar in a team of 20+? Would love to hear about the challenges at scale.