Two organisations I have worked with had almost identical tooling. Same cloud, similar spend, the same commercial cost platform, dashboards built by people who knew what they were doing. One cut its unit cost by roughly a fifth over a year. The other spent eighteen months producing beautiful reports that changed nothing. The difference was not technical. In the first, a named person could tell an engineering director that a workload had to move, and that instruction stuck. In the second, the FinOps analyst reported three levels below anyone who could approve a change, and every recommendation ended as a polite item in someone else’s backlog.

That is the whole subject of this part. Every technique in this series so far produces a recommendation, and a recommendation is worth exactly as much as the organisation’s ability to act on it. Structure, reporting line and decision rights are what convert analysis into a changed bill, and they are chosen far less deliberately than the tooling is.

What a FinOps team is, and what it is not

A few definitions first, because this part uses organisational vocabulary rather than technical vocabulary and the words are used loosely in most companies. An operating model is the written answer to who does what, who decides, and how often. A persona, in the framework’s language, is a broad stakeholder group rather than a job title, so Engineering as a persona might be four hundred people across nine teams. A FinOps champion is somebody in an adjacent role, usually an engineer, who takes on cost work for their own team without joining the FinOps team. Decision rights mean who can say yes and have it happen, as opposed to who can recommend.

The framework is careful about the term FinOps team, and the care is worth copying. It refers to the group of people who enable FinOps, however they are organised and whatever they are called. That group may be a central team, a virtual committee drawn from finance and engineering, a hub and spoke arrangement, or a function running inside a platform engineering team or a cloud centre of excellence. Some organisations call it the Technology Business Office. The label does not matter. The reporting line does.

What a FinOps team is not is the department that owns cloud cost. That framing is the single most common way these teams fail, and it fails in a specific way: engineering stops feeling responsible for spend the moment somebody else is accountable for it. The team’s job is to make cost legible and decisions possible. The spend stays owned by whoever creates it, which is the entire point of everything covered back in Part 5 and Part 6.

Six roles, and the order they appear in

The Foundation documents six common roles inside a FinOps team, plus two that show up less often. Nobody starts with six. Almost everybody starts with one person doing all of them badly, which is fine and is how it should go. What is useful about the list is that it tells you which specialisation to hire next when the one person starts drowning, and the answer depends on what is breaking.

Role definitions from the FinOps Foundation paper on building FinOps teams, last updated December 2025. The hiring triggers in the third column are mine, not the Foundation’s.

Two roles appear less often and are worth knowing about: a FinOps Technical Writer, who turns process into documentation people actually read, and a FinOps Program Manager, who runs the initiatives across teams. Both tend to show up only in large practices, and in smaller ones the lead absorbs them. My own view is that the Educator role is the most consistently underrated of the six. A practice that trains well needs fewer analysts, because the questions stop arriving.

flowchart TD
  A{Do you have more than one business unit with its own budget} -->|No| C[Centralised, one team, one process]
  A -->|Yes| B{Do those units already act on cost without being asked}
  B -->|No| C
  B -->|Yes| D{Do you need consolidated visibility across all of them}
  D -->|Yes| H[Hub and spoke, central core plus embedded members]
  D -->|No| E[Distributed, practitioners embedded in each unit]
  C --> R[Revisit when a second unit gets its own cloud budget]
  H --> R
  E --> R

Centralised, distributed or hub and spoke

There are three documented structures and the choice between them is genuinely consequential, so I will give a verdict rather than a survey. Centralised means the whole team sits in one functional area. Distributed means practitioners are embedded in and report into finance, product or engineering teams. Hub and spoke means both: a central core, plus embedded members who usually keep a dotted reporting line back to the hub.

Structure guidance from the FinOps Foundation, read July 2026. The strength and cost columns compress the Foundation’s notes plus my own experience of watching each one fail.

The verdict: unless you are already large, complex and confident that individual product teams hold themselves accountable, start centralised. Distributed sounds attractive because it puts the practitioner close to the work, and it fails quietly for a reason that has nothing to do with skill. Embedded practitioners with no dotted line home drift into whatever their host team values, and within a year you have four incompatible definitions of cost per customer and nobody who can reconcile them.

There is a cheap intermediate step that many organisations miss. You can keep a centralised team and get much of the hub and spoke benefit by running a champions programme, where a nominated engineer in each team carries cost work locally without changing reporting lines. It costs no headcount, it gives you a named contact in every team, and it is reversible. I would try that for two quarters before restructuring anything.

Where should the team report?

The framework’s position is that FinOps teams tend to report to whichever executive is responsible for making technology investment successful, and the survey data bears that out. State of FinOps figures cited by the Foundation put the CTO as the owning executive for around 40 percent of respondents, with the CIO next at around 20 percent. That leaves a substantial remainder spread across the CFO and others, which is itself informative: there is no consensus, and the right answer is organisation specific.

Two failure modes sit at either end. Place the team under finance and it will be read as a cost policing function, which poisons the collaboration the practice depends on. Place it deep under engineering and it loses financial rigour and influence over budget decisions. The other variable is depth, not just branch. The further the team sits from the people who make decisions, the weaker the link between an insight and any action taken on it, and burying a good team four levels down is a reliable way to waste it.

Sizing the team without inventing a ratio

Some organisations set an internal guideline along the lines of one analyst per so many millions under management, and the Foundation acknowledges the practice while being clear that it is only one input. The others are the number of business units, products and teams supported, the complexity of the technology environment, and the maturity of the practice itself. The Foundation’s own framing is that the right size is less about hitting a ratio and more about resourcing the function to meet the organisation’s goals, which is correct and unhelpfully unquantified, so here is a way to make it concrete.

