FinOps / business decisions

I also pay the bill.

Alongside the cloud infrastructure and vendor relationships, I also look after the bill. So I introduced the FinOps function at Cloudera to help make sure the right people pay it.

Build a shared understanding

My approach aligns closely with the FinOps Foundation framework. I want people to understand their usage, what efficiency means for their work, how to optimise, how to forecast and how to show the value they are getting from technology.

That takes a joined-up conversation across departments and between the people doing the work and the people setting its direction. Engineering, finance, product and leadership each bring part of the picture. My role is to help those parts connect.

Use language people can work with

Cloud can be intimidating. An engineer may need to understand the cost of an architectural choice. A team lead needs to balance delivery, capacity and budget. Finance needs a forecast it can work with, and a CFO needs to understand the investment, uncertainty and business value.

I adapt the language and level of detail to the audience, while keeping the underlying information consistent. Everyone should understand their role and feel able to take part in the conversation.

Account for the whole cost

I operate cost tracking across the stack, accounting for and allocating spend so it can be traced to the people, teams and departments using the services. That includes full AI spend allocation, with usage costed and attributed at user, team and department level. I am also extending this approach into SaaS and on-premises costs.

The aim is to make every cent explainable: what it supports, who owns it and how it contributes to the business. Shared services need an understood allocation approach too, so that teams can make sense of the costs assigned to them.

Build the maturity the business needs

I took Cloudera from establishing a FinOps practice at the crawl stage to walk, and in many areas to run. That meant developing the knowledge, ownership and working practices alongside the tooling.

I want to understand where an organisation is today and where it needs to get to, across the different areas of spending and capabilities it manages. Allocation may be well developed while forecasting needs more attention. The next improvement should address a real business need.

The Foundation's crawl, walk, run model gives us a useful way to discuss that progress. Maturity can differ by capability; reaching run everywhere is not the objective.

Make FinOps part of the culture

A central team cannot identify and solve every FinOps problem. The people closest to the work understand why resources are there, what can change and what would put delivery at risk.

FinOps champions are key to my approach: people within teams who build understanding, connect colleagues with support and bring problems and solutions into a shared discussion. I support that with practical learning, accessible information and opportunities to learn from one another.

The central function provides the structure and expertise. The organisation needs to share the ownership, with FinOps becoming part of how work is planned, delivered and reviewed.

Turn that understanding into decisions

A rising bill might reflect useful growth, an inefficient design, unused capacity or a change in price. Each calls for a different response. I connect the technical and commercial context so the right people can agree what to do.

Illustrative exampleA discount on the wrong baseline

Illustrative example. This scenario shows how I approach a decision; it is not a claim about a particular employer or a measured saving.

A service's cloud spend has grown. The first suggestion is to buy a longer-term commitment to reduce the rate. That may be useful, but I want to understand which demand we expect to keep before deciding how much to commit to.

Understand the demand

I would bring the service owner into the review and separate ongoing demand from temporary work, idle resources and capacity kept for resilience. Low utilisation alone does not tell us whether something can safely be removed.

Understand what is changing

I would ask about planned migrations, product growth, changes in architecture and the engineering effort needed to improve efficiency. The current bill is evidence of current use; it needs to be considered alongside the service's future.

Compare the available choices

We might remove confirmed waste, change how the service runs, negotiate a better rate or make a commitment against demand we expect to retain. We might also choose to keep paying for flexibility. The decision depends on the workload, the commercial terms and the confidence we have in the forecast.

Make the decision explicit

In this scenario, I would propose removing confirmed waste and checking the expected remaining demand before choosing the size and term of a new commitment. Engineering needs to understand the operational changes; finance needs to understand the assumptions and exposure. Both need a clear owner and a review point.

Link to this example

Follow the decision through

I want to know whether a change delivered what we expected. That means separating estimates from realised results, accounting for changes in demand and checking that we have not moved cost or work somewhere else.

The result I am working towards is an organisation that understands its technology spending, can plan with greater confidence and can explain the value of its decisions.

Back to my experience →