Peter Crenshaw spent nearly twenty years at Kronos, now part of UKG, building cloud cost analysis before FinOps tooling existed and running IT diligence across roughly twenty-five acquisitions. He now leads FinOps, M&A and IT business partnerships at IEM.
Ask most people when FinOps enters the picture, and they will point to the moment a cloud bill grows large enough to frighten someone. Peter Crenshaw applies it earlier. He applies it before the company is even bought.
His own entry came the way it did for many early practitioners: a bill nobody could read. For nearly twenty years at Kronos, the workforce-management company that merged into UKG in 2020, Peter worked from technical support up to running cloud infrastructure. When a product the company had built on Google Cloud went live, the spend climbed and the invoice arrived as a single line item, Cloud services from GCP. He pulled it apart by hand, in spreadsheets, until he maxed out Excel. That is how Peter took his first steps into FinOps, before the discipline had a name or a tool.
A second discipline found him through the same instinct. Because he could speak the language of finance, he was pulled into the IT side of merger and acquisition diligence, sizing up what target companies were really running across roughly twenty-five deals. Today he does both jobs at IEM, an industrial manufacturer, building a FinOps practice as a team of one. He builds things by hand, the way he has built everything else. FinOps, in his telling, is not a discipline for shrinking a bill. It is a seat in the decision before the decision is made, and a translator the business cannot replace.
Bringing FinOps Into the Deal Room: From Diligence to Integration
An acquisition is one of the few moments when a company opens its books to outsiders and has to decide what it is really buying. The technical diligence that follows usually treats cloud and infrastructure spend as a single figure to confirm and budget around. Peter's argument is that the figure hides the work. The same lens a FinOps team uses to find waste in a live environment can find it in a target before the deal closes, and it shapes what happens to that infrastructure long after the deal is signed.
Q: FinOps and M&A diligence are usually two different jobs in two different teams. How did they end up in the same one for you?
I kind of stumbled into it, because I was doing both roles. Usually they are very independent. The FinOps team is focused on engineering and spend, and the strategy or business enablement team is focused on the M&A side. They may not even talk to each other. Because I was part of both worlds, it came together, and I realised the value of it.
Q: What does a FinOps lens see in a target that a standard review does not, and how does it change the deal?
Standard diligence asks the high-level questions. What is your total spend, what is your budget for the year. Through a FinOps lens you go deeper. Say a company is carrying a stack of savings plans it never managed. Someone who only looks at total cost sees total cost. FinOps sees the plans that are not being used, cuts them, and reduces what you spend. That matters because savings found are funding you redirect the day after close, into other areas or into recouping the purchase faster. The data center side works the same way. You overlay spend on the target's hardware and its age, and you see what has to be replaced before you own it. That beats getting caught on day one with infrastructure that is ten years old and out of warranty.
Q: And once a deal closes, how do you decide what to do with the infrastructure you have just acquired?
It comes down to intent. If we wanted the product line, we kept the lights on with their existing stack, connected it so we could offer the feature, then built a roadmap to migrate it into our own product and move their customers over. If it was a direct competitor we just wanted the customers from, we put it on live support, set sunset dates for the hardware and software, and offered incentives to move people onto our product line. And if it was going to stick around as its own offering, we brought it up to our standards. Same monitoring, same security tools, so our larger infrastructure teams could take it over, instead of running a separate satellite team for one technology.
Knowing What the Numbers Can Move, and What They Can't
An analysis is only worth what it changes. Peter's has changed deals. It has also taught him exactly how far a number can be trusted. The two facts are connected. The authority to stop a deal is earned by the honesty about what the estimate cannot see.
On more than one deal, the IT investment a target needed ran far past what the business had assumed. Infrastructure was aging, out of warranty, and would have to be rebuilt soon after close. Left unexamined, that cost would have landed after the purchase, not before it.
The findings tipped the scales. Rather than buy the whole business, the company carved out only the piece it actually wanted and left the rest. On other deals the numbers, weighed against what other teams were finding, stopped the acquisition entirely. The analysis did not just inform the price. It changed what got bought.
Q: When you projected those numbers and then watched the company run for real, how close were you?
It was never a hundred percent. There is always a big disclaimer, in bold, at the top and the bottom. This is an estimate based on the data available. With good data, and time to get in there myself, I would be around seventy-five percent on year one. When the data was thin and I could not get in, it was closer to thirty or forty. There is always a renewal that did not get listed, something that was not on a spreadsheet, something a contract did not mention.
Earning the Finance Seat: Why the Questions Come to FinOps
FinOps is usually drawn as an engineering function, reporting up through the CTO. Peter's day looks different. The people who keep coming back to him sit in finance, and they come back because of what they get when they ask.
Q: You report through engineering structures, yet you spend most of your time with finance. Why does the discipline pull that way?
Finance realised FinOps has the answers. They used to chase engineering leaders and get back gibberish they could not use. They ask the FinOps team and get an answer in terms they understand, with quality data behind it. Before, finance would ask why a cost went up six months running. Engineering would say new feature, or new customers. It told them nothing. Now there is a team that translates the technical answer into a financial one. They stop chasing four engineering leaders and come to the one team that can answer. They like the answer, and they keep coming back.
Q: Does that pull get stronger as AI and infrastructure costs climb?
A hundred percent. They come to that team for any technology stack now. What is on the roadmap, how does it change spend, what do we need to factor in to protect the company. When an IT leader walks in and asks for a million dollars, finance needs to know how much can be capitalised, how much is operational, how much is software. That is a different language, and FinOps is what speaks both.
Holding the Frontier: What FinOps Becomes When AI Does the Easy Part
A few weeks after this interview, the FinOps Foundation used its 2026 conference in San Diego to put AI economics at the centre. It expanded its Scopes framework to cover token and inference pricing, and joined the Linux Foundation to launch a Tokenomics Foundation aimed at standardising AI billing across providers. One finding from the event could have come straight from Peter. Teams expected token prices to fall, but constraints on GPUs and energy mean those costs are likely to persist. He had already drawn the line between the work AI can take over and the work it cannot.
Q: Where does AI replace what FinOps does, and where does it fall short?
Some of the initial data analysis and the deep calculations can be replaced by AI, at an efficient cost. That part I am fine handing over. But you can feed all the documents you want into a model, and unless the data is perfectly clean, you get incorrect answers. Someone has to take the ask, translate it, and know that one of three data centers is not reporting well. Keeping a human in the loop keeps the answer close. The person who knows the organisation gets you closer than the model alone.
Q: And the cost of AI itself? Where does that go?
As with everything, the cost eventually bounces. Tokens may get cheaper as efficiencies come in, but the back-end compute keeps climbing, because as the data grows it takes longer to churn through. Companies are moving everything to AI as fast as they can, just to say they have, and those costs catch up. I read about surprise AI bills all the time. A lot of the ROI just is not there yet. In three years it is a different landscape. In five, different again.
Key Takeaways
Peter Crenshaw's perspective reframes FinOps as a strategic discipline with these essential insights:
Before the buy. A FinOps lens belongs in M&A diligence, where it surfaces savings and risks a total-spend review never sees.
Savings are the case. Waste uncovered in a target is funding redirected the day after close, which accelerates the return on the deal.
Honest by design. Every projection is an estimate bounded by data access. The disclaimer is the discipline, not a weakness.
Intent sets the road. Integration is not one playbook but three, chosen by why the business bought, not by habit.
The translator's seat. Finance keeps returning to FinOps because it speaks both languages, and that role grows as AI and infrastructure costs climb.
The human in the loop. AI can run the easy analysis, but only a person knows the skeletons in the closet that keep an answer honest.
The Bottom Line
FinOps is outgrowing the cloud bill. The practitioners who matter next will sit in the deal room and the CFO's office, translating technology into decisions before the money is committed. AI will take the easy calculations. The judgment, and the knowledge of where the data lies, stays human. That is the seat worth building toward.
About Peter Crenshaw
Peter Crenshaw spent nearly twenty years at Kronos, the workforce-management company that merged into UKG in 2020, where he built cloud cost analysis before FinOps tooling existed and ran IT diligence across roughly twenty-five acquisitions. He now serves as Director of FinOps, M&A and IT Business Partnerships at IEM, a manufacturer of industrial electrical components, building the practice as a team of one. He has presented at FinOps X on the observability tooling his team built. Connect with Peter on LinkedIn.
Cloud Value Lab publishes practitioner-led thought leadership at the intersection of FinOps, GreenOps, and AI Economics. If you are a practitioner or subject matter expert interested in sharing your perspective, reach out to David May.