Score the drivers rather than the spend. Every business unit with its own budget is a recurring relationship. Every additional cloud or major scope, meaning public cloud, private cloud, data centre or AI workloads, is a separate data model and a separate set of optimisation levers. Every one of those is roughly a fixed monthly cost in practitioner time regardless of how many dollars flow through it.

Stage descriptions follow the Foundation’s small, mid and large guidance. The one published growth data point I would anchor on: HSBC went from three full time practitioners in 2019 to 44 by 2025, tracking scope and maturity rather than spend alone.

You do not have to fill every box with a hire. Contractors, consultants and champions all count, and so does automation. Forecasting and anomaly management in particular lean on historical data and pattern recognition, which makes them reasonable candidates for tooling and increasingly for AI assistance. That extends what a given practitioner can cover. It does not remove the role, because the constraint on a FinOps team is almost never analysis throughput. It is the number of conversations one person can sustain.

Decision rights and the monthly rhythm

An operating model that only says who is on the team is half written. The other half is who decides what, and when the decision gets made. The framework uses a three level model for responsibility across capabilities: Own means you are the primary driver doing the hands on work, Contribute means you actively participate without owning the outcome, and Observe means you stay informed and little more. Writing that grid out for your top ten capabilities takes an afternoon and settles arguments that otherwise recur for years.

The distinction that saves the most pain is between decision authority and advisory input. Finance may own budgeting for the organisation while the FinOps Financial Analyst owns it from within the practice. Both statements are true and they describe different things, and if you have not written which is which, every commitment purchase turns into a fresh negotiation about who signs.

My advice on mechanism: use the governance forums you already have. New committees invented for cost attract poor attendance and quietly die, whereas a standing cost item on an existing architecture review or a monthly business review inherits an audience and a chair who can compel a decision. The framework says the same thing in more diplomatic language, and it is one of the few pieces of organisational advice that is nearly always right.

flowchart LR
  W[Weekly: anomalies triaged, owner named] --> M[Monthly: unit cost review with each business unit]
  M --> Q[Quarterly: commitment posture and forecast reset]
  Q --> H[Half yearly: maturity assessment, team shape reviewed]
  H --> W
  M --> E[Escalation into an existing governance forum]
  E --> D[Decision recorded with a named owner and a date]
  D --> W

Four ways these teams get wasted

The first is the wrong executive sponsor. The Foundation is unusually blunt about this: positioning FinOps beneath an executive who is not educated, motivated or bought into the mission will likely produce poor results. I would go further. A disengaged sponsor is worse than no sponsor, because the team gets the appearance of backing without any of the substance, and everyone else works that out before the team does.

The second is measuring the team purely on savings. Savings and cost avoidance are legitimate measures of value and the framework lists them, but if that is the only number, the team optimises for the reportable win and stops doing the unglamorous allocation and enablement work that makes everything else possible. Pair it with adoption measures: how many teams use the dashboards, how widely FinOps data appears in decisions.

The third is the practice that exists only in one person’s head. FinOps leads move on, and the Foundation notes how common those moves are, into consulting, vendors, or promotions into infrastructure and cloud leadership. If the operating model, the decision grid and the cadence are documented, the practice survives that. If they are not, the practice restarts.

The fourth is treating structure as permanent. The framework’s more mature stages describe teams that review their own size, roles and placement regularly and adjust. Most organisations set a structure once, during a reorganisation, and then live inside it for four years while the estate underneath it changes completely. Put a review on the calendar at a fixed interval, and make it a real review with the authority to change the answer.

Name one owner and give them a standing agenda slot

The recommendation for this part has two moves and neither needs budget. Name one person as the FinOps lead, even at twenty percent of their time, and write down what they own, what they contribute to and what they merely observe. Then get that person a recurring slot in a governance forum that already exists and already has an executive in the room. That is the whole first quarter, and it does more than a restructure.

Keep the structure centralised while you do it. Add champions in the teams that produce the most spend, because that gives you reach without a reorganisation and tells you which teams would justify a genuine spoke later. Only move to hub and spoke when you can point at a specific decision that is being delayed because the central team is too far from the work. If you cannot name that decision, the restructure is theatre.

Part 20 closes the series with tooling, the maturity model and a roadmap for the next twelve months, which is where the team and cadence built here get pointed at a sequence of goals. The reporting this team runs on came from Part 7, the guardrails the FinOps engineer maintains were covered in Part 18, the personas and phases behind all of it are in Part 3, and every part is indexed on the Cloud FinOps guide.

One thing to do this week: write down the name of the person who can approve a cloud cost decision without asking anyone else. If that takes more than ten seconds, you have found the actual problem, and it is not a tooling problem.

References

• Building FinOps Teams: Roles, Structures, Career Paths, FinOps Foundation, last updated December 2025
• FinOps Practice Operations capability, FinOps Framework, including the crawl, walk and run maturity descriptions
• FinOps Personas, core and allied, FinOps Framework
• What is a FinOps Champions Program, FinOps Foundation
• Adopting FinOps, the stages of adoption, FinOps Foundation

Role names, team structures and maturity stages were read from FinOps Foundation material in July 2026 and are revised periodically. The 40 percent CTO and 20 percent CIO figures are State of FinOps survey results as cited by the Foundation; the third bar in the chart is the arithmetic remainder rather than a published category. Sizing guidance in the stage table is my own compression of the Foundation’s small, mid and large descriptions and is not a published ratio. The exact current State of FinOps survey year and sample size for the ownership split should be confirmed against the live data set [VERIFY].

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts