Just when most organizations start to feel confident with how their cloud operations are paving the path to capability and customer growth, warning bells start to sound from finance executives and board members…
“Cloud spending is out of control.”
“We need to better understand where our cloud costs are going.”
“You need to consider how margins will be impacted as we scale.”
While these alarms often leave Finance and Engineering in a standoff, the good news is that your company is asking questions about the relationship between cloud costs and financial return.
In other words, you are laying the groundwork for FinOps – the strategic practice of optimizing cloud operations for maximum business value at scale.
Common FinOps Mistakes and How to Avoid Them
Sounds great, right? Maximum business value? Sign me up.
However, when organizations embrace the exciting potential of FinOps, they often make early mistakes that paralyze their progress towards achieving their goals. Here are five of the most common mistakes companies face as they get started:
- Rallying around a silver cost savings bullet
One of the common early wins of a FinOps program is cost reduction realized by right-sizing and better rate management. But, too often, companies discover immediate savings and assume they will translate into long term margin improvement with little additional investment. Unfortunately, these savings are usually transient and are quickly reversed if attention moves to other priorities.Savings need to be sustainable. Changes to how your organization reviews, budgets, and plans for cloud investment on an ongoing basis will be required to maintain the financial, architectural, and scalability benefits of FinOps.
- Not giving FinOps the right home
Cloud cost governance is not just an Engineering problem. Nor is it just a Finance problem. While FinOps creates the need for a tighter working relationship between these parts of your organization, there is often ambiguity about who is in charge.Often, due to the fact that organizations are talking about the Cloud, FinOps responsibilities and expectations get thrust upon Engineering. This leads to loading FinOps work onto already overstretched team members, creates conflicting priorities for your program leaders, and sends mixed signals to others in your organization about the importance of FinOps.
While it is true that some of the FinOps functions are technical in nature, rate management, analysis, and reporting should be done by a centralized FinOps team that has a view into financial needs that are generally outside the bounds of Engineering concerns. Many technical requirements of the program will be handled by individual Engineering teams, of course, but it’s important that accountability for those requirements comes from outside the Engineering organization.
FinOps has unique goals and expectations. When these goals and expectations get lumped in with other accountabilities, they can be viewed as something outside a team’s “real job”. Having a dedicated and properly positioned FinOps team puts the burden of meeting and measuring FinOps goals in well-defined and capable hands.
- Not appointing one leader to hold teams accountable
Even when organizations give FinOps a home of its own, they make the mistake of not identifying one leader in the organization to hold others accountable. This can doom your FinOps program early because great ideas can fail to become meaningful actions without a leader driving progress.Remember, you are not just looking for a band-aid to stop your cloud cost bleeding. FinOps is a strategic shift that has both short term and long term impacts. By not allocating a dedicated leader, you are implying to your organization that it is just a task to check off and not worth significant investment.
One leader in the organization must be the person holding everyone else accountable and providing direction when there are competing priorities. Your FinOps leader will not only be responsible for making sure that work is being done, but also for overseeing the change management and facilitating new collaborations between Engineering and Finance.
This leader will also serve as the liaison between the executive team and the FinOps operational team. Without a single leader the alignment between your FinOps program and organizational objectives may fade, leading to a breakdown in the executive buy-in you need. This leader must be the advocate for budget, resources, and time that your teams need to make sure your FinOps program has an impact.
- Starting without a data-driven early action plan
You may have an idea of what problems exist, but defining these priorities without a deep dive into all available cloud data can lead to misidentifying priorities and not meeting your goals.The process of gathering data needs to start from day one to allow for “quick wins” within the first 1-4 weeks.
On the cost reduction side, spend technical effort collecting usage information and performing a surface-level waste audit of infrastructure. For example, look for unused databases (no connections), unused VM’s (near-zero CPU utilization), unused disks, etc. From this, come up with a list of immediately actionable opportunities with low technical cost/risk and strong payback.
On the architectural side, perform a real ROI analysis of proposed code or deployment changes being considered or already in the works. This should include a detailed look at the number of resource-hours or other billable features that will be reduced by the changes, with full discounting applied. It should also take into account forecasted variables like customer growth and product changes. Use this data to inform quick yes/no decisions on further investment.
Finally, on the reporting side, identify the blind spots for finance/accounting with respect to cloud spending. Do an audit of all tagged/labeled resources and how those map (or don’t yet map) to the expressed needs. Quantify the gaps that could be closed fastest and with minimal effort.
- Prioritizing perfection over progress
Often, companies delay starting a FinOps effort in earnest because they’re waiting for a perfect dataset or all the resources they need. For example, partial data in usage metrics, or a half-completed audit of waste might be all that’s available within a few days. As a result, a decision is made to wait for a full analysis before starting a right-sizing pass. Or, Finance may be blocking progress on a full tagging/labeling standard for the infrastructure because they feel they have to get their reporting dimensions “just right.”An important realization is that there will never be a moment when you’re “ready” or “done.” All data will change and become outdated. Analysis will always be stuck at 98%. The tagging standard you spend time on today will be a relic in 12 months. And, you will never have all the time and people you need to do everything.
Make progress now on the data you have and with the standards you can agree on quickly. A little progress towards a goal begets excitement and more progress. Spend effort building your FinOps engine around the idea of rapid iteration rather than completion. For example, expend more effort making it quick to deploy changes to infrastructure so that tags/labels can be updated with less friction when reporting needs change, rather than expending effort on perfecting your tags/labels in the first place.
From Making Mistakes to Generating Momentum
The push for FinOps often comes from internal or external pressures on costs and margins – new investment rounds, market uncertainty, etc. As a result, the desire to move quickly entices companies to overlook important drivers of program success. Ignoring these not only can lead to momentum stalling gaps, but also set you up to repeat the mistakes as your company scales.
In other words, quieting the voices questioning your cloud operations is not about distracting them with small savings victories, but rather providing the lasting visibility, control, oversight, and strategic direction so you have the answers regardless of what questions are asked.