Hot take: If you have a “FinOps Team,” you’ve made a big mistake. 

Just like DevOps, it’s not a separate team – it’s a business competency for everyone responsible for running production. Stay with me, and I’ll show you why cost awareness belongs right next to reliability and performance in your operational toolbelt.

Let’s Talk About “The Goal”

Unless we’re founders, we report to someone. And our managers tend to be more business-minded than we are. So let’s look at this from their perspective.

There’s a management book called The Goal by Eli Goldratt that’s been around since the ’80s but remains super relevant. One of its central ideas is that the goal of any business is to:

Make money by increasing throughput while simultaneously reducing inventory and operational expense.

Sounds dry, like plant manufacturing. Gross. So let’s translate it for tech:

Make money by increasing sales and subscription revenue while simultaneously reducing unreleased code and the expense of operating and supporting the product.

Now we’re getting somewhere. That “unreleased code” part is worth pausing on – code sitting in pull requests is inventory in the Goldratt sense. It carries real cost: merge conflicts, context switching, stale assumptions. The longer it sits, the more expensive it gets. And “operational expense” is exactly what it sounds like: what it costs to keep the lights on.

This describes how a tech business succeeds: by maximizing margins, shipping fast, and keeping costs tight.

We Make Cost Decisions Constantly

So let’s put our DevOps/SRE/Platform hats back on. What work do we already deal with that’s fundamentally about costs?

Incidents are expensive. Outages cost millions, SLA violations risk customer relationships, and engineer burnout drives up retention costs. We already think about costs when systems break. The question is whether we think about costs when systems are running fine.

When you provision infrastructure, you’re making a cost decision. When you choose an instance type, that’s a cost decision. When you spin up a test environment and forget to tear it down, that’s also a cost decision. You just didn’t frame it as one.

This is what the FinOps discipline actually covers: not just capacity planning, but cost allocation, workload optimization, rate optimization, and knowing how your budget is being spent. That breadth is exactly why it shouldn’t live in a silo. It touches too many operational decisions to be somebody else’s meeting.

The SRE Book’s reliability hierarchy even includes capacity planning as a core concern. Cost has always been part of operational responsibilities. We just haven’t treated it that way.

The Uncomfortable Audit

Here’s where a FinOps practice begins, realistically: making sure every piece of infrastructure is tracked, managed, and verified to serve a business purpose.

That last part is the uncomfortable one. Go audit your cloud accounts right now. How many resources are running that nobody can explain the justification for? Test environments from six months ago that never got torn down. Services scaled for a traffic spike that ended in Q2. That POC that the product team vibe-coded using Claude a few months ago.

I’m not being hypothetical. I once had a colleague find six figures of annual infrastructure waste in a single afternoon. EC2 instances just sitting there idle, doing nothing, happily running up the cloud bill. This only happened after weeks of analysis with fancy tooling. The low-hanging fruit is there, ripe for the taking. The question is whether anyone in your organization considers it their job to look.

Why a Separate FinOps Function Still Misses the Point

I’ll give credit where it’s due: the FinOps movement gets a lot right. Cross-functional collaboration between engineering, finance, and business stakeholders is the correct mindset. That’s way better than handing a cloud bill to an accountant and saying, “Figure it out.”

But even a well-structured cross-functional FinOps group has a subtle problem: it still separates cost awareness from the moment it matters most.

Infrastructure spending decisions happen when an engineer writes a Terraform module, when someone spins up a test environment, when a team chooses an instance type. Those decisions happen dozens of times a day across an organization. A cross-functional group that meets weekly or monthly can only review those decisions reactively rather than proactively. They weren’t there when the decisions were made.

The risk around the mere existence of a FinOps function, however well-organized, gives individual engineers implicit permission to not think about costs in their daily work. “The FinOps group handles that.” It’s the difference between having a safety committee and having a culture where every employee considers safety part of their job.

