The CFO Who Couldn't Explain the Engineering Budget - And What He Learned When He Finally Could

The board asked me a simple question: 'Engineering is 42% of operating expense. What are we getting for it?'

I had the headcount numbers. I had the infrastructure costs. I had the tool spend. What I didn't have was a coherent answer to the actual question: what value does this $18 million produce?

I said something about velocity and story points. The board member who'd spent twenty years in manufacturing looked at me like I'd explained factory output by counting how many times the machines turned on.

The financial black box

I've been a CFO for twelve years. I can model every other function in the company with reasonable precision:

• Sales: pipeline × conversion rate × average deal size = predictable revenue.
• Marketing: spend × cost-per-acquisition × lifetime value = predictable ROI.
• Operations: headcount × utilization × output per person = predictable capacity.
• Engineering: ??? × ??? × ??? = the CTO says it's going well.

Engineering was the only function where I approved budget based on trust instead of a model. And every year, when the budget grew by 25% and the output seemed roughly the same, I had no framework to understand why.

The questions I couldn't answer

I started writing down the questions I wished I could answer. The list was embarrassing for someone in my position:

• If we add five engineers, how much additional output do we get? Nobody could tell me.
• What percentage of engineering time is spent on new features vs. maintenance vs. rework? Nobody tracked it in a way that was financially meaningful.
• When a project takes twice as long as estimated, where does the extra cost go? Into 'complexity' - which is another way of saying 'we don't know.'
• What does a deployment cost? Including the engineer time, the review time, the rollback risk? Nobody had ever calculated it.

I was approving $18 million in annual spend with less financial visibility than I had over the office supply budget.

The conversation that reframed the problem

I was at a CFO roundtable when a peer from a larger company said something that rewired my thinking:

You're measuring engineering like it's a cost center. It's not. It's a production system. And you should model it the same way you'd model a factory: input costs, throughput, yield, waste, and capacity utilization.

That night I looked for frameworks that treated software delivery as a production system. The Team Helix blog had exactly the framing I needed:

The coordination tax is measurable

This was the financial model I'd been missing. Linear cost growth with sub-linear (or negative) output growth. I'd been funding the wrong side of the equation.

The delivery system is the asset, not the people

From a CFO's perspective, this meant the investment should go into the system that makes engineers productive, not just into more engineers. The analogy to manufacturing was perfect: you don't hire more assembly line workers when the assembly line is broken.

What I changed

1. I built a delivery economics model

Instead of tracking headcount and tool spend, I started tracking delivery metrics with financial implications: cost per deployment, time from commit to production, rework rate, incident cost, and delivery predictability.

For the first time, I could see where the money was actually going - and 35% was going to coordination overhead, rework, and incident remediation.

2. I funded the system, not just the people

The CTO was surprised. Usually the CFO fights to reduce engineering spend. I was fighting to spend it differently.

3. I made delivery predictability a financial metric

I added delivery predictability to the financial dashboard - right next to revenue growth and gross margin. When the board could see the correlation between delivery predictability and customer retention, engineering investment stopped feeling like a leap of faith.

What happened

• Engineering headcount grew 10% while output grew 40%. The delivery system was doing the work that additional bodies used to do - badly.
• Rework costs dropped by half. When governance constraints catch issues at build time instead of production, the cost of fixing them drops by an order of magnitude.
• I could finally answer the board's question: 'What are we getting for the engineering budget?' with data, not narrative.
• Engineering stopped being the function I funded on faith and became the function I could model, predict, and optimize like any other.

The CTO told me later: 'You're the first CFO who ever asked how the system works instead of just asking how much it costs.' I took that as the compliment it was - and as an indictment of the question I should have been asking all along.

Time to come clean

There wasn't a single board question that triggered the change. There wasn't one CFO roundtable that provided the framework. There wasn't a clean pivot from 'funding faith' to 'delivery economics.'

But every CFO who's signed off on a growing engineering budget without a clear output model knows this feeling. The uncomfortable silence when the board asks what the money produces. The vague metrics that don't connect to business outcomes. The nagging suspicion that more people isn't the same as more output.