Chapter 20. Operate: Aligning Teams to Business Goals
Without a process for action, goals are never achieved. As you move into the operate phase of FinOps, you work to support and strengthen the elements identified in the previous two phases.
In this chapter, we look more broadly at processes and how they not only enable automation but also help organizations achieve their FinOps goals.
Achieving Goals
Whereas the optimize phase sets the goals, the operate phase takes action. New goals aren’t set here—this is where you make decisions and put plans into place to address the goals that have already been set, based on the business case and context.
Let’s take the concept of turning off resources out of hours—when not needed—and apply the correct order of operations. During the inform phase you identify the resources that could benefit from being turned off. In the optimize phase you measure the potential savings and set a target for how much you’d like to save based on these metrics. In the operate phase you define the process of turning resources on and off, and you can enable automation to increase the likelihood of the resources having the new process applied. This is the phase in which you introduce scalability and replication by defining processes that can be implemented across the whole organization.
The operate phase doesn’t always lead to action. If you think about the optimize phase as where you identify the opportunity for optimization and build the mini–business case for action, the operate phase is where you reach the decision to take, or perhaps not take, an action.
Most information is irrelevant. Knowing what to ignore saves you time, reduces stress, and improves your decision making.
Shane Parrish, Farnam Street
With each iteration of the lifecycle, another goal comes into focus, with new processes and automation being built upon to reach that goal. While building processes you might uncover more goals you would like to achieve. When that happens, return to the inform and optimize phases to correctly measure and set targets for new processes. Keep each iteration of the lifecycle small and quick to correctly measure each change you make.
Staffing and Augmenting Your FinOps Team
Over time, most organizations hire experienced FinOps practitioners to staff their internal teams, as we discussed in Chapter 3. However, the number of new jobs in the space has exploded in recent years, outstripping the available talent pool of experienced individuals on the market. IDC in 2022 estimated that 60% of enterprises already have or are building FinOps teams. There can be fierce competition for talent.
Many turn initially to FinOps consultants to augment and kick-start their teams as they look to upskill internally with FinOps training and attract talent externally. All the major global consulting firms and big accounting firms now boast FinOps practices, including Accenture, Deloitte, EY, KPMG, PWC, etc., and systems integrators including HCL, SADA, SoftwareONE, Virtasant, etc.
There is, however, a big variety in the maturity and size of these practices in each, so be sure to confirm whether they are FinOps Certified Service Providers, and verify the number of FinOps Certified Professionals they staff.
Processes
On their first time through the lifecycle loop, most organizations focus on understanding their current costs. This includes building processes around what accounts they have, identifying how the bill is organized, and implementing some form of spend analytics tooling, either from the cloud service providers directly or from third-party FinOps platforms, to achieve higher-level capabilities like complete chargeback or container reporting.
After this, the most important goal for your organization should drive the processes you build. A cost-sensitive organization will focus on cost efficiency as the most important goal, while an organization focused on rapid innovation will choose to focus on enabling speed.
Many processes work together to formulate a successful FinOps practice. Automation follows process.
Tip
Before you can build automation, you need to build out processes for that automation to follow.
It’s important to define who is responsible for (or “owns”) the process, what parts of the organization must follow the process, and to what goal or goals the process contributes. A clearly defined operating model outlines expectations for staff.
When you adopt third-party automation tools—covered in Chapter 21—they often dictate how the process must work. When using these tools, you may need to adjust your defined processes to suit.
Start by figuring out how items get added to the new process (onboarding), what is expected from teams (responsibility), how teams are informed about when the process should be followed and the outcomes of following the process (visibility/alerting), and finally begin following the process (action).
Onboarding
Circumstances change, especially when you’re using the cloud. Your organization might add to its existing cloud deployments or go through a company merger. All processes should clearly define what changes with cloud growth; otherwise, you end up with a process that works for the present but not for the near future. Don’t just think about the now, think about what the future may bring, and start thinking ahead about which parts of the process will need to evolve so you’re setting yourself up for future changes and success. Getting buy-in from the teams that will be actioning the process should happen well before action needs to be taken, and setting expectations with them that there will be changes as the practice matures. Convey to teams the goal and outcomes that the new process is aiming to achieve.
Responsibility
Each process should be allocated to an owner. Effective processes clearly define who does what, and when, and how they do it. Do teams follow the process daily, weekly, monthly, or at some other frequency? Remember some processes will be followed by the FinOps practitioner (like buying commitments), while others are distributed (like rightsizing and usage optimization).
Responsibilities assigned to teams will grow as processes mature. Regularly communicating any increases in expectations will reduce the likelihood of teams claiming they were unaware of what they should have been doing and when.
Through each iteration of the FinOps lifecycle, you build on these processes. At the beginning of the cost visibility journey, for example, the only expectation of a team when they receive a cost report might be to read it. Later, teams might be asked to investigate and explain any costs over a certain threshold. Even later, teams might be required to revise budgets and forecasts when projections show goals won’t be met.
Once again, you’re gradually maturing FinOps. It’s impossible to have teams investigate costs during the first time through the FinOps lifecycle without first putting in place a well-developed cost allocation strategy and correctly forecasted budgets. Instead, you minimize time through the loop, because trying to build all the processes at once makes it impossible to track the impacts of each process.
Tip
In photography studio and theater lighting design, there’s a maxim that reminds the lighting technician to only move one light at a time—that way, they can see the impact of each change before making additional adjustments. The same holds true here: if you change processes related to your rightsizing or tagging and to your reserved instance or savings plan management at the same time, you may not be able to easily identify which change drove movement in your bill.
Visibility
Both before and after an action is taken, you must build visibility. In the operate phase, processes that enable visibility ensure that everyone is aware of the changes required and those being made. The most common operational processes for visibility send automatically generated reports or alerts to teams to make them aware of events as they happen.
Reports should be clear and easy to understand using the FinOps common language we defined in Chapter 4. Training and documentation should be made available to ensure all staff are familiar with this lexicon. Alerting and anomaly detection should occur on predictions based on current metrics, allowing staff to respond before things are off track. Instead of waiting for a target line to be breached, forecast the near term to identify when action is required early. A good example of this is AWS Budgets, which allows alert configuration based on predicted end-of-month spend.
Over time, processes and communication channels will grow in importance and sophistication. The FinOps team can bring development teams, finance teams, and business teams to the table to learn what information can help them plan and make decisions more effectively, as well as to receive information about their plans. Over time, the amount and variety of information provided will increase, and it will be critical for FinOps practitioners to continuously improve how they communicate.
Many FinOps teams start by holding monthly or quarterly meetings with the technology teams building and running applications. The first meetings can be awkward, uncomfortable, and somewhat guarded, with neither side quite understanding what the other wants. Over time, as these discussions continue, the FinOps team works with the IT teams to advocate for them, to evangelize the good steps they are taking to understand and control costs, and to provide them with a better understanding of business goals and finance requirements. Records of these meetings show deeper conversations about complex cloud decisions the team is considering, and participants begin to come to the meeting prepared to talk about ideas to save costs, rather than being dragged through their own cost data.
Combining visibility with clear responsibility and role definition breeds trust and leads to partnership in action. Working with the various teams of your organization is one of the processes the FinOps team needs to build. Be careful not to overlook the processes related to operating a FinOps team successfully when building processes such as rightsizing and commitment-based discount program planning, which are more focused on the cloud providers.
Action
The action stage is where something actually happens—processes involving activities that enable your organization to reach its FinOps goals, from generating new reports to turning actual cloud resources on and off. Action processes are often good candidates for automation. When we discussed rightsizing in Chapter 15, we highlighted that recommendations are often generated by the centralized FinOps team and then distributed to engineering teams so they can investigate and adjust their resources where appropriate. Without clear processes for how rightsizing recommendations are generated or communication about what is expected from engineers, rightsizing often does not succeed.
Central FinOps groups can be great sources of information on how to perform the various FinOps capabilities at increasing levels of sophistication. Internal knowledge sharing, process repositories, and tools can be a huge benefit, particularly to large or complex organizations. Scripts, process documents, and how-to materials can be collected for use by all, along with records and logs of actions taken or decisions made. Remember, different groups within any organization will be at different maturity levels and different stages of the FinOps lifecycle. They should have a clear place to go to find processes that work.
A direct action might not always be the decision you reach. Even if you have an excellent business case for rightsizing, it might not be feasible if critical staff members need to focus on another strategic initiative. You might postpone a commitment purchase by two weeks to accommodate a pending decision about cloud architecture, which could radically change the demand for the services being considered. Not every optimization opportunity will lead to an action or a concrete saving.
It’s just as important, though, to document these decisions and the rationale for making them, to provide a record of action and guide future decisions.
How Do Responsibilities Help Culture?
Processes that define which teams are responsible for taking actions also help build the culture around how different teams work together. Teams should understand how their contributions help the organization reach goals. When teams don’t see how their efforts contribute, they often don’t follow processes.
Carrot Versus Stick Approach
Reporting that helps highlight the positive impacts of following processes encourages teams to put in the effort to realize these benefits. It’s also important to track and report where teams haven’t been following processes and measuring those impacts. Building out the best performers and worst offenders list can help the organization to reach its goals. How these reports are distributed inside an organization will be determined by the culture of the company. Some publicly reward success and privately deal with teams that don’t apply enough effort, while others prefer a public “worst offenders” board.
While traditional IT organizations typically work with positive metrics rather than negative ones, in the world of public cloud and FinOps there’s one great distinction: teams have the power to stop waste and negative behaviors in a way that they never did when running in the data center. Punishing a team for wasting storage capacity on a storage area network (SAN) whose cost was long ago depreciated serves little purpose, but highlighting unused resources that continue to cost the company money hour after hour, despite the fact that they could be terminated with a few clicks, makes sense.
In usage optimization, a common issue is getting teams to implement changes. The ability to show the overall savings your teams can achieve and what savings other teams have generated will help convince teams to engage with the process.
The preference here is to use the carrot as a way to build collaboration with engineers and avoid creating an us versus them environment. Unfortunately, the aforementioned carrot is not always enough, and you will need to work with teams that are not following the guidance from FinOps.
Tip
Remember that some teams are expected to spend significantly more than others. A “worst offenders” list based on total spend won’t be productive. While it might be topical that team A spends more than team B, it’s more important to know if team B spends more than budgeted while team A is on target. Focusing the conversation on the things that are critical, and not wasting time on those that aren’t, plays into the language of FinOps.
Handling Inaction
It’s important for the executive team to propagate the message that meeting targets is important to the success of the whole organization. When teams understand this, they pay more attention to reporting on their overall performance. When teams want to sacrifice spend for speed, management needs to sign off. This exception should then be factored into budgets.
It’s not often that you come across a staff member who doesn’t care that the organization is overspending. So when we find that our teams aren’t following the advice of the FinOps team, it’s most often because they have other priorities. Understanding what these priorities are can avoid conflicts of opinion.
Teams might focus on the speed of execution more than the cost. Getting a project done earlier might give the business an overall market advantage. If a team is having problems with what they’ve deployed, stopping them from addressing that in order to save money might not be in the business’s interest.
If team members are reluctant to allocate time to meeting targets due to other project timelines, then either the management responsible for the roadmap planning needs to allocate time specifically to optimization, or the budget lead needs to capture the increase in spend due to time not being allocated to optimization.
In cases where there is good reason to be over target, details might be missed in the target-setting phase. Spending some more time target setting could prevent a team from appearing in the “worst offenders” list.
What do you do when a team isn’t prioritizing addressing their targets and isn’t willing to make the needed changes? That’s when a FinOps practitioner advises the business unit’s budget lead of which targets are being missed and what opportunities are available to help the team get back on track.
Putting Operate into Action
Let’s look at an example of usage optimization by removing idle resources. The FinOps team defines a process of detecting idle resources and estimating the potential savings. During the optimize phase of the FinOps lifecycle, the FinOps practitioner measures the amount of idle resources.
Assume you have $150,000 in potential cost avoidance, of which a goal of $50,000 is set. You define a process that assigns responsibilities and clearly outlines what is expected from engineering teams, how quickly they are expected to respond to the recommendations, and what teams should do to exclude their resources from the process. You generate reports for these idle resources and publish them to the teams responsible for the resources.
As teams remove idle resources, the amount of costs that could be avoided decreases from the initial $150,000. Engineering teams will see the number of recommendations assigned to them coming down as well. Both results help show the impact of the teams’ efforts.
Where teams aren’t following the process, their recommendations and potential savings will not change, or worse, they will increase. Management should reiterate the importance of following the processes to remove idle resources, putting pressure on teams that are not applying the process. The FinOps team should collaborate with teams not meeting their goals to determine how they can be assisted. This is covered in more detail in Chapter 24.
As the goal of $50,000 in costs avoided is reached, new—and hopefully more ambitious—goals can be defined.
Conclusion
To achieve goals, every organization needs processes that clearly define who is required to do what and by when.
To summarize:
Set goals in the optimize phase, and build processes in the operate phase to achieve them.
The FinOps maturity approach applies to processes. Don’t try to achieve everything all at once.
Developing processes in small increments allows you to measure progress toward your goals.
Management buy-in can help with teams not completing their required tasks.
Collaborate with FinOps practitioners outside your organization to adopt processes already proven to work at other organizations; consider joining the FinOps Foundation, using FinOps contractors, or hiring experienced practitioners.
There are many processes that lend themselves to automation: report generation and alerting are two primary candidates. In the next chapter we discuss how automation in FinOps should follow only a clearly defined process.