Adopting FinOps: A guide for motivating preoccupied engineers


It takes a team effort to realize the benefits of FinOps, often requiring an organizational shift in your relationship with cloud costs. Here’s what you can do for a seamless adoption.

FinOps has taken the cloud ecosystem by storm, inspiring cross-functional teams to rethink how they view cloud spend, communicate with each other about said spend, and make business decisions.

But FinOps is more a cultural shift than it is a set of best practices or a checklist of tasks. Because while there will always be a handful of people — or a centralized FinOps team — who care about cost, the challenge is getting buy-in from the rest of your stakeholders.

In fact, “Empowering engineers to take action” and “Organizational Adoption” ranked #1 and #3, respectively, in terms of the top challenges for FinOps Practitioners, according to the FinOps Foundation.

As a result, the barrier to entry of FinOps is often too high for busy organizations because a successful adoption relies on a lot of people changing their relationship with cloud costs.


Source: State of FinOps 2023 by FinOps Foundation

But there are things you can do to slowly help stakeholders build their “FinOps muscle”, so that they become more collaborative and take ownership of their cloud usage.

Using “Alex”, a hypothetical Engineering Lead as an example, we’ll show you how you can nudge your colleagues towards FinOps adoption by highlighting what our most FinOps-mature customers do using DoiT’s product portfolio and other FinOps training activities.

Define the cloud costs stakeholders should care about

The most popular initiative for establishing a FinOps culture, according to the FinOps Foundation’s “The State of FinOps 2023” report, is creating visibility and transparency into cloud costs. And the first step — assuming your resources are already tagged/labeled — to creating visibility and transparency for stakeholders’ costs is to define the costs they should care about.

For an Engineering Lead, this may be the cost of running the product/application they’re responsible for. Our customers create Attributions to define the cost categories that different stakeholders care about. Attributions help you map cloud costs to org-specific categories like products, teams, and more by grouping cloud resources together.

As Engineering Lead, Alex has been tasked to manage their company's Business Intelligence (BI) application.. To understand costs more deeply, Alex groups cloud resources used by the BI application with an Attribution. In the example below, BI Application costs are defined as any resources tagged with a “team” label or project label value corresponding to “BI Application”."

You’d use Attributions to group cloud resources that can be attributed to the BI application. In the example below, BI Application costs are defined as any resources tagged with a “team” label or project label value corresponding to “BI Application”.


Defining "BI Application" in the DoiT Console by grouping resources with Attributions

Every company’s definitions of these categories differ. For instance, a single product may be defined by a single AWS Account / GCP Project, a single tag/label value, or a combination of this and more.

Drive visibility into cloud costs

Once Attributions are created, you can build reports to help your stakeholders drill down into the costs associated with their work.
In our example, we break down our BI Application costs by service to understand what the biggest cost drivers are.

Breaking down our BI Application costs by service in the DoiT Console

Going a step further, we can set up our report to display % changes in service costs, period-over-period to better identify any changes that materially impact our BI Application’s spend.


Highlighting the largest % changes in service costs with a heatmap in the DoiT Console

Automate cloud usage reports

In the beginning of your FinOps adoption efforts, it may be that your stakeholders won’t be motivated enough to learn a new tool, let alone build their own reports analyzing cloud costs.

If this is the case, you can build these types of reports for them, and schedule them to be delivered at a regular interval. This way, you’ll make stakeholders more aware of their cloud costs on their terms, instead of asking them to learn a new tool right away.

In our case we might want to include our Engineering Lead in this scheduled report, as well as the engineers reporting to them.

Automating cloud cost report delivery in the DoiT Console

Breaking down cloud costs by custom-defined categories

While the Engineering Lead may not care about allocating cloud costs between all applications, they may want to break down their application cost by another custom cost category, such as environments.

To do this, you can use Attribution Groups, which help you do cost allocation between a common set of Attributions. Below, you can see an Attribution Group for three different Applications, including our Engineering Lead’s BI Application. We’ve also created a similar one for Environment costs.

Grouping all our applications together to identify any unallocated costs in the DoiT Console


Once these Attribution Groups have been created, you can use them in Reports to break down one group’s cost by another group. Below we can our BI Application’s costs broken down by environment, which were also defined using Attributions.


Breaking down BI Application costs by Environment in the DoiT Console

Improve spend predictability for stakeholders with Budgets

Once you make stakeholders aware of their portion of the cloud bill, the next step is to improve their understanding of these costs, period over period.

Many DoiT customers create Budgets and automate alerts for stakeholders in the DoiT Console — but not just for financial planning.

They use Budgets as a hypothesis-testing framework for their stakeholders, with the hypothesis being “I expect to spend _______ over the next [period].” When they go over budget, that drives more internal communication between the stakeholder and the rest of their team.

