I’ve been fortunate to spend the last 16 years working with engineering teams in some capacity. Designing cloud infrastructure, building automation pipelines, helping clients optimise for performance, resiliency, and uptime.
The focus was always fairly straightforward: move fast, ship often, keep it running, keep it compliant.
But more and more, the question that actually matters is:
Are we building in a way that helps the business grow?
That’s where unit metrics can really shine. And why they’re the natural next step in the DevOps journey.
Why Engineering and Finance Talk Past Each Other
I’m sure many of you have been in a meeting like this:

Finance team:
Looks like this machine is oversized. Can we reduce it to save some money?
Engineering:
That configuration gives us the headroom we need to stay resilient. Scaling it down adds risk we’re not comfortable with.
Nobody’s wrong. But the conversation is reactive, tactical, and frustrating on both sides.
It seems the crux of the issue is that finance sees cost, whilst engineering sees architecture. Neither really sees the full picture or is accountable for both.
DevOps Unlocked Speed, But Overlooked Cost.
Seventeen years ago, DevOps gave teams autonomy. That shift allowed engineering to focus more on automation, infrastructure as code, and cloud services. Combined with agile and microservices, it led to unprecedented speed.
By automating infrastructure and breaking down silos, we made it easier for developers to deliver faster and own more of the lifecycle. Ops became part of the build process, not just the safety net.
But this led to something interesting:
Developers are now making cloud purchasing decisions every day, for example:
- Choosing between S3 tiers
- Picking databases and queueing services
- Deciding how resilient “resilient” it really needs to be
- Integrating cloud or AI APIs into applications
These are product-defining choices. And they come with real cost implications.
But without the right context, it’s hard to know whether those costs are justified.
Unit metrics give you that context.
Unit Metrics Make Cost Meaningful
Instead of tracking spend in isolation, imagine tying it directly to something the business actually cares about for example:
- Cost per active customer
- Cost per transaction
- Cost per AI inference
- Cost per deployment
- Cost per $1 of revenue
When you frame cost this way, it’s no longer just a finance concern. It becomes a window into efficiency, not just in technical terms, but in terms of business impact. You’re not reacting to cloud spikes. You’re making informed decisions that support growth.
Designing for Margin, Not Just Engagement
A few years ago, I worked with a mobile gaming company that wanted to track usage within the game at a really granular level, for example measuring when a specific weapon was used in their iOS game. They were trying to understand what players loved in real-time, so they could replicate what worked and drive more engagement.
They added code hooks to track every usage event.
Now imagine if, alongside that behavioural data, they could also see how much each weapon cost to support.
Suddenly, they wouldn’t just be designing for engagement. They’d be designing with margin in mind too, building features that not only drive usage, but also contribute meaningfully to business growth.
That’s the potential when combining business insight with cost data.
Smart Engineering Starts with Cost Visibility
Over the years, I’ve helped teams implement everything from rightsizing automation to CI/CD pipelines that respond to performance metrics.
But operational efficiency is only part of the story.
When you add cost per unit into the equation, you go from:
Let’s make sure it scales.
To:
Let’s make sure it scales efficiently.
Cost becomes part of engineering’s design toolkit, not just something to justify after the fact.
It can be treated like any other non-functional requirement, just like latency, security, or availability.
How CloudZero Helps Teams Build With the Business in Mind
This is what excites me about CloudZero and why I decided to join the company.
I’ve been diving into the platform myself over the last few weeks, because for me, it’s important to really understand the technology if I’m going to advocate for it in any way.
The platform integrates natively with AWS, Azure, GCP, Kubernetes, and Snowflake, and can ingest data from any other sources using the AnyCost adaptor. It normalises and maps that cost data to your architecture, environments, and business dimensions like teams, products, features, and customers.
This gives engineering teams real-time, drill-down visibility into how decisions impact cost at a very granular level, and more importantly, how those costs align with business outcomes like margin, growth, and unit economics.
You don’t need to decipher billing spreadsheets or mess around with pivot tables.
Once you’ve decided what’s important to you, you can just focus on that. Of course, you can break everything down by team, business unit, product, and so on, but with the unit economics piece, you might decide to focus on:
• Your cost per customer
• The cost of a specific feature or deployment
• How much each team or environment contributes to overall COGS
• Anything else your business needs to track to drive growth
And you don’t need a perfect tagging setup or weeks of implementation. It works out of the box, even in complex environments like Kubernetes.
When engineers get that kind of clarity, the conversation can shift from:
“Can we cut spend?“
To:
“What’s the best way to build this for the business?“
Engineering, Product, and Finance: Finally Aligned
So it feels to me that unit metrics bring everything full circle.
- DevOps gave us agility
- Now cost becomes a first-class input, not an afterthought
- Automation gave us scale

This way, engineering, product, and finance can finally speak the same language:
What are we building, what does it cost, and is it worth it?
If you’re trying to connect technical decisions to business impact, or if you’ve ever had one of those painful cost conversations without context, I’d love to hear how you’re thinking about this!
Unit metrics are the shift that makes FinOps useful for engineers. CloudZero is the platform that makes it possible.