FinOps teams struggle to get engineers to take action. This isn’t new. In a FinOps Foundation survey, 40% of respondents rated this issue as their top challenge. The diagnosis was that engineers are unaware of costs. They feel cost is not their responsibility. In addition, they work in environments where delivery deadlines drive effort. The conclusion was that it is an awareness and motivation problem.
In every team I’ve coached so far, I’ve observed the same thing. It is not only about FinOps. Testers, for example, who don’t file clean defects. Or tech who don’t respect a 24-hour SLA. Or even developers who don’t run the required root cause analysis.
The question is not why people don’t act. It is what in their work makes acting the obvious next step.
The diagnosis: no target means no gap
44% of the defects declared by a team of software testers I observed were false. They were not lazy or unaware. They just had no “standard” for completing a defect report. That standard would have included a check or verification against specs, which would reduce false defects. Instead, testers had no way to spot their own deviations, and nobody noticed.
The causes there are the same for cost tracking and actions regarding FinOps:
No target, so no gap is visible. A cost is just a number until there is an expected value next to it.
The related actions aren’t specified anywhere. They are vague and belong to everyone, so, as usual, to nobody.
No manager has a cadence and a structure for reviewing the gap with team members. It means there is no specified know-how for them.
Feedback arrives weeks after the decision, aggregated and sent to the wrong person, so nobody can connect the cost to the choice that caused it.
So, the consequence is the monthly bill you want to avoid. By then, it is usually too late to change course.
The FinOps Foundation diagnosis highlights awareness and motivation. That vision leads to tactics focused on information and encouragement. But information without a standard (a way to act) is just meaningless. The same goes for encouragement without a ritual to see and understand the situation: it’s just a message. No one in the team will remember that message in a few weeks.
The countermeasure: standards to act and learn
In a team, a “standard” is the current best way to do a task, written by the people who do it. It is short and visible to everyone. A standard helps to reduce variability. Using it leads to predictable results, creating a baseline so deviations become visible and improvement becomes possible. To be clear, the standard is not a policy. It is the procedure that sets the point you compare reality to.
You can use it in two ways here. The first is the team’s standard for achieving the desired cost outcome. The other is the manager standard. It is how he hands the problem to the team and ensures learning. For example, it covers what he checks, with whom, and at what cadence; what he does when it’s red. It’s the routine he follows to make a problem visible and put a person in front of it, on a schedule.
No target means no gap. So engineers need a written target per team for what “normal” cost looks like, especially for what they run. For example, expected monthly range, cost per deploy or per thousand requests, tag coverage. Write it with the team, keep it short, and revise it as they learn. From that, a cost is a deviation an engineer can explain.
Cost belongs to everyone, but means nothing without ownership. Each team needs a named FinOps champion, with a standard for the role: what they check, when, and what counts as red. It is a routine role, revised like any other standard.
No cadence means no habit. The engineering manager and the champion have a weekly improvement ritual, and it has a standard. This is the manager’s standard work. It includes how to set up the ritual, the intro, how to run it precisely, and the why behind each step.
The real cost feedback arrives too late to learn from. In an enterprise context, it takes a long time for finance to aggregate costs, among other things, and get back to tech teams. By then, engineers are on other work, and the context is gone. The reported numbers cover many things. That kills learning. So, your engineers, using their dashboard, have to raise deviations immediately. The dashboard works here only because the target defines what’s normal. Then the engineer raises the deviation the day he sees it.
Let’s be clear: guidelines and policies don’t work because a central team owns them and enforces them. A team owns a standard and revises it as it evolves.
The case
The four moves became three documents - standards - and one KPI set.
We were in a big services organization. That tech department had roughly 60 engineers.
We had three engineering managers. Each of them managed two tech teams. On top of that, a director of engineering who raised the cloud costs issue in the first place. Cloud costs had never been in scope there, so putting that on the table wasn’t well received by the tech teams.
From an organizational perspective, we created one FinOps champion per tech team. A team member voluntarily took the role. On the cost matter, he worked with the engineering manager he reported to. In addition, each tech team’s FinOps champions had the same single FinOps point of contact from the central organization’s FinOps initiative. That relationship was informative and focused more on awareness of new directions or lessons learned at the company level.
In liaison with the director, we created standards for everything.
First, onboarding: how an engineering manager onboarded himself to the FinOps initiative. It covers the full process, roles, and stakeholders. It includes how to bootstrap the initiative with a tech team until you identify a FinOps champion. Then it includes a standard for onboarding a new FinOps champion on a tech team.
The role of a FinOps champion: it covers what he does within his team about FinOps. It includes evangelization, cost KPI management, a problem-solving approach (PDCA), and cost-optimization techniques.
How to drive the initiative: one part covers the weekly ritual the engineering manager had with each FinOps champion. Then there was a continuous improvement dimension covering both the approach and the optimization techniques. Engineering managers run continuous improvement (PDCA) autonomously on FinOps and raise it in their weekly meeting with the director.
Now, the mechanism is that engineering managers run it weekly. After initial onboarding, they enable tech teams to drive costs through a structured problem-solving approach. On the other side, they run a continuous learning loop among themselves and with the director. This lets them learn cost-optimization techniques and adapt in real time.
The rituals ran on one global cost KPI with its target, and one per tech team.
Here is how I implemented it. I built the system in liaison with the director. Then I bootstrapped it by onboarding one engineering manager. He then ran the whole thing with his teams: he ran information sessions and identified and onboarded two FinOps champions. Onboarding a champion meant the team’s cost KPI was in place and managed within the team. Then we did a continuous improvement session together, where we updated the standards he used based on what happened in reality with the teams. From that first improvement iteration, we got a new version of everything and agreed he would then onboard another colleague engineering manager. Then I left them to it. My part of building that was done. Whether the loop held is not mine to claim.
Standards reduce variability in task outcomes, regardless of who uses them. Standards trigger the right problem-solving at the right time for the right reasons.
This champion program runs on standards. Organizations meter their token billing daily, so the feedback can be same-day. With a target, a standard, and a ritual, you tackle the deviation the day it appears, not on the bill.