For example, determining whether a budget overrun was due to under-budgeting or legitimate overspend in one or more services.
Repeatedly doing this exercise improves their (and your) understanding of cloud costs and makes costs more predictable over time.

Building cloud cost budgets in the DoiT Console

Attributions — what we used to define “BI Application” — serve as the scope for what costs your budget(s) will monitor.

Below we see a monthly budget created for our Engineering Lead responsible for the BI Application.

Here we can:

  1. Set our budget amount (and view the previous month’s BI Application costs for context)
  2. [Optional] Continuously adapt budgets
    1. Automatically base the budget amount on what the last period’s spend was
    2. Build growth into your budget
  3. Determine which people get sent the budget alerts
  4. Send budget alerts to relevant Slack channel(s)
  5. Set budget thresholds at which you’d like to alert stakeholder(s)
  6. View current spend and forecasted spend vs. budget amount
  7. View historical spending patterns for the Attribution(s) you’re building a budget with.
How to build cloud cost budgets in the DoiT Console


Once a threshold has been exceeded, our Engineering Lead will get an email (and Slack message) with the following information:

An example automated budget alert sent from the DoiT Console

They also have the option of investigating the cause of a threshold being exceeded.

What if your 50% threshold was exceeded five days into the month? Surely something unanticipated happened.

Within a Budget (or from a Budget’s Slack alert) your stakeholders can generate a pre-configured report in one click, breaking down your Attribution’s costs by service to identify the potential cause.

In our example below we can see a dramatic increase in Cloud Storage costs in the beginning of the month.

Investigating why a budget threshold was exceeded early in the DoiT Console

Set up granular cloud cost alerts for stakeholders

Budgets are useful if your alert thresholds are based on absolute numbers (ex. dollars spent) and you’re evaluating a single item (ex. BI Application).

They’re less useful if you want to evaluate each instance of the same dimension separately (i.e. each of your K8s clusters), or base your alerts on % changes over a specific interval of time (ex. weekly).

For example, what if you wanted to know when any K8s cluster had a month-over-month spend increase greater than 15%? Normally, you’d have to set a budget for each cluster. And then manually input the budget amount that represents a 15% increase from the previous week. Finally, you’d have to then constantly update each budget amount. You get the point.

For these situations where you’d want your stakeholders to be aware of usage at more granular levels, DoiT customers set up Alerts.

Example: Monitoring any resource for a week-over-week 25% increase

Let’s say we wanted our Engineering Lead to be notified when any resource — an S3 bucket, for instance — associated with the BI Application increases 25% week-over-week. This could give them an early warning of a potentially unanticipated increase in compute costs.

In the example below we accomplish this by:

  1. Scoping the alert to BI Application costs using the Attribution we created
  2. Setting the alert to monitor for a 25% percentage increase
  3. Selecting “Resource” in the “Evaluate for each” dropdown so that we monitor any resource


Setting up an alert that monitors >25% week-over-week cost increase for any VM used by our BI Application


When that’s all done, all we need to do is enter the email(s) of the stakeholders that should be alerted, whether it's just the Engineering Lead or their whole team as well.

Setting up a cost alert in the DoiT Console

Catch cost spikes before they snowball

With so many moving parts in the cloud, it can be difficult to keep an eye on everything. For the blind spots your Alerts and Budgets aren’t covering, there’s Anomaly Detection.

Anomaly Detection autonomously defines what “normal spend behavior” looks like for your organization — per account/project, per service — notifying you when anomalous spend is detected.

An example cloud cost anomaly detected in the DoiT Console

Most likely, though, individual stakeholders won’t care about anomalies in the context of your overall cloud spend, and perhaps even a specific project/account.

Luckily, you can turn on Anomaly Detection for individual Attributions as well. This means we can evaluate for anomalies in the scope of our BI Application, and our Engineering Lead will be notified when one is detected.

How to turn on anomaly detection for a custom cost category in the DoiT Console

There may be a cost increase that isn’t viewed as an anomaly when looking at total cloud spend, but when examining BI Application costs only, it is.

When your stakeholders can autonomously identify cost spikes early, they’re spending less time determining the source or scope of the issue and more time reviewing with their team how it happened and what they can do to prevent it from happening again. More importantly, this can only increase the sense of ownership they have over their costs.

Build stakeholders’ cost awareness with daily cost digests

Finally, for day-to-day updates on spend, many FinOps leaders of DoiT’s customers subscribe their stakeholders to Daily Digests for their portion of the cloud bill.

Daily Digests give you day-over-day, month-over-month, and month-to-date context over an Attribution’s spend.

In our example below, we can subscribe our Engineering Lead to Daily Digests for the BI Application so that even when there isn’t an abnormal spike or budget threshold exceeded, they will still be aware of their day-to-day costs.

An example Daily Digest report sent from the DoiT Console

FinOps Training Activities

