Winning Trust with Technical Leaders as Change Agents

I had just started in a role when we began building what became one of the first FinOps professional services practices in the world. We called our new consulting practice the “Cloud Financial Office”, but the discipline later became known as FinOps. During a client meeting, our team was about to make optimization recommendations to senior IT and finance leadership at a prestigious financial firm. We presented our software platform’s “rightsizing” report, which listed compute instances that appeared to be either over-provisioned or entirely idle the majority of the time. The report recommended that the instances either be downsized or terminated.

After our presentation, the finance lead inquired if the IT leader knew who “owned” the resources in the report and was therefore responsible for the potential waste. The IT leader reviewed the list and, to our astonishment, picked up the phone to call in one of his technical leaders. Although our practice was fairly new, we had an uneasy feeling that the meeting was about to take a bad turn. When the practice lead arrived, the CTO demanded to know why there was so much waste in the department and what they were doing to address it. The technical lead was blindsided. He had no background on who we were and no context that a cost savings initiative was underway. He reviewed the list while two senior leaders from his employer watched, then proceeded to take every opportunity to discredit the rightsizing recommendations provided by our platform. It then became very unclear whether the technical lead or our software was more credible.

What a disaster, we all thought silently. We left the meeting battered but we knew we had just learned a valuable lesson -- we had learned exactly how not to approach technical owners when trying to find opportunities to cut a client’s costs and reduce waste.

This was a mistake we did not repeat. From then on, we adopted an entirely different approach to approaching our clients’ technical owners by becoming much more mindful of how we and our client FinOps practitioners are perceived. The change has allowed us to enjoy much greater success in building trust with technical leaders and influencing them to take action to cut costs. Here are the changes we made after that first, painful experience:

1. Build awareness of the FinOps team’s purpose

Before the first technical leader is even approached, it is critical that the FinOps team is introduced to the wider organization and that the team’s role is carefully described. FinOps teams should be presented as a resource that is tasked with developing and sharing best practices around reporting, efficiency, and governance of cloud costs. The impression that the FinOps team is a governing body that has been established to enforce policies or to issue directives should be avoided. This subjective positioning can dramatically improve the FinOps practitioner’s ability to communicate with technical teams and to influence positive changes in the organization.

2. Develop relationships before making requests

Once the FinOps team is introduced, practitioners should hold brief introductory meetings to develop relationships with technical owners before holding consultations with them about cost reductions. This step builds trust and understanding and provides an opportunity to reiterate that the FinOps team won’t only be asking for their time and energy to help reduce costs -- they will make these requests but will offer help with reporting and governance frameworks in return.

3. Ask questions, don’t presume to make recommendations

When the time comes to consult technical owners about cost reduction opportunities, recommendations provided by cloud cost tooling should always be interpreted and presented by FinOps practitioners “with a grain of salt.” From a technical standpoint, such reports can only derive recommendations based on a limited set of performance metrics. Many data points can only be polled at specific intervals -- for example, once every five minutes. The nature of such data points means that judgment must be applied when interpreting a recommendation that a resource should be deleted or downsized.

For example, a compute instance may be provisioned to accommodate short-period, bursting workloads that frequently occur outside the polling intervals for performance data points. The data points may therefore show chronically low instance utilization, resulting in a recommendation that it be significantly downsized. Doing so, however, could risk prohibitively large degradations in end-user performance. That is why FinOps practitioners should always ask technical owners about the viability of resizing or deleting resources as opposed to making recommendations for such changes. Instead of presenting a list of compute instances that “should be” deleted or resized and recommending that the technical owner execute the recommendations, the FinOps practitioners should ask the technical owners which of the recommendations they believe should be followed and which can be executed at an engineering cost lower than the anticipated cost savings. Asking technical owners for consultation on optimization results in a completely different interpersonal dynamic than approaching them with “recommendations,” and results in much greater success in getting optimization recommendations executed.

Beyond FinOps

FinOps is hardly the only discipline where this collaborative approach can positively influence key personnel in an organization. Learning these skills can be useful whenever a cross-functional group needs to influence other parties in an organization but has no organizational authority to compel those parties to take action. In those situations, the best approach is to combine “soft” interpersonal communication skills with opportunities to “horse trade” something in return for what is being asked of the other party. In the context of FinOps, help with reporting and governance are offered in exchange for help from engineering in taking action on cost optimization. Looking for similar “trades” in other contexts can result in a win-win for all parties.