Material impact is achieved not solely by a dedicated group reviewing spend after the fact, but by the people who provision and manage infrastructure as well. This allows organizations to treat cost as a first-class operational concern, just as we treat reliability.

Performance Without FinOps Is a Premature Optimization

Once your infrastructure is lean, tracked, and justified, you can talk about performance engineering. That’s returning to your observability foundations and squeezing as many transactions per CPU cycle and megabyte of RAM as possible.

But doing performance engineering without FinOps maturity is a premature optimization.

Why? Because if you haven’t right-sized your infrastructure, you don’t actually know what your performance baseline is. You might spend weeks optimizing a service that’s running on 4x the compute it needs. Congratulations – you made your over-provisioned system 15% faster. Meanwhile, you’re still paying for three times the resources you actually need.

Right-sizing is only half the problem. Even if your utilization is clean and your inventory is accounted for, if you’re paying retail rates for compute, you’ve already hampered your ability to manage costs – before a single dashboard is built or a single alert fires. Tagging discipline and utilization reviews are valuable, but they’re fighting uphill against your per-instance pricing. You can have perfect visibility hygiene and still be leaving a lot of money on the table.

This is where automation earns its place. Rate optimization (e.g., optimizing for – Reserved Instances, Savings Plans, Committed Use Discounts, Spot) follows well-understood rules. It doesn’t require engineering judgment, but it does require engineering ownership. The SRE move is to treat this the same way we treat any toil: automate it, own the tooling, and eliminate it as a source of ongoing manual work. Tools like ProsperOps handle this layer continuously, adapting discount coverage as your infrastructure changes, so your team’s attention stays on the work that actually requires human judgment.

To be clear, I’m not saying ignore performance problems that are affecting your customers. If your app is slow, fix it. But proactive performance engineering as an operational discipline? That comes after you know what you have, what it costs, and that you’re not paying a premium for it by default.

Get the house in order first. Know what you have, why you have it, and what it costs. Make sure the foundation isn’t working against you before you optimize anything on top of it.

Where to Start on Monday Morning

If this message lands and you’re wondering where to begin, there are two steps (and the order matters).

Step One: Visibility and Ownership. This is your audit layer. Before you can manage costs, you need to know what you have and who owns it.

• Tag everything. If a resource doesn’t have an owner and a purpose, flag it for review.
• Set up billing alerts so cost spikes surface immediately, not at the end of the month when someone notices the invoice.
• Review instance utilization weekly. If something is consistently running below 20% utilization, have a conversation.
• Make cost visibility part of your team’s existing dashboards, right next to latency and error rates.

Step Two: Automate the Rate Layer. Once you know what you have, lock in your compute costs. Reserved Instances, Savings Plans, Azure Reservations, and Committed Use Discounts shouldn’t be a quarterly conversation someone has with a spreadsheet. That’s toil. Accountants don’t do calculations by hand anymore, so why should we? Instead, your time should be spent on higher-leverage activities. Own the tooling that handles rate optimization continuously, so that as your infrastructure evolves, your discount coverage evolves with it. This is the foundation that makes everything else in Step One actually matter.

None of this requires a new team. It requires the team you already have to own it and the discipline to automate the parts that don’t need a human in the loop.

Back to “The Goal”

Let’s come back to Goldratt. The goal of a business is to make money by increasing throughput while reducing inventory and operational expense. We’ve spent the last two decades focused on throughput – shipping faster, deploying more frequently, removing bottlenecks in the delivery pipeline. That work mattered.

But we’ve largely ignored the other side of the equation. Operational expense isn’t someone else’s problem. It isn’t a separate discipline that needs its own team, its own title, its own conference track. It’s a natural part of operational maturity, and it’s always been there, waiting for us to get to it.

Right now, implementing FinOps at the engineering level is even more important with the rise of AI workloads and agents. Teams are experimenting more, which means there’s a greater risk of unmanaged compute costs.

FinOps isn’t new. It’s the work we should have been doing all along.