June 18, 2026
It's Not That Simple
This post is part of my Medium blog.
FinOps is a combo discipline. Finance plus technical operations. That's not a weakness — it's the whole point. But it means you end up with a mixture of people on the team, and that mixture has to be intentional.
You want people with a finance background. Not just people who know the difference between capex and opex — anyone can memorize that. You want people who understand how finance actually views those two things. How what you're doing affects the balance sheet. How a committed spend program looks different to the CFO than it looks to the engineering manager who signed the agreement. The finance people bring the nuance that engineers don't naturally have, because in finance, "it depends" isn't evasion. It's the honest answer, and if you've worked with people in Finance enough you understand that they don't often have quick answers if people are asking questions like, "how much money will we save if we use this option versus another?"
I'm an engineer. I can understand the capex/opex distinction. But whenever I interact with finance, there are always gray areas. Someone in Finance might say, "Well, it's not that simple. I wouldn't say we have a preference for OpEx over CapEx, but it changes how we need to plan."
That's the thing I've heard the most from finance people. "Wouldn't it be better if we did X?" "It depends."
On the timeline. On which executive has approval authority for that category of spend. On whether the amount crosses a threshold that triggers a different approval process entirely. The answer to almost every financial question in a real business starts with "it depends," and the finance people on your FinOps team are the ones who can explain what it depends on.
You also want people from engineering. People who can jump in and say, "Wait — just because you read that online doesn't mean it's true." Technology is full of quack science. And, when you are looking for cost savings opportunities there's always a vendor at the ready with blog posts designed to sell snake oil to a finance partner.
Vendor-sponsored benchmarks are often presented as independent research — a framing you won't catch until an engineer reads the fine print. And those same blog posts written by engineers often make a financial argument that makes Finance repeat their favorite line, "it isn't that simple."
A good FinOps function has skepticism and validation from engineering next to skepticism and validation from finance, but if you are missing one of those components it is likely you are making bad decisions.
This is especially true with AI. Every vendor has a ROI calculator. Every consultant has a framework. Every LinkedIn post has a case study that conveniently omits the context that would make it less impressive.
Every major frontier model that is announced from Fable to GLM 5.2 to GPT-5.5 has a blog post with cost numbers and benchmark results that don't tell the whole story.
You need someone on the team who can look at a claim and say, "Let's look at the motivation of the person who wrote it. This is from a vendor."
The challenge in FinOps is always trying to get to the point where you can state, for the record, that you've objectively factored in all complicating factors. That's the goal. Not a simple answer. A complete one.
If you're a small company and your cloud bill is a hundred dollars, there are easy questions you can answer quickly. But if you're doing anything in the real world — at scale, with real business impact — you realize that some of these questions can only be answered if you answer other questions first. The migration savings depend on the timeline. The timeline depends on the team. The team depends on the budget. The budget depends on the revenue forecast. The revenue forecast depends on the market. You don't get to the answer by simplifying, and you don't get a better answer by not asking yourself tough questions about strategy.
Nothing in FinOps at scale is easy. The questions are multidimensional. The answers involve many different specialties. The discipline itself sits between two functions that think differently, speak differently, and prioritize differently. That's not a bug. That's the design.
The people who do this work well are the ones who can hold multiple dimensions at once — who can say "it depends" and then explain what it depends on, who can spot the snake oil and also understand why the CFO cares about the amortization schedule. You don't need one kind of person. You need both, and you need them to disagree productively.
The simple answers are for the hundred-dollar cloud bill. Everything else requires the team that can handle the nuance.
I wrote about this kind of team — finance and engineering friction that produces better answers than either side could reach alone — in Redundant.
In Essential, the third book in The Condition Set trilogy, the law that requires a human to remain in the decision loop is ninety days from expiring. Rob Coleman runs the agency that oversees every AI system in Canada. The question isn't whether the machines work. The question is whether anyone can tell when they stop working in the public's interest.