Each team within your organization likely uses discipline-specific terms, views cloud billing data from a different perspective, and has separate motivators for what they would like to achieve. This chapter discusses how you can enable teams to collaborate more effectively by educating staff on specific terms being used by each and by defining a common lexicon to encourage alignment and trust.
An early stage company typically starts with simple daily spend visibility that shows teams their respective spend. However, the common lexicon is important not only for those starting out in FinOps, but even the most well-versed FinOps practices. As your maturity in the cloud increases, the amount of terminology used in your cost reporting expands. As you continue to add capability areas in your FinOps practice, increase consumption of additional cloud services, and become more granular in your reporting, you end up with even more discipline-specific terminology. This increases the potential to use ambiguous (or duplicate) terms, which can create confusion and lack of trust in the data. Consistency becomes even more important in later stages to provide a better understanding of how all the reports relate to each other and drive accountability to the respective teams. Try to avoid using esoteric discipline-specific terms from finance or engineering and aim to agree upon a standardized lexicon.
It’s easy to highlight the need for a common lexicon: simply ask a finance team and an engineering team to each describe a service. A finance team typically thinks about the costs and rates of services while engineers will be thinking more about their service availability, reliability, and available capacity. Both are correct. The disconnect comes when these teams try to communicate with each other, which cloud forces them to do much more often than was common during the data center days. In that not-so-distant past, operations teams interacted with costs only when they proposed new equipment purchases. After that, their day-to-day job was about the efficiency and performance of their services. Finance teams, alternately, focused on what spend was committed and which budgets it should be depreciated against.
When you distribute technology buying power throughout your organization, you need to ensure all teams are using the same vocabulary for describing costs—and that you don’t overload terms to mean different things to different people. The language gets more complex when you add in cloud service provider–specific terms, and it quickly approaches incoherence as you switch between multiple cloud service providers and their vendor-specific nomenclature.
If every report you generate also needs to come with a dictionary of terms—or worse, someone has to sit down and teach a team how to read a report—that prevents the interteam collaboration at the heart of FinOps. People will refuse to give reports the time it takes to understand them, while the FinOps practitioner quickly will run out of bandwidth to keep everyone informed.
To build a common language across an organization, reports must consistently use specific terms, and teams must have learned how to correctly interpret them. While one person might understand that divided costs means the same as cost allocation, that won’t be common knowledge in the beginning of FinOps.
Where possible, it’s better to use existing language constructs instead of creating all-new terms that teams must learn. And if a cloud service provider uses terminology that doesn’t align with existing business language, it’s best to translate it before reporting out to the teams.
Of course, having everyone read this book will also help build a common understanding of the terms used in FinOps. Let’s define some terms used in the industry:
Some terms that come from the finance discipline that are helpful for the engineers to understand include:
COGS measures how many dollars of outlay it takes to generate revenues in a specific period. For example, if a power company is trucking coal out of storage and into the power plant, it would record the cost of the coal burned. That cost has no future benefit, so it’s going to be an expense that is directly traceable to revenue in that period, making it a COGS expense. The test of COGS is: are they directly expensed and directly related to revenues in the same period?
Hosting costs spent on R&D may receive more favorable tax treatment than that spent on COGS, so the ability to clearly distinguish between the two is a potentially valuable capability of the FinOps effort.
Jason Rhoades, Intuit
For a software company, the COGS would be the monthly cloud bill to operate its software, salesperson commissions, and support costs. Notably, cloud is the most variable and has the most potential for optimization. Since it isn’t generally good business practice to turn down your sales commissions or fire your support people, this shines a bright spotlight on optimizing your cloud spend without reducing revenue.
Human beings tend to have trouble with very large and very small numbers. For instance, if something costs $1 per hour, calculating how many hours you would get for $10 is relatively simple. However, if a resource costs $0.0034 per hour, working out how many hours you would get for $10 will require a calculator. Number formatting is also important. Without formatting, 100000000 is hard to read. Most people would need to count the zeros and add commas to determine the amount it signifies.
Another human issue with large numbers is that we tend to lose our sense of scale. This can be a problem with teams working with large dollar amounts, like thousands, millions, tens of millions, or more. As Hans Rosling points out in his book Factfulness (Flatiron Books), the size instinct kicks in when humans deal with very large or very small numbers, and you need to identify ways to deal with this.
In a FinOps Foundation meeting, one of the members showed how using abstraction can assist FinOps. He strengthened his point by noting that the difference between one billion and two billion doesn’t sound like much, but it’s actually a huge change.
Many organizations with large cloud spend struggle to give their engineers meaningful metrics about spending. Imagine an organization is going to spend $100 million a year on cloud. At that scale, all humans will struggle to understand the scale of the numbers involved. And when you have trouble with scale, it becomes difficult to answer questions like these:
Is a $30,000 a month optimization a little or a lot?
How much effort is worth putting in to achieve the savings?
Does it really matter to the business?
Are there more important priorities?
Keeping a culture of accountability, so vital to a successful FinOps practice, becomes more and more difficult when the numbers get too large to relate to.
To help with context and understanding, it’s sometimes helpful to not use the common lexicon, because the specific number of dollars spent or saved may not be the key takeaway. If the impact to the business for spending or savings can be articulated using other units of measurement, the message comes across much more clearly.
For example, a FinOps Foundation member correlated the amount of cost savings to beer. If the team took a certain set of actions, he showed that they could save the equivalent of a thousand beers. In the years since the first edition of this book, that same beer metric practitioner has been able to evolve his reporting to include tangible business metrics such as requests served, revenue delivered, and customers served to their offering.
This move away from reporting only in dollars is important, because each team involved with cloud spend has a different set of motivators. Using the motivations of teams to find an appropriate example is one way to put cloud spend in a more meaningful context. For example, an up-and-coming motivator of engineering teams is the introduction of sustainability metrics like carbon emissions. See Chapter 19 for more on sustainability and FinOps.
For business leaders, seeing cloud costs tied to an important business value metric, such as a percentage of the supported product’s revenue or the output of some key activity, gives a more understandable picture of the overall efficiency of your cloud spend. An organization can then set target limits for the spend percentage and use this to drive projects to optimize using a number of techniques to reduce growth of cloud spend relative to revenue growth. Part III discusses optimization methods.
But that overall business strategy doesn’t directly relate to teams’ motivations. Engineering teams, for example, turn their efforts into functionality for users, so their motivations revolve around growing their engineering team and delivering more functionality. A FinOps Foundation member found that by reporting cloud spend in terms of the monthly cost of the engineering team, he had landed on a meaningful way to engage the engineers. When evaluating a cost-saving action, they were able to say that an optimization action might result in a specific amount of additional headcount, or they could say how quickly a cost-saving action might pay for a team’s salary.
Knowing the teams’ motivations helps you find an effective way to engage them. For service managers, reporting in alternative units like cost per daily active users (DAUs) is a good tactic. By dividing the cloud spend by the number of DAUs of their services, they can show the amount of business value those services are generating per dollar spent.
As a FinOps practice continues to mature and you start adopting unit metrics, you can associate a true cost to a business function and start to steer cost conversations to value conversations. For a transport company, your unit metric might be packages delivered, or you might start with a simpler metric like cost per request or API call. When you can equate a cloud cost to each business delivery, you can report on cost optimizations in terms of how many more shipments you can make from the savings you generate. All of this contextualizing helps create a common understanding among teams.
As you create reports that move away from the people operating the cloud resources, or from the FinOps team that’s operating the cost-saving programs, it makes sense to abstract away the cloud-specific terms. When you switch those terms for more generic business terms, you can summarize reports while still being accurate.
As an example, let’s look at cloud reservations for compute resources. These will be covered in more detail in Chapter 17, but generally the idea is that if you make a commitment to a cloud service provider and use those commitments effectively, you can save money. If you don’t, you lose money. AWS calls them Savings Plans or Reserved Instances, with various options saving different amounts.
If your FinOps team creates a report for themselves, they need the details on the individual commitments made. But as you start reporting up to finance and then to the business at large, the important message changes. What you focus on here is the overall success: did you save money or lose money? When you move from reporting with cloud-specific terms like commitment utilization into more generic business terms like savings realized, you create clarity.
Reducing the number of individuals that need deep cloud knowledge, especially as you move farther away from the technology toward more general business reporting and monitoring, reduces the knowledge barrier. And focusing your reports on the actual business outcome being reported continues to foster more trust, credibility, and understanding.
We previously referred to this using the concept of a Babel fish from the Douglas Adams masterpiece The Hitchhiker’s Guide to the Galaxy (Harmony Books). However, it was a reference that not everyone understood. Instead we are going to use a Star Trek reference to a similar idea called a Universal Translator. In Star Trek, the Universal Translator is used to interpret alien languages into the user’s native language. It’s exactly the kind of thing every FinOps team wishes they could give to finance, technical, and product teams so they could all perfectly understand one another.
For example, we’ve been in meetings where the technical team talked about the specific values they use to tag cloud resources while the finance team talked more broadly about the need for cost allocation. Both teams were describing the same thing, but there was nuance to the reporting they were reviewing, such as details of how a tag value was used to allocate costs, that prevented these two teams from understanding each other.
They could have used a translator to cut through the confusion.
But if both the finance and technical teams are clear on how FinOps practices such as cost allocation work within the organization, the conversation always starts from a common level of understanding—no universal translator needed.
Finance and engineering teams are very smart. However, you must remember that they have different practices and different terminology. FinOps should help finance teams to understand the cloud language by abstracting the cloud-specific terminology away for those who understand the dollars and cents, and they should simplify the finance requirements for the engineering teams.
FinOps practitioners build reporting and processes that reduce the need for both finance and engineering teams to spend large amounts of time learning and working outside their areas of expertise. Building those reports with consistent language enables teams to familiarize themselves with a common set of terms and then use those common reports to have conversations around the cloud benefits and costs.
You need FinOps to enable teams to communicate efficiently. Ideally, someone from the FinOps team isn’t required in the room at all. That person’s presence becomes less necessary when everyone shares a vocabulary. However, the FinOps team is always there to assist in building these reports, so that trust, understanding, and clarity will continue to grow.
FinOps teams can then help collect and define the terms used by an organization that will be used to describe cloud spend and savings. Discipline-specific terms, industry terms, and variations used by different cloud service providers must be adopted, and/or adapted, into a common lexicon.
No one in finance, technology, product, procurement, or management should be expected to try to learn all the common languages of every other team. Ideally, everyone meets in the middle, where finance learns the necessary terms used to describe cloud resources, engineering learns the terms used to describe costs, and product teams learn to communicate with both. When teams learn more of the language used by other teams, the conversations lead more quickly to successful outcomes.
When common reporting built around the same language is used to measure each team’s spend and optimization, it becomes possible to compare the teams—and even create some friendly rivalry. Chapter 22 digs deeper into the metrics used to compare groups, but for now think of how being able to compare teams can lead into gamification.
For example, virtual achievement badges can be awarded for successful management of team cloud spend. Celebrating teams that perform the most optimizations, and highlighting the specific positive effect on the overall cloud spend and optimization, is a great way to engage and encourage teams.
Alternatively, having reporting that highlights the worst offenders—those who have shown a lack of optimization actions, ignored their team’s cloud spend, or were slow to respond to unexpected spend anomalies—can be effective and even fun, if done well. From our experience, teams don’t like to be listed as the worst offenders and will often put in extra effort to change their position on the list. We will look more at what we call “shameback/worst offender lists” in Chapter 11, when we get to practices that will help you reach your FinOps goals.
Ultimately, you use your common lexicon to build a shared understanding of your cloud costs and optimization opportunities.
To summarize:
Be aware that different teams use discipline-specific terms.
Help staff learn common vocabulary and stay consistent with the terms used in reporting, which will help eliminate confusion.
A FinOps team doesn’t have to be a constant translator in meetings but should assist in learning and enabling teams to communicate more and more on their own.
Consider adding reporting using abstracted units of measurements to communicate in ways that are more meaningful to your teams.
Dividing out costs and savings against some unit of business value allows you to gauge how efficient your cloud spend is.
Before you can optimize your cloud spend, you need to understand your cloud costs. We’ll take a look at the anatomy of a cloud bill in the next chapter.