Most FinOps practitioners don’t work in isolation. They work with internal partners such as finance, product owners, and engineering teams. Building healthy relationships with these partners is critical to a FinOps practitioner’s ability to successfully advance organizational goals.
Without trust, we don’t truly collaborate; we merely coordinate or, at best, cooperate. It is trust that transforms a group of people into a team.
— Stephen Covey
In order to build and maintain healthy relationships, a FinOps practitioner must begin with a foundation of trust. This document will address why trust is important, the building blocks of trust, and how FinOps practitioners can introduce trust in their practices today.
Trust can mean a lot of different things in different settings. For this paper, we’re using the International Association of Business Communicators definition of trust:
“[Trust is] the organization’s willingness, based upon its culture and communication behaviors in relationships and transactions, to be open and honest, based on the belief that another individual, group, or organization is also competent, open and honest, concerned, reliable, and identified with common goals, norms, and values.”
Most business leaders today recognize trust is important, but many don’t realize just how critical it is to success. Harvard Business Review shows that when trust is healthy, relationships between teams promote high levels of engagement, better communication, and higher productivity.
When it’s not healthy, teams lose cohesion, have poor communication, and conflicts exist that lower productivity, efficiency, and success.
Within the scope of FinOps, building and maintaining healthy working relationships through trust underpins all capabilities. Successful execution of FinOps capabilities requires involvement from multiple teams. Those who treat trust as a currency, who value trust as an asset, and embed trust as a core operating principle will succeed as a team and business.
A FinOps practitioner can build trust by practicing behaviors that build trust. While there are many behaviors one can practice to build trust, we’ve outlined five behaviors which we determined to be most critical. As the practitioner practices more of these behaviors, they are able to more easily build successful relationships across business units.
The foundation of all trust comes from communication in all of its forms. In our digital age, written and verbal methods of communication are the dominant drivers. For a newly established FinOps practice, or for the individual striving to bring a FinOps mindset to an organization, it begins with communicating the importance of FinOps to key stakeholders and personas who might be impacted by FinOps work.
Providing context for why employees or teams are being asked to perform work outside their existing pipeline, like optimizing resources or reviewing team budgets, will increase the likelihood they follow through on the work. Other means of improving context and providing helpful information include:
While direct communication is preferred, setting the standards for clarity and timeliness of asynchronous communications can allow trust to be built across time zones.
Don’t make teams guess what you are thinking. Tell them.
Unfortunately, teams tend to believe that no news is bad news. FinOps practitioners should keep stakeholders updated on different workstreams and how they evolve over time. This can include updates on products or services that are still WIP and are still evolving. This transparency and visibility around progress keeps everybody in the loop on how the organizational FinOps program is maturing and helps with building cross functional trust.
For example, one FinOps practitioner worked with an Engineering department that had an overambitious FinOps goal, cut costs 20% within 6 months. The team had already cleared out the quick wins and were left with tasks that would require high engineering effort and take time that might otherwise be spent on product updates. Using concrete examples of the team’s recent accomplishments, along with current usage data to highlight what opportunities were easily available to them, the practitioner reset the department’s expectations of what was feasible given competing needs, without undermining the team’s goals.
A proven track record of success is one of the best indicators of credibility to other team members. Leaders can encourage team members to share their wins through email, during meetings, newsletters or social media pages when appropriate.
For example, one team created a punchy, well-designed weekly roundup of the extended team’s wins. Rather than just list the success stories, they put them in the context of external market developments, connecting them to the business with engaging lines like, “What you need to know” and “Why it matters.”
A big part of FinOps is exposing what is wasteful spend, but an equally important part is sharing progress and savings made.
One organization uses quarterly business unit calls to highlight team led optimization efforts. On a quarterly basis, three optimization use cases were shared in a department wide meeting where each use case was highlighted by the leading team with a short description of the work that was done by the team members that led the optimization. Those highlights allowed the rest of the business unit to learn about the different actions they took to achieve savings, but also helped with celebrating success by other team members.
Building trust is not an event. It is a process involving consistent and predictable interaction over time. People tend to trust those who behave in a consistent manner, even if they do not like the actions. It provides a measure of comfort to know that we can count on someone to act in predictable ways. As is commonly said, “The devil you know is better than the devil you don’t know.”
For example, deliver FinOps reports on a regular cadence. This reinforces downstream behaviors in teams who rely on those reports for activities like sprint planning. Also ensure FinOps KPIs are clearly defined and reported consistently.
Easy access to KPI data via solutions like self-service dashboards allow teams to review KPIs and usage data on their own terms. And ensure spend data is accurate, and any data massaging is clearly documented and explained. If the data is not accurate, teams won’t act on the insights it provides.
Honesty is the most important element of human trust. People respond to sincerity, self-disclosure, and openness. We already touched on accentuating positives above, but it’s important to share both good and bad news openly, and provide context for your vision and actions.
If a FinOps practitioner finds an architecture change that would save hundreds of thousands of dollars per month, but doing so requires a high amount of engineering effort, they should openly share those tradeoffs with the team. This allows the team to make an informed, data-driven decision about what is more important for them at that moment: saving money at the cost of product development or furthering product development at the cost of a high cloud bill.
Avoid withholding information that may weaken your position because it may help others make an informed decision. Include your team members in these conversations and ask for their input.
At its core, FinOps is a data-driven discipline. FinOps cost overviews and visualizations should be holistic in nature, transparently providing cost metrics and cost data on an organizational level.
For example, a large insurance company has adopted full cost transparency for its IT spend. Using TBM, the organization has created reporting dashboards for the entire IT spend with organizational wide transparency from executive to manager level employees. The dashboard included interactive features and metrics to support drill down capabilities into direct drivers of variances and anomalies. This transparency helped the organization create a culture of accountability and shared responsibility for lowering and optimizing IT spend.
Fostering a learning environment allows teams to safely share missteps and lessons learned. Engineering teams may accidentally deploy resources that prompt anomalous spend but FinOps practitioners can leverage this opportunity to educate engineers on the importance of considering costs while deploying cloud services.
Financial teams may report inaccurate spend data in their reports or dashboards due to a showback error but FinOps practitioners can leverage this opportunity to improve financial controls. This type of honest transparency creates trust by building on mistakes and human errors that are all part of an evolving FinOps program.
Similarly, share things you need help understanding or executing. It’s impossible for FinOps practitioners to be proficient with all of the diverse technical resources we encounter in our work.
It’s perfectly acceptable for FinOps practitioners to rely on development teams as the subject matter experts for their application architecture, since they built it and know it better than anyone else in the organization. Some organizations have a message board where the FinOps team would post questions for other teams to help answer or explain (for example, a Slack or Teams channel would also do just fine). Often, the best way to build trust in a relationship is by asking for help.
One of the golden rules for building a trusting relationship is: Do what you say and say what you will do. Note that this is different from being consistent because it requires practitioners hold themselves accountable for their words and actions. Keep your promises and help people see the bigger picture.
When leaders don’t make their actions visible, it creates the perception that they don’t follow through. This perception only increases when you factor in the physical distance between coworkers.
Many organizations include performance assessments where employees assess the performance of their leaders across specific areas. This could be used as a safe space for employees to provide transparent feedback on how leadership can increase trust.
Great things in business are never done by one person. They’re done by a team of people.
The above behaviors are critical for FinOps practitioners to create trust with key stakeholders in their organization, but can be overwhelming if attempted all at once. The following guidelines describe how FinOps practitioners can successfully introduce trust-building behaviors into their existing practices today.
Trust within teams or partner teams needs to be established as early as possible. It’s during those first interactions, first stages, and first promises that trust is created. After that, it evolves slowly through consistent and accurate communication and performance to become a lasting foundation of trust.
For example, one company faced issues with account proliferation (independent teams opening accounts) with no insight on total spend. Their FinOps team devised a strategy for the payer account and setup payment method (non CC) and the CSP was instructed to notify the organization if any independent account activity was detected. This quick win provided visibility to the finance teams and they were able to determine the monthly cloud spend. It helped the security teams start looking into account posture and what guardrails need to be implemented. This example is a strong case for a centralized FinOps team and first push for Cloud COE.
The best way to create an environment of trust is to trust others. FinOps practitioners are leaders within their organizations and as leaders they need to set the example for others.
The old saying “treat people the way you want to be treated” is also true for team relationships. For example, treat teams as the subject matter experts of their domains. An engineering team that owns a particular workload knows the business decisions that led to its current architecture, and what architectural changes are feasible to cut costs.
Waiting to trust an employee is never as effective as assuming they are trustworthy from the start. As team members come to feel that you trust them, they will find it easier to trust you. This means letting teams own their FinOps decisions and apply their own judgment to improve processes. If mistakes are made, work with one another to learn and develop skills and knowledge for the teams and individuals involved.
FinOps as a whole is based on cross functional collaboration. It is critical that opportunities to build trust across function areas are also pursued. This means trusting key stakeholders with data and ownership. This might include sharing data and access in order to break silos and operate as a single team.
When a SaaS startup underwent a cost cutting measure, teams were at odds about the work. Product was worried rightsizing instances would impact product stability, Finance wanted to decrease COGS, and engineering just wanted to keep sprint velocity high. As leaders in the organization, FinOps practitioners worked with each team to understand their needs, which built trust between the practitioners and each team. The practitioners then leveraged these trust relationships to align teams’ goals and create a unified outcome.
This list may be overwhelming, so start small with one or two behaviors. And remember: these behaviors take time to become habits. Trust comes from what you do and say over a period of time. The more a FinOps practitioner normalizes these behaviors, the more likely the behaviors will become standard operating procedure with other stakeholders.
Given how most FinOps initiatives require repeated communication, data collection, analysis, and interactions with a whole wide gamut of people, there are ample opportunities to build trust.
Lasting trust takes a long time to develop and can be lost in a moment. For FinOps practitioners, trust might be broken when we make an optimization recommendation that’s not reasonable, or build cost policies that make developers’ work more difficult.
When you make a mistake, admit it and move on. Don’t cover it up and ignore the consequences. Creating a psychologically safe environment increases open, honest conversation, decreases chance for human error, and lowers any resistance as results of organizational politics.
A team is not a group of people who work together. It is a group of people who trust each other.
Trust is the foundation of building and maintaining healthy relationships – critical to FinOps practitioners’ success in driving the adoption of FinOps in an organization.
To a FinOps practitioner, trust means exemplifying behaviors that build trust, like communicating clearly and effectively, highlighting FinOps wins across the company, acting consistently, sharing data and business context openly and honestly, and keeping commitments. Relationships built on these behaviors increase organizational alignment and promote higher engagement and productivity.
But no one is perfect and there are times when trust is broken. Rebuilding trust is more difficult than maintaining trust, so start with transparent and open communication and recommit to building the relationship by collaborating on meaningful projects.
Knowing that this is a journey, just like building a FinOps culture can be, we hope this guide equips our community to not only build a better way to collaboratively manage cloud costs and business value, but also together build amazing relationships and trust at the same time.
While it’s great to document ways to build trust as a Working Group, we want to hear real stories and feedback from our amazing community. What are ways you’ve built trust within and outside of your FinOps teams? What kinds of barriers or challenges have we not covered in our guide?
We’re always looking to improve this documentation and guidance. Please get in touch with us in our Slack chat channel, #chat-social-aspects. Please also get in touch if you’d like to support this Working Group and help out with a future sprint!
Working Group Chat Channel: #chat-social-aspects
The FinOps Foundation would like to thank its generous Working Group members for all the contributions and time put into crafting this guide:
Thank you to our supporters as well, including Benjamin van der Maas, Phillip Purcell, Bhavna Halai, Jeremy Nancel, Dean Tabor, and many more.
Lastly, a big thank you to the FinOps Foundation support team for helping us bring our work to life: Suha Shim (Staff Co-sponsor), Samantha White (Program Management), Tom Sharpe (Design), and Andrew Nhem (Staff Co-sponsor, Content).