FinOps is About Shortening the Money-Feedback Loop

Many companies first discover FinOps because they have an urgent need to save money. FinOps is great for these quick wins — there are several low-hanging fruit practices (like purchasing Reserved Instances/Savings Plans, right-sizing services, and deleting unused resources) that can instantly reduce spend.

But those savings can quickly be replaced with new spend if the underlying habits aren’t also addressed. After the big savings push, it will be right back to past behavior that originally warranted the big savings push.

It’s no surprise that cloud costs continue to rise as a faster-than-planned when there’s a sub-optimal Money-Feedback loop. Engineering is all about cause and effect, and most loops are near instant. When an engineer makes an infrastructure change, impacts on reliability, availability, and speed present almost immediately.

But often, cost is an effect that takes significantly longer to be noticed. If your company isn’t monitoring costs until a monthly invoice arrived, then it can be up to 45 days¹ before any spend anomalies are noticed.

One important aspect of FinOps is to both shorten and improve this Money-Feedback loop.

What is the Money-Feedback Loop?

The money-feedback loop is the life cycle of spend. This cycle begins the moment an action is taken that incurs cost, and it ends once that spend is both visible and accounted for.

There are many different variations that the money-feedback loop can take — the loop can vary in terms of how long it takes to complete, and it does not always start and end with the same person.

Here are different variations of the money-feedback loop.

The Eng-Finance Loop

One common form that a money-feedback loop can take is end Eng-Finance loop. This is common in companies with no dedicated FinOps person or team, or is early on their FinOps journey.

In this loop, an engineer is the person performing a cost-incurring action, and the Finance team is the group accounting for that spend.

This is a sub-optimal loop due to two reasons: the amount of time it takes to complete the loop, and the information sharing (usually manual) required to satisfy the the loop.

It can take a long time for the loop to complete if a company is only looking at cloud spend when the monthly bill from the service provider arrives. Theoretically, an engineer could incur significant spend at the beginning of the month, and it wouldn’t even be noticed until the bill arrived in the middle of the following month.

But the money-feedback loop doesn’t end when the additional spend is noticed. It also needs to be accounted for.

If there’s a spend anomaly that Finance doesn’t expect, then work must be done to explain (and document) the change. The amount of time that this detective work takes can vary wildly depending on the root cause. Sometimes it’s a quick answer. Other times, it takes a lot of digging through charts, analyzing old data, and talking to individual engineers.

Finance is unhappy because they’re not empowered to answer questions on their own. And Engineering is unhappy because of the amount of time it takes to reconcile the bill each month. This loop needs improvement.

The Eng-Sr. Eng Loop

Another money-feedback loop variation is from an engineer (the one that incurs the spend) to senior engineer (usually manager or director, but sometimes VP or CTO). This loop is a bit better than the Eng-Finance loop, but still has some potential pitfalls.

With this loop, the engineers writing code often aren’t aware of the financial consequences of their decisions and actions. Instead, senior engineering leaders receive and review costs, but keep these details away from the engineers incurring cost. This can be by design — companies may want to shield engineers from cost to avoid unintended behavioral impact. For example, engineers choosing not to prioritize a product or feature after learning its high cost, despite the company explicitly wanting to spend that money on that feature.

Finance is still the department that’s receiving and reconciling the monthly cloud bill, but it’s now in direct partnership with Engineering leadership, making the process smoother.

This loop, however, also has its challenges, especially on the engineering side. The senior engineering leader that closes the Eng-Sr. Eng loop is responsible for both 1) monitoring spend and making decisions based on that information, and 2) answering any questions that Finance has about variations in spend.

When cloud costs are within expected bounds, this is fairly easy. But when costs are higher than expected, this level of responsibility can quickly become its own full-time job, taking time away from the many other responsibilities of a senior engineering leader.

Additionally, in this loop, Finance is fully reliant on this engineering lead to answer all questions about spend, which means the engineering lead can easily become a bottleneck to mission-critical Finance functions. Ideally, we want to Finance team to be empowered to answer as many questions as they can on their own.

The FinOps Eng-Eng Loop

Finally, let’s look at a more optimized Money-Feedback loop, enabled by FinOps best practices. First of all, this is an Eng-Eng loop, which means that the individual who incurs costs is also the person who accounts for the spend, thus closing the loop.

This happens through engineer-level cloud cost visibility and alerting. Engineers should have the ability to view the costs for their respective cloud infrastructure, and there should be automated system in place that rings an alarm if that spend goes out-of-bounds.

It can also be useful to create some structure around the review and accounting of this spend. This can take different forms, like regularly meeting to discuss previous and upcoming spend, or regularly collaborating an a cost summary report for the executive team.

Empowering the engineers that are incurring spend to also review and account for spend creates the shortest and most direct loop. If an individual makes a mistake — like spinning up 1,000 instances instead of 100 — that spike will be quickly noticed and rectified.

This also helps Finance, because any cost anomalies are already known and explained before the bill arrives. With proper structure in place, this can all be documented already in a format that Finance can consume. But even without this, any questions Finance has should be easily answered, as opposed to needing lots of hunting and cost detective work.

Adding Value by Shortening the Loop

FinOps is all about updating business practices to best take advantage of the variable-spend nature of the cloud. When a customer only pays for what it uses, the business has the potential to significantly lower its infrastructure spend.

But “potential” is the key word. Moving to the cloud does not guarantee savings. Instead, the entire business must change and adapt in order to actually realize these savings, and to prevent unfortunate “cost events” from impacting gross margin.

That’s where a robust FinOps practice can help. FinOps is about more than identifying flow-hanging savings and trying to make engineers spend less money. By optimizing and shortening the Money-Feedback loop, you’re creating a culture of cloud cost mindfulness that will benefit the company’s financials in perpetuity.