Chapter 6. Adopting FinOps
FinOps is an infinite game. By this we mean that you’re never really done at getting better at it. And you have to start somewhere.
In finite games, like football or chess, the players are known, the rules are fixed, and the endpoint is clear. The winners and losers are easily identified. In infinite games, like business or politics or life itself, the players come and go, the rules are changeable, and there is no defined endpoint. There are no winners or losers in an infinite game; there is only ahead and behind.
Simon Sinek, The Infinite Game (Penguin UK, 2020)
One of the most common questions we hear from the community of practitioners is “How do I get my executive to buy in to the practice?” and, then, “How do I get the organization to adopt the practice across the broad swath of personas critical to its success?”
This chapter works through common approaches to gaining proper organizational support from both the technical and financial leadership of the company. Without that, nascent FinOps practices often get stuck in a reactive midstage maturity battling other priorities in the organization. The chapter also looks at the processes of the FinOps Driver, the person who recognizes the need for the practice and champions it internally.
Figure 6-1 outlines key personas to inform and milestones to accomplish as you help build the practice and culture at your organization.
Figure 6-1. The FinOps Adoption Roadmap, original source Mike Eisenstein and Dean Oliver (Accenture, LLP)
A Confession
While writing the second edition of this book, my coauthor Mike Fuller confessed to me: “In hindsight, we [Atlassian] weren’t serious about FinOps when we wrote the first edition of the book.” Yes, FinOps was one of his areas of responsibility, and he had spent years working and thinking on the patterns of FinOps while managing Atlassian’s cloud spend during their massive migration and growth in cloud, but it wasn’t his full-time job.
In fact, it was no one’s full-time job at the company. There were no top-down C-level codified company goals around FinOps outcomes. Target setting was inconsistent and they were not leaning aggressively into optimizations and processes so much as focusing on low-hanging fruit. He knew what they needed to do and how to get them there, but it was simply not the company’s highest priority. And that was OK. The company was doing informed ignoring—making an intentional decision to focus on other priorities like completing migrations and delivering products more quickly.
At first, my jaw dropped. I had been taking notes on Mike’s advanced thinking around cloud cost management since we first met in 2014 and he—in his quietly authoritative fashion—reset my thinking around a number of core areas like RI strategy and data sources.
However, the more I thought about it, Mike’s “confession” about his own journey (and by extension Atlassian’s) into FinOps maturity was just like everyone else’s. Invariably, you start FinOps as a light practice—or an early maturity one—and over time, as cloud spend grows and company goals align, you transition to taking it more seriously. Mike was always personally obsessed with FinOps, but he had a day job (at the time he was working within Atlassian’s CCoE), and his company (like most) took some time to get to the point where they decided to heavily invest in staffing the FinOps functions and roles needed to promulgate the practice. He is the classic FinOps driver archetype: it starts with a noisy individual, then over time it turns into a company focus with broadly prioritized, executive-sponsored goals.
As we dug into this thinking, we realized that there are generally a couple of levels of practice maturity. This is important to unpack at the start of this chapter, as the pitch you will make to leadership will be very different depending on which level the company is on. Before you pitch FinOps internally, you need to take an honest look at where the company sits in its FinOps journey, which is typically tied to its cloud adoption journey and which outcomes it is most actively prioritizing.
FinOps isn’t about saving money, it’s about making money through data-informed decisions about your cloud technology investments. If your top priority is to get out of your data centers as soon as possible, or to leverage cloud to transform your technology and drive more revenue, then you’re likely not going to get a lot of buy-in to focus on long-tail optimizations; you’ll mainly get support to accelerate migrations.
Though Atlassian was practicing informed ignoring, it didn’t mean they weren’t doing anything. It meant they were selectively leaning into capabilities they saw as critical and being passive about others. Cost allocation was seen as critical to accountability and was aggressively pursued, whereas commitment-based discounts and rightsizing were being done more passively.
There hit a point, though, where Mike knew he needed to convert the passive practice to an actively managed one.
Different Executive Pitches for Different Levels
To ensure you get the most success, let’s turn again to the FinOps maturity model discussed in Chapter 1. At the early stages, you’ll have a certain pitch, based on the outcomes you are looking to achieve. To do that, you must assess where your organization really is.
In the less mature stages, you’re likely doing things that are FinOps adjacent, such as reviewing spending or occasionally making optimizations, but you aren’t doing them in a lifecycle, or running a framework (such as the FinOps Foundation Framework covered in Chapter 7) with capabilities, or adopting a playbook.
Mike later added:
We weren’t doing FinOps in a structured way like we are today. We had been doing it for years in a more ad hoc one. In the middle stages of our FinOps maturity we started setting goals on all the framework capability areas and set targets and thresholds for those capabilities, tracking which ones we aimed to improve, measured the results of our efforts, and reported it out.
Starting Pitch
What the wise man does in the beginning, the fool does in the end.
Warren Buffett
Here are some questions you’ll want to have answers to when pitching initial FinOps adoption:
- Why should you start doing FinOps?
- Consider the first few chapters of this book for help in sharing the why to get started.
- What are the benefits to each executive persona involved?
- Each executive is focused (and bonused) in different ways. If individual executives know the specifics, this will help them build their own cases for supporting the initiative. Later in this chapter, we’ll break down the individual executive challenges, motivations, and benefits between CEOs, CFOs, CTOs, etc.
- What are the benefits to the business in terms of your cloud adoption and the outcomes the organization will receive?
- Consider the main outcomes of the FinOps Framework (which are covered in Chapter 7). Also look closely at your cloud adoption to determine the balance between such benefits as cost allocation, optimization, etc. Cloud adoption goals prescribe where on the Iron Triangle to focus efforts, as discussed in Chapter 26.
- How can FinOps help unblock the pathway to other important initiatives like security, GreenOps, and sustainability?
- We’re starting to see strong overlaps between GreenOps and FinOps teams. They share a set of common underlying goals. Tying sustainability goals to FinOps can help with funding for the ask; two birds, one stone. See Chapter 19 to understand more about how sustainability and FinOps intersect.
- Why do existing financial frameworks not solve the need?
- Existing IT financial frameworks often work in parallel to a FinOps practice by solving a different set of needs in the business. See Chapter 25 to understand how other common frameworks may work together (or not) with FinOps. It’s important to have answers to this question when you encounter those more familiar with traditional IT frameworks who are not used to dealing with massive variability and granularity of spending data unique to the cloud at scale.
Since this is a starting pitch, you won’t yet have a FinOps framework structured that clearly outlines the different capabilities you need within your organization. Instead, you are presenting high-level outcomes that answer questions such as: can you understand your costs and usage, are you able to identify optimization opportunities, etc.?
Advancing Pitch
Here are some things you’ll want to include when pitching to grow a practice’s maturity.
A good starting place is to measure how successful your organization is in individual FinOps capabilities. This allows you to define and pitch where you need to go next. This stage of pitch is focused on how you can invest more heavily into specific areas with specific outcomes you expect to achieve.
Each of the capabilities in Table 6-1 should have a measure of success and a set of outcomes, which is covered in greater detail in Chapter 7. Focus on telling the story of how to hit the outcome you need to hit the target measure of success. Then connect these outcomes to the asks required from the business to achieve them, such as:
Time commitments from other teams
Additional money to be spent or payments to be made up front
Added headcounts in either the FinOps team itself or other teams across your organization
| Domain | Capability | Maturity | ||
|---|---|---|---|---|
| Early | Middle | Advanced | ||
| Understanding cloud usage and cost | Cost allocation | Current | Grow | |
| Managing shared costs | Current | Grow | ||
| Performance tracking and benchmarking | Forecasting | Build | ||
| Cloud rate optimization | Managing commitment-based discounts | Current | Grow | |
| Cloud usage optimization | Resource utilization and efficiency | Build | ||
| Real-time decision making | Measuring unit costs | Build | ||
| Organizational alignment | FinOps intersection with other frameworks | Current | Grow | |
Here are some examples of capability outcomes you’ll want to highlight with additional investment in the practice:
- Cost allocation
- Improve the percentage of costs being correctly allocated to teams.
- Forecasting
- Increase reliability and predictability, etc.
- Measuring unit costs
- Identify teams that can start measuring a business value metric for a set of products and tie it back to their reporting to use in their value conversations.
- FinOps intersection with other frameworks
- Provide alignment between teams managing other finance practices and FinOps within the organization, reduce duplication of work, and improve consistency of reporting on cloud spend.
- Budget management
- Improve the ability to both stay inside of forecasted budgets and to “shift left” proactive budget management such that engineering teams proactively predict the cost impact of changes and raise awareness to budget leaders when material impacts are expected.
State of FinOps 2022 data showed early stage teams tend to be 1–3 people, whereas advanced stage companies tend to have upward of 13 dedicated people helping to enable FinOps in the organization. The most recent survey data can be found on the FinOps Foundation site.
Going back to Mike’s case, improving cost takeouts was the original pitch. But in the advancing stage, it has become all about engineering efficiency. He looked to answer the question of “How can we keep engineers from getting bogged down and increase the velocity of releases?” He knew that improved engineering cost efficiency would allow his technology leader to save money and enable funding of additional projects and headcount: “Give us some money now to improve our FinOps practice, and you get more money later to do more innovative things with more engineers.”
Overspend can limit technology team velocity. Too often when teams overspend, they are told to pull back on feature development and focus on reducing costs by burning down a backlog of waste. Ideally, teams are structured to keep ahead of the problem from day one and are cost architecting as they go to prevent slowdowns. It’s a classic maintenance and KTLO (keep the lights on) approach versus getting bogged down in firefighting. This enables predictable, smooth engineering workloads instead of large spikes of effort that take their attention away from releases when the waste gets too high. This concept is often a key part of your pitch to advance your practice.
FinOps can present a large palette of things to solve in the organization. Each will be different. The complete picture could go as far as influencing what the business decided to invest in. Table 6-2 shows some examples of the focus areas to present to different personas.
| Persona | Focus |
|---|---|
| Business leaders | Leverage cloud to be more competitive |
| Engineering | Innovate while increasing cost efficiency and speed of delivery |
| Finance | Understand, allocate, and predict cost accurately |
All are interested in cost savings to some degree, but each has different core motivations. Today, fewer companies are starting with zero FinOps; most have some level of FinOps activity already happening. So you need to paint a picture of where you are today, where you are going, and the benefits of that long journey.
Sample Headcount Plan for Advancing a FinOps Team
Table 6-3 is a sample headcount plan as part of an advancing FinOps pitch made to a technology executive. It includes additional headcount for key areas such as data engineers to ingest/normalize the billing data and related feeds, analysts to interrogate the data and prepare reporting for the organization, cost engineers who embed within service teams to uplevel their usage optimization skills, automation engineers to connect various FinOps services and provide templates to the organization, and leads who manage the FinOps team itself.
| Financial year | Data engineers | Analysts | Automation engineers | Team leads | Funding required |
|---|---|---|---|---|---|
| FY22 | 2 | 1 | 1 | 1 | |
| FY23 | 2 | 2 | 2 | 1 | +2 |
| FY24 | 3 | 3 | 2 | 2 | +3 |
| FY25 | 4 | 5 | 3 | 2 | +4 |
Your advancing FinOps pitch should include the outcomes you expect to see happen once you get the resource needed. For example, the organization needs $X million of commitments to reduce rates, three new headcounts, and commitments from these three other teams (finance, engineering, and procurement) to build out a business value model.
Pitching the Executive Sponsor
As of 2022, State of FinOps data shows that the majority of FinOps teams report to a technology executive like the CIO or CTO. A growing number report to a CFO for Technology or a related hybrid role. The first part of your pitch is to paint the picture to the CTO (or the right CxO for your org) where you stand today. This includes covering what reporting visibility is in place as well as an assessment of the company’s maturity along key capabilities of the FinOps Framework. We recommend starting with the open source FinOps assessment available on the FinOps Foundation website.
Most importantly, you need to portray what you expect to change in the company’s culture and ways of working once the next phase of the practice is implemented.
Here are some questions you can answer in your pitch:
How does the daily work of an engineer change?
What programs and rituals does the organization need to introduce?
How do engineering managers start to think about FinOps?
How does the organization ensure they have the right resources?
Digging into visibility advantages, what unit economics and reports could the organization drive?
Here are some more questions that begin to model some specific scenarios:
In what mix should the organization plan to achieve cost avoidance: by focusing more on usage reduction or more on rate reduction?
How many more SPs or CUDs could the organization have if they had more time and people to focus on maintaining them properly?
How much more you could have saved in the last year if you were able to manage commitments and resource utilization more effectively?
What do you need to change so when you perform a lookback a year from now, your efficiency is markedly improved?
How much more usage reduction could the organization do if they had whole company goals or better executive support for such changes?
The pitch should cover what it really means for the company. It is not simply about the amount of money it costs, the number of people needed, and the dollars saved. At Atlassian, as it is in most companies, it was important for the CTO to think through the impact of adopting FinOps on the engineering team (a technology company’s most important asset) before moving into the value proposition of savings and efficiency it would drive.
So before making the pitch to the Atlassian CTO, Mike got feedback from relevant teams. He interviewed finance about pain points they had around allocation of spending and accurate forecasting of variable spending. He talked to engineering service owners about how much visibility they currently had into cost and what they would need in order to be able to explain to leadership what had happened when anomalies occurred. Through all the conversations, he looked at how the central FinOps team he was pitching could help.
These conversations also began to prepare the teams for the changes that were coming: service owners would be expected to know what their costs were and to be prepared for discussions when spending changed. He also began to socialize the critical strategy of putting data in the path of the engineer (see Chapter 8 for details on this concept). He began to set expectations for what each level of engineering would do once the more structured FinOps goals and practice were rolled out.
In Mike’s case, funding came from the CTO, so the conversation was centered around engineering gains. When pitching to a CFO, the focus should be more on ensuring better reporting of costs via cleaner allocation, more accurate forecasting, and lower variances against budget targets that could be improved with more investment.
Playing to Your Audience
When proposing the adoption of a FinOps function within an organization, brief a variety of personas among the executive team (engineering leadership, finance leadership, etc.) to gain approval, buy-in, and involvement in conducting FinOps and achieving its goals.
Each executive team persona is described below, in terms of their goals, concerns, key messaging, and useful KPIs. By understanding the motivations of each executive persona, a FinOps champion will be able to describe the value of FinOps more effectively, minimizing the time and effort to gain alignment.
Key Personas That the Driver Must Influence
Figure 6-2 shows how the FinOps team and driver persona sits initially in between all the various stakeholders helping to translate needs and build bridges that allow them to work more closely together autonomously.
Figure 6-2. Persona interactions with the FinOps driver
For a more comprehensive look at various personas and roles involved in building a FinOps practice, see the individual personas motivations in Chapter 3. Parts of the following sections are adapted from the Adopting FinOps open source project.
CEO Persona
When it comes to a FinOps practice, the CEO’s goal is to ensure that cloud investments are aligned with business objectives. See Table 6-4 for examples.
| Objectives | Frustrations | Key metrics | FinOps benefits |
|---|---|---|---|
Accelerate company growth YoY Strategic competitive advantage Faster time-to-market Deliver innovative, market-leading solutions cost effectively | Unpredictable, sometimes chaotic, cloud spend Unable to see link between engineering initiatives and business objectives Unsure of the return on their company’s cloud investment | Revenue growth Gross margins COGS (cost of goods sold) Unit cost economics | Manage risk Connect engineering decisions with business outcomes Predict how cloud spend will grow as the business grows Guide organization to make good cloud investments |
CTO/CIO Persona
Leverage technology to give the business a market and competitive advantage. See Table 6-5 for examples.
| Objectives | Frustrations | Key metrics | FinOps benefits |
|---|---|---|---|
Accelerate company growth YoY Strategic competitive advantage Faster time-to-market Deliver innovative, market-leading solutions cost effectively | Extreme pressure to either justify or bring down the cloud bill No guardrails on spend Unsatisfied engineers Business continuity Reliability | Revenue growth Gross margins COGS Unit cost economics Time to market for new features/product Engineering productivity Track R&D versus production spend Maintain operations within budget | Predict how cloud spend will grow as the business grows Drive organization to make good cloud investments Enable engineering organizations to gain more freedom to utilize newer cloud technologies and deliver solutions to market faster |
CFO Persona
Increase accuracy and predictability of cost reporting and forecasting. See Table 6-6 for examples.
| Objectives | Frustrations | Key metrics | FinOps benefits |
|---|---|---|---|
Cost visibility and granularity, and accuracy Overall cost-per-unit/COGS reduction Managing costs during growth, disproportionate cost reduction during flat/declining periods | Unpredictable, sometimes chaotic, cloud spend Unsure of the return on their company’s cloud investment Cost fluctuations and innovation do not align to budgeting cycles | Revenue growth Gross margins COGS Unit cost economics Predictability | Increased accountability for cloud cost Increased reliance on budget and forecast models Direct impact on company bottom line |
Engineering Lead Persona
Increase speed of delivery while also being cost-effective and enabling innovation. See Table 6-7 for examples.
| Objectives | Frustrations | Key metrics | FinOps benefits |
|---|---|---|---|
Drive accountability to engineering teams that are responsible for the application/services Provide guidance to engineering teams to have a cost-effective application/service by identifying anomalies and best practices Work together with engineering teams to identify rate reductions and possible cost avoidance Cost allocation | Unsatisfied engineers as their workload keeps rising Long delivery cycles Cannot predict the impact on the budget Difficult to identify service or application ownership Cannot predict the costs closely enough for developing new features and products | Revenue by infrastructure costs Cost per deployed service and service utilization rates Showback and chargeback of IT costs to the business | Increased visibility to cloud cost Connection to cloud cost and unit economics More accountability for utilization Incentive toward solid architecture principles to factor efficiency |
Roadmap for Getting Adoption of FinOps
We’ve provided this starter guide to help you build a presentation to inform other teams, teammates, and stakeholders about the benefits of building a FinOps practice. It includes preparation steps, accountability and expectations per role and persona, a detailed roadmap, and more.
The stages below are based on the open source sprint outputs of the Adopting FinOps working group at the FinOps Foundation, which included core contributions from Mike Eisenstein (Accenture), Idaliz Baez (RealOps.io), Natalie Daley (HSBC), Rejane Leite (Flexera), Mike Bradbury (JunoCX), Tracy Roesler (dbt Labs), Bailey Caldwell (McKinsey), Rich Gibbons (ITAM Review), Erik Peterson (CloudZero), Nick Grab (Ellix GmbH), Anthony Johnson (Box), Kim Wier (Target), Melvin Brown II (US government), and Mandy van Os (TechNative).
Stage 1: Planning for FinOps in an Organization
As stated at the beginning of the chapter, FinOps is an infinite game. You’re never really done. It’s crucial that you get started as soon as possible and start taking baby steps toward maturing the capabilities most important to your business. The goal of this stage is to have a suitable plan for FinOps transformation in your organization that has been adapted to the resourcing you have available and the goals that you’ve outlined as being most important.
Do your research
Seek out the right stakeholders within the organization. As an individual looking to bring FinOps to your organization, you will need senior-level sponsorship as well as cultivated supporters to build momentum. Here are some steps you can take:
Research your possible advocate/champion/executive sponsor, and have one-on-one conversations with them using a customized FinOps introduction deck or targeted interview questions to determine adoption strategy.
Research pain points being experienced by the organization during your conversations, such as cloud costs breaking business cases, general perception of cost overruns, lack of cost visibility by cloud consumers, etc.
Research impacted groups, teams, and individuals during your conversations. Who is affected by the pain points?
Create a plan
Paint a picture of the future state. This should appeal to the business (business acceleration due to valuation of cloud technology, unit economics improvements, etc.). Here are some steps you can take:
Identify tool requirements. Determine if existing owned tools can fill the needs of the plan.
Identify an organizational home for the FinOps function. This may be in a CCoE, in finance, or in IT. Depending on the complexity of the organization structure, creating a dedicated FinOps team might take a phased approach. Some organizations might (1) set up a cross-functional transformation program office and create workstreams/working groups, (2) create a FinOps function as part of the extended Cloud Business Office/CCoE, and (3) evolve into a dedicated cloud FinOps team.
Identify candidate early-adopter teams who can be evangelists.
Identify KPIs to measure the FinOps function and identify ways to measure engagement and performance of stakeholders like business units and application teams. These KPIs are preliminary and will evolve during Stage 2, but it’s important to have a starting set.
Prepare a communication plan that will be used in Stage 2.
Gather support
Bring cultivated supporters together and explain why it is important to adopt FinOps:
Highlight current state, pain points, and other issues.
Identify threats and provide scenarios that could happen if action is not taken.
Demonstrate what maturing FinOps would look like for the organization.
Examine opportunities that should be, or could be, exploited.
Present a roadmap for implementing the plan.
Get feedback from the executive sponsor and adjust as needed.
Include initial team size, budget, and timeline for initialization.
Include the value proposition (e.g., ROI such as the cost of having a FinOps function versus an ongoing reasonable cloud overspend).
Present to other stakeholders, supporters, and a pilot set of people unfamiliar with the project such as business unit leads.
Perform initial resourcing
Successful FinOps requires carving out dedicated resourcing with relevant skill sets:
Request support from the sponsor to recruit other executive leaders as sponsors.
Form a change coalition made up of true organizational influencers and stakeholders.
Get budget approval for headcount.
Choose native, third-party, or homegrown tooling depending on need.
Stage 2: Socializing FinOps for Adoption in an Organization
FinOps is a cultural change that requires buy-in from many different teams and personas across the organization. As such, communication and feedback loops designed to encourage adoption of the practice are key. The goal of this stage is to socialize the FinOps plan created in Stage 1 to all the relevant stakeholders. The FinOps pitch deck below helps communicate this in a clear, easy to read, and quick manner.
Communicate value
How key stakeholders promote FinOps in the organization:
Communicate the values that are central to the change.
Share a short summary of what you see the future organization looking like.
Share high-level roadmap.
The What Is FinOps pitch deck available on the FinOps Foundation website is a good starting point for this pitch, but it must be customized for your organization to touch on your plan.
Gather team feedback
Create FinOps conversations with identified impacted teams, such as finance lead(s), product lead(s), and lead engineer(s), to:
Provide an understanding of what FinOps is.
Understand their issues and explain/educate on how FinOps could help them.
Discuss proposed KPIs and adjust per conversation feedback.
Establish interaction model between FinOps and key partners (IT domains; controllers; app teams).
Identify future members during socialization for CCoE and executive steering committee.
Define initial FinOps model
Your model should include resources, an operating model, patterns for cross-functional interaction, and related KPIs to report on progress:
Customize the FinOps model (inform, optimize, and operate) to the organization.
Identify the FinOps team with internal transfers where there is overlap with existing roles or individuals; fill remaining gaps via recruiting/contracting.
Map the change network for FinOps across the organization—sponsors, influencers, adopters. Create a clear training and communications strategy that ensures full coverage of all impacted resources.
Create a hub-and-spoke model to scale FinOps within very large organizations, detailed later in this chapter.
KPI roadmap: Finalize the first set of KPIs and reports, and identify and plan for next-gen KPIs and reports.
Stage 3: Preparing the Organization for FinOps
Once you’ve socialized and gathered support for the cultural changes, now comes the work of assessing and engaging the various parts of the business. The goal of this stage is to begin starting the FinOps flywheel in your organization so you can begin maturing across the various capabilities and domains of the FinOps framework.
Assess FinOps readiness
Performing an assessment of the organization’s maturity in key capabilities often includes the following:
Define tags, metadata, and organizational taxonomy.
Deploy, configure, and smoke-test tool(s).
Finalize the first wave of KPIs. KPIs/business adoption metrics can evolve over “adoption periods” to create a mentality of gradual FinOps maturity and not push full maturity in one go. This will allow for less mature teams and executives to not be “scared off” and do it step-by-step.
Define usage and spend thresholds for alerts and report limits.
Define and prepare persona-based self-service dashboards. These should show important metrics like the first wave of KPIs, cost allocation, budget anomalies, optimization recommendations, and other views of interest to stakeholders.
Prepare forecasting model with unit cost calculations included. At this point, this is likely just a spreadsheet.
Engage stakeholders
You’re now ready to begin ongoing cadences and processes to implement your model:
Determine business unit appetite for commitment levels (total cost for enterprise discount negotiations, RI/SP/CUD/etc.).
Engage early adopter team to get optimization wins (e.g., shutting down test environments or instances that are no longer in use to show material savings). These are important for socializing, rolling out, and winning additional adoption later.
Get some additional early governance wins for getting FinOps implemented (e.g., tagging policy, lease-to-live automation, etc.).
Start cadence of regular meetings. The FinOps/CCoE team should be talking on a regular basis with the business units, app teams, practitioners, and stakeholders to implement best practices and track KPIs.
Remember that if the organization has multiple business units operating from a federated cloud operating model, they will have differing levels of maturity. It is important that the change management considers this and allows them to adopt at differing paces.
Congratulations, you’ve begun to practice FinOps!
Type of Alignment to the Organization
We typically see three types of FinOps practice teams: centralized, decentralized, and hub and spoke.
With a centralized FinOps team, they are aligned directly to CIO, CFO, or CTO and act as a service to the businesses. They might be part of a CCoE, or they might not, if the organization doesn’t have one. Business units with cloud spend interact with this dedicated FinOps team to collaborate on FinOps activities, and the dedicated FinOps team centralizes capabilities—such as managing commitment-based discounts—which most benefit from centralization.
- Pros
- Authority, expertise, economies of scale
- Cons
- Many stakeholders, enablement and education key, persuasion requires executive buy-in
With decentralized FinOps teams, they align to a specific business unit and serve that business unit’s best interest. Each of the business units (BUs) with significant cloud spend would have a dedicated FinOps person within their group, but without an overarching central team driving best practices and repeatable patterns across the organization.
- Pros
- Very agile, embedded with engineering teams
- Cons
- Not maximizing rates, duplication of effort, susceptible to loss of key talent
We typically see decentralized teams when there is organizational recognition that FinOps needs to be happening but there is not a central executive buy-in to set up a formal centralized practice. For most organizations, it will be a transitory state at the beginning of the practice.
Hub-and-spoke teams allow for a combination of both centralized and decentralized.
- Pros
- Key BUs have dedicated embedded FinOps resources in the spokes, central hub FinOps focuses on maximizing rates and enabling more spokes
- Cons
- Teams require more investment, training, and hiring of the right people at the spoke level
Fidelity Investments has a long-standing and well-defined hub-and-spoke model for FinOps that they discussed at the 2022 FinOps X conference. A central team manages commitments and rolls up capabilities like forecasts from the various teams, but each major business unit also has dedicated and embedded FinOps experts funded by their respective business units.
Full Time, Part Time, Borrowed Time: A Note on Resources
Resources for your FinOps team ultimately should end up as fully dedicated to FinOps; however, they often start as a dotted line with a percentage allocation of time. A combination of the two models is also common: you have a dedicated FinOps lead who has a dotted reporting line to finance or engineering partners.
In the beginning, don’t be afraid to consider external contractors or consultants to kick-start, accelerate, or even run parts of your central practice. It’s very hard to hire good talent who knows FinOps well; sometimes the consultants available to you are the best option. The FinOps Foundation has a list of FinOps Certified Service Providers.
Often, a nondedicated virtual FinOps team can get the company started on FinOps. Use one to start to build some capability such as the basics of understanding your cloud spend and identifying the biggest cost drivers. As you get good at that, your success becomes your pitch for funding dedicated resources. Start small, look for wins, promote them widely.
As Mike found out at Atlassian, they knew there was value in optimizing spend, and that there was a need to understand costs, but it wasn’t until he was able to show just how large the impact could be that he got buy-in for scaling a dedicated team. This came on the back of hard data based on real-world examples, not projections. The beauty of FinOps headcount is that it usually pays for itself. It’s rare that you can say to your executive, “Give me five resources, and I’ll give you the money back.”
But what happens if your pitch gets knocked back and you don’t get funding for the team? It’s time to look at why the business is making that choice. It could be what we call deep pockets syndrome, where the priority is to migrate at all costs, and the executives want the teams to worry about getting it done above all else. In that case, you may need to start practicing informed ignoring until the business is ready and begin giving visibility to the various stakeholders. Don’t try to force engineers to do cost optimization. Start building your muscles around cost allocation, begin exploring the data with cloud native tools, and figure out what basic first capabilities you can start without the dedicated team.
Some early wins may be to begin exploring commitment-based discounts, as discussed in Chapter 16, to achieve some quick cost optimization gains. These discount vehicles can largely be made in a manner transparent to engineering teams, keeping them focused on higher-priority efforts.
A Complex System Designed from Scratch Never Works
Before building your pitch, consider the following quote:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a simple working system.
John Gall, Systemantics: How Systems Work and Especially How They Fail (Quadrangle, 1977)
If you make your plan overly complex then it is unlikely to succeed. Your adopting FinOps plan should simply outline the steps the business will take to start—or expand—FinOps and the benefits of getting the practice going.
Keep it simple. Don’t boil the ocean. Pick the most critical parts and start there. Define who the key stakeholders will be, determine what skill sets you already have and what gaps exist that need to be filled, define achievable objectives, and begin to lay out a cost allocation strategy.
You also must paint the picture that effecting real cultural change in the organization is a long process that can take years. FinOps needs to grow in stages and mature over time as the adjoining teams and processes recognize the changes required to effectively manage the value of cloud.
Like the human immune system, a FinOps practice is not born fully formed. To be ready to respond to challenges, it must start as a basic system that learns through experience the patterns, habits, and appropriate responses it needs to adapt to an ever-changing landscape.
Conclusion
Getting organizational adoption of FinOps takes careful planning, an understanding of executive motivation, and a lot of research into how the organization functions.
To summarize:
The pitch for the advanced practice should include an assessment of the current practice and a plan for FinOps within your organization that includes the additional investments that will accelerate specific capabilities and their resulting outcomes.
Don’t try to overshoot with your initial plan for the FinOps practice. Start small, gain wins, and iterate over time.
Different executives will look for different outcomes from the FinOps practice; be sure to understand their differing motivations before pitching each.
Your pitch for starting a FinOps practice should focus on the low-hanging fruit that can be achieved with careful investment.
Remember to overcommunicate and socialize your efforts at all stages to bring along the various stakeholders.
Remember, building a FinOps practice is about building consensus. You’ve got to win hearts and minds, and change long-standing processes. In the next chapter, we’ll get into the FinOps Framework, which will give you a menu of capabilities to choose as you take your practice to the next level, from wherever you may be starting.