All this said, technology can’t help your organization adopt FinOps by itself. You need to use it in combination with other educational activities and resources.

For that, DoiT customers have access to FinOps specialists that can help your organization internalize FinOps principles through individual and group activities.

One-on-One FinOps advisory

Individually, our FinOps specialists help customers adopt FinOps capabilities like understanding and allocating costs, refining forecasts, optimizing commitment-based and commercial discounts, and motivating engineers to optimize their cloud costs.

Cost visibility and allocation

If you’re having trouble deciphering your cloud bill, we can help you create tailored cost reports and that’ll drive awareness to not just you, but your stakeholders, and help everyone understand unit costs.

This includes:

  • Introducing self-serve reports and effectively delivering them to the right audience in the right channel at the right time
  • Monitoring trends on spending at a general or specific level,
  • Surfacing cost or usage anomalies to the group that owns the usage
  • Building accurate budgets for your stakeholder groups

These are all ways to push the stakeholder groups towards developing a sense of accountability over costs.

And better yet, we can help you automate these tasks so you’re only setting things up once for your stakeholders.

In fact, anomaly and budget alerting rank #1 and #2 respectively in terms of areas FinOps practitioners plan to automate in 2023, according to the FinOps Foundation’s “State of FinOps 2023” report.

Source: State of FinOps 2023 by FinOps Foundation

Rate optimization through commitment-based and commercial discounts

While many customers use automated savings products like Flexsave to cover all of their on-demand compute spend, some companies would like to purchase their own 3-year CUDs or Savings Plans and let Flexsave cover whatever’s left.

In these situations, our FinOps specialists work with your team to translate your long-term business plans into a three-year commitment that makes sense, so that you’re maximizing your savings from commitment-based discounts while minimizing underutilization risk.

Additionally, when trying to secure an EDP/cloud commitment, it can be difficult to know whether you’re getting a good deal, or if you can push for a larger discount in some SKUs based on your projected usage. You can tap into our experience from helping hundreds of customers negotiate commitments with cloud providers for the best possible deal.


As FinOps is a cultural reframing, often requiring a shift in organizational behavior, gamification initiatives can help motivate stakeholders and accelerate org-wide adoption.

How can you incorporate game-like elements into FinOps? Many set up leaderboards, but not necessarily tracking which team or person saved the most money. We found that savings leaderboards can drive undesired outcomes. For example, they can incentivize teams to prioritize the most inefficient approaches rather than the ones that could drive the most impact if optimized.

The FinOps approach of "blameless culture" is critical in this process. Some organizations may blame engineers for "not building it correctly the first-time", or receive praise for being "better" than others.

This is not healthy since it detracts from the ability to deliver the goal and reduces collaboration. As such, a useful activity is to reward whistleblowing/discovery, thus helping highlight previously overlooked areas to apply the gamification and focus. The goal is to reduce inefficiencies specific to the business and these can sometimes be highly specific.

The most successful gamification initiatives ensure that they match with the company culture, and incentivize targets that would solve the most problematic issues and drive the largest impact. You’d then reward teams for making the optimizations systematic, and the kudos/”points” awarded based on the weight placed on the initiatives they addressed.

What are some examples of activities you can gamify?

  • Tagging compliance (increasing % tagged resources)
  • Lower budget overspend
  • Reducing the time it takes to resolve cloud cost anomalies
  • Improving reservation coverage
  • Optimizing usage prior to a migration or making a commercial commitment

Gamification also implies rewards and/or recognition, and here you shouldn’t be afraid to be creative, but also consider company culture. Existing incentive products can be used (we use Bonusly at DoiT) but we’ve also seen teams use savings to pay for conference tickets or team parties.

Group FinOps Training

Our FinOps specialists deliver multi-week FinOps Bootcamps, introducing relevant concepts and tools of FinOps to groups of customers. The goal of these is to help you identify where you are in the FinOps adoption curve, build individual plans for your organization to achieve relevant goals, and set the foundation for a comprehensive FinOps strategy.

These group training sessions also give you a chance to learn from customer peers in a similar position — what they tried already, which tactics worked, challenges they faced, and more.


It takes a team effort to adopt FinOps

You can’t realize FinOps’ benefits without the communication and collaboration that a successful cultural adoption brings.

Stakeholders most likely won’t immediately adopt new tools that may give them visibility, which is why you have to meet them on their turf.

Many of DoiT’s most FinOps-mature customers use DoiT’s products to drive cost awareness and collaboration because they can deliver valuable context without forcing stakeholders to learn new tools. Eventually, stakeholders will develop more awareness about their costs and develop a sense of ownership over them.

If you’re not a DoiT customer, get in touch with us to learn more about accessing our products and FinOps specialists to drive FinOps adoption in your organization.

Subscribe to updates, news and more.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related blogs