Do not start by cutting costs. Start by defining what to do, who does it, how it gets done, and when.
Three documents carry you through the setup phase: a FinOps Strategy, a FinOps Operating Model, and a tailored Best Practices guide.
Once those three exist, execution (allocation, optimisation, operations) has a foundation to sit on. Without them, every iteration is improvised.

The instinct is to jump into cost cutting. Don’t.

Ask most people where to start with FinOps and the answer comes back fast: find the waste, right-size the instances, buy some RIs, tag what isn’t tagged. Start saving money on day one.

That instinct is wrong — or at least, premature. You can shave 5% off a bill in a week with some quick wins. I’ve done it. It feels productive. But a month later the bill drifts back up, because nothing about how decisions get made has changed. The same engineer who over-provisioned the instance is going to over-provision the next one, and nobody agreed on who owns that conversation.

The FinOps framework as published tends to get read as a linear sequence — Inform → Optimise → Operate. Follow that literally and you start in the middle. The organisational work that should come before Inform often gets skipped, and then the “why isn’t this sticking?” question shows up six months later.

Start with the organisational work. Then the technical work has somewhere to land.

The three documents that come first

Four questions need answers before FinOps has a foundation:

What needs to be done, and which best practices apply? Who handles each task? How are tasks carried out (processes)? When do they run, and how long do they take?

Three documents answer those four questions. Build them in order.

1. The FinOps Strategy

A strategy document does one thing: it says where you are, where you want to be, and how you plan to get there. For FinOps, that means four sections:

As-is state. Honest assessment of current practice. Not what the framework says, what you actually do. Who touches the cloud bill today? What gets allocated? What gets optimised? What is completely manual? Write it down, however ugly it looks.
To-be state. What does “good” look like for your organisation? This is not a copy of the FinOps Foundation maturity model. A 50-person SaaS startup and a 20,000-person bank should have very different to-be states.
Gap analysis. The delta between the two. Each gap is a candidate workstream. Some gaps are capability gaps (we don’t have the skill), some are process gaps (we have the skill but no agreed way to use it), some are tooling gaps.
Roadmap. Realistic milestones over 6 to 18 months. Emphasis on realistic. A roadmap that says “full FOCUS adoption in Q2, unit economics in Q3” when you don’t even have tagging in place is a work of fiction.

The strategy should fit on a few pages. If it runs to 40 slides, it is not a strategy — it is a theatre piece.

2. The FinOps Operating Model

Once the strategy exists, the operating model defines the machinery that delivers it. Think of it as the target operating model (TOM) adapted for FinOps. Three components:

Organisational design. Where does the FinOps function sit? Who does it report to? Does it live under Finance, under Engineering, under a CTO, under a CFO? Is it a centralised team, a center of excellence, or a distributed model with embedded practitioners? There is no universally right answer — but there is a right answer for your org, and the wrong answers create friction every single day.

Execution and rollout. How are FinOps changes rolled out to engineering teams, finance teams, and business owners? Who communicates what, to whom, when? This is also where the FinOps KPIs and metrics live — the numbers the function is measured on, aligned to the strategy’s to-be state.

FinOps governance. The main FinOps domains (cost allocation, rate optimisation, workload optimisation, anomaly management, forecasting, and so on) broken down into processes. Each process has:

A RACI — who is Responsible, Accountable, Consulted, Informed
A cadence — how often it runs
A desired outcome — what finishing it looks like
Metrics — how you know it’s working

If a process doesn’t have those four attributes, it isn’t a process. It’s a hope.

3. The FinOps Best Practices Guide

Now the tactical layer.

There are many ways to achieve the same FinOps capability. Cost allocation can be done through tagging, through account/project hierarchy, through a hybrid of both, through showback vs. chargeback. Commitment management can be centralised, federated, or automated via third-party tooling. None of these are universally right.

The best-practices guide takes the generic FinOps playbook and customises it for your organisation. For each capability, it answers:

Which approach are we using?
Why this one over the alternatives?
What does the desired outcome look like when followed correctly?
What are we explicitly not doing, and why?

The last bullet is the one most guides skip, and it’s the most useful one. Calling out what you’re deliberately leaving out prevents well-meaning team members from quietly adding scope.

The order matters

The sequence is not arbitrary. Strategy defines the destination. The operating model defines the vehicle. Best practices define how to drive. Do them out of order and you get a team driving fast in the wrong direction — or a perfectly-documented process that nobody knows how to apply.

 ┌────────────────┐    ┌────────────────┐    ┌────────────────┐
 │  Strategy      │ ──►│  Operating     │ ──►│  Best          │
 │                │    │  Model         │    │  Practices     │
 │ Where are we?  │    │ Who does what? │    │ How do we      │
 │ Where to?      │    │ How? When?     │    │ actually do    │
 │ How to bridge? │    │ How measured?  │    │ each task?     │
 └────────────────┘    └────────────────┘    └────────────────┘
         │                     │                      │
         ▼                     ▼                      ▼
   Sets the goal         Builds the            Gives teams the
   and direction.        machinery to          concrete playbook.
                         deliver it.

Only after those three exist does execution make sense.

Different cooks, different recipes

There is no universal “start here” for FinOps. Anyone who sells you a single linear path is selling you a product, not a method.

But there is a shape to a good start, and the shape is organisational first, operational second. Set clear goals. Build clear structures. Write down what you agree on. Then and only then start running the capabilities — allocation, optimisation, forecasting — against the foundation you built.

Skip the foundation and you’ll still make progress. For a while. Then it will unwind, and you’ll be back here wondering why.

Summary

FinOps does not start with optimisation. It starts with organisational clarity.
Three documents, in order: Strategy (what and where), Operating Model (who, how, when), Best Practices (the how in practical detail).
Customise every document to your organisation. The framework is a template, not a mandate.
Once the foundation exists, execution becomes obvious. Without it, execution is improvisation.

Thanks for reading. If this helped, share it. Questions or topic suggestions — send them through.

FinOps: Where Do You Actually Start?