How I Learned to Talk About Engineering in Money

How I learned to talk about engineering in money

Early in my career, I could not answer a simple question: what is the return on your engineering investment?

I knew my systems were good. My teams shipped on time. But when someone asked me to put a number on it, I had nothing. I would talk about uptime, deployment frequency, code quality scores. The CFO would nod politely and move on.

This is the gap most engineering leaders never close. We speak in technical metrics. The business speaks in money. And we wonder why engineering keeps getting treated as a cost centre.

The consulting firm that taught me numbers

My first real lesson came at ITC Infotech, where I ran a $5M consulting P&L. In consulting, every project needs a number before it starts and a number when it ends. There is no hiding behind "we improved developer experience" or "we reduced tech debt." The client wants to know: did this make money or save money, and how much?

I learned to build business cases before writing a single line of code. Not because I wanted to. The commercial team would simply reject my proposals if I didn't.

That changed how I thought about engineering permanently. Every technical decision has a cost and a benefit. If you can't state both, you don't understand the decision well enough.

The CFO who asked hard questions

Then I moved to Maersk. $50M annual technology investment, 200+ engineers, 130 countries. Different scale, same principle. Except now the CFO was in the room, and the CFO did not care about sprint velocity.

The first time I presented an infrastructure modernisation plan, I led with architecture diagrams. Beautiful diagrams. The CFO stopped me five minutes in. "What does this cost us per transaction today, and what will it cost after?"

I didn't have the answer.

That was embarrassing. It was also the most useful moment of my career. I went back, did the maths, and came back with unit economics. Cost per transaction. Cost per customer served. Cost per data pipeline run. The CFO approved the plan in one meeting. I had failed to get the same plan approved twice before.

How to actually measure engineering ROI

After doing this across consulting, large enterprise, and now a retail data platform, I have a way of working that holds up. It is not complicated. It just requires you to stop thinking like an engineer for a few hours each quarter.

Quantify technical debt in money

Most teams track tech debt as tickets in a backlog. That tells you nothing useful.

Instead, calculate what tech debt costs you each month. How many hours does the team spend on workarounds? How many incidents come from legacy code? What revenue do you lose from slow feature delivery?

At Maersk, we found one legacy integration layer was costing us roughly 400 engineering hours per quarter in maintenance and incident response. That is a number a CFO understands.

Measure productivity, not velocity

Story points and velocity tell you how busy your team is. They don't tell you how productive they are. Busy and productive are different things.

I measure productivity as: how much business value did the team deliver per unit of cost? That means connecting what the team ships to business outcomes. Revenue generated. Costs avoided. Time saved for users.

Yes, this is harder than counting story points. That's exactly why it matters.

Assess business impact directly

Every quarter, I sit down with product and commercial teams and ask: what did engineering deliver that moved a business number? Not what did we ship. What moved a number.

Sometimes the answer is clear. We built a feature that increased conversion by 3%. Sometimes it is fuzzy, like platform reliability work that probably helped retention but we can't isolate the effect. Both are fine. The discipline is in asking and writing the answer down, even when the answer is "we don't know yet."

Unit economics for AI systems

This one matters more now than ever. Every company is spending on AI. Most can't tell you what they get back per pound spent.

For every AI system I build, I track cost per decision. Not cost per API call. Cost per business decision the system supports. An ML model that costs 2p per inference but saves an analyst 20 minutes of work has clear unit economics. One that produces a recommendation nobody acts on is a waste of money, regardless of its accuracy score.

At my current place, we track this weekly. What did the AI system cost to run? What decisions did it inform? What was the value of those decisions? When we can't answer the third question, that is a signal to stop and rethink before spending more.

What changed

The results were concrete. Across my portfolio, I could show $5M in annual engineering value. Not by doing more work. By measuring what we already did and presenting it in language the business understood.

Investment approval rates went up by 80%. When you show the CFO a clear return, the approval conversation gets shorter. The plan I used to pitch three times now gets approved in one meeting.

My teams also got better at their jobs. Engineers who understand why they're building something, in business terms, make different technical decisions. They cut scope differently. They argue for the right investments, not just the interesting ones.

Why this is worth your time

Most engineering leaders avoid this work because it feels reductive. We build complicated things. Reducing that to a spreadsheet feels wrong.

But if you can't explain your engineering investment in money, someone else will. And they'll probably get it wrong. They'll cut your budget based on gut feel. They'll fund the wrong projects because the loudest stakeholder wins.

This is not about reducing engineering to finance. It is about making sure engineering gets a fair hearing in the room where decisions are made. That room runs on numbers.

Start small. Pick one project. Work out what it cost, what it delivered, and what the return was. Present that to your CFO or finance partner. The conversation will be different from any you've had before.