N100FN100F
Published on

FinOps without a FinOps team

An SME does not need a FinOps function to practise it. It needs clear owners, a short monthly review and decisions on the record. A minimum operating model that works.

Service line FinOps Engineering

The myth of the dedicated team

A good deal of what is written about FinOps assumes a large organisation, with a dedicated team, its own tooling and a committee. An SME has none of that, and its cloud bill can still be one of its most significant and least understood spend lines.

The good news is that FinOps does not depend on the size of the team, but on three functions talking to each other with data: whoever decides the business, whoever pays and whoever builds.

Three functions, one review

The monthly rhythm of FinOpsA monthly calendar with close, report and review, and a matrix of who does what across management, finance and engineering.FINOPS · OPERATING MODELThe rhythm of a monthTHE MONTHLY CALENDARday 30Days 1–3Close and reconciliationAutomated pipelineDay 4Report publishedThe same one for everybodyDay 9Monthly review1 hour · 3 functionsContinuous: variance alerts and detection of resources with no ownerWHO DOES WHATManagementFinanceEngineeringKeep the data reliableCRPrepare the reportRCExplain the variancesCRDecide whether the spend is worth itRCCR: responsible for doing it · C: brings contextN100F · n100f.com

Management brings the value question: which products matter, what growth is expected, what risk is acceptable.

Finance brings the budget, the forecast and the reconciliation against the bill.

Engineering brings the technical context: why something went up, what can be optimised and how much a change costs before it is made.

The three meet in one short monthly review (an hour is enough) with the same report in front of them.

The minimum that has to exist

  1. One owner per application, by name. Not a generic team: a person who explains the cost of their application when it moves.
  2. A single report, built on corrected and allocated data, that everyone reads the same way.
  3. A unit metric and a budget for each relevant application.
  4. A record of decisions: what was decided, why and with what expected result. That is what makes it possible to learn from one month to the next.

What can be automated from day one

  • Loading and normalising the billing data.
  • Variance alerts against budget.
  • Detection of untagged and idle resources.
  • Cost estimation on every infrastructure change.

What cannot be automated is the conversation: deciding whether a spend is worth what it costs remains a decision for people, and that is what the review is for.

The role you do need

Even with no team, you do need somebody to drive the practice: to keep the data reliable, prepare the report and run the review. It can be an internal person with part of their time, or outside support. What matters is that the role exists and has continuity.

How we apply it: FinOps Engineering.

If your cloud cost keeps growing and nobody knows why, or your architecture depends on whoever built it, let’s talk.

Let’s talk