Most FinOps leaders measure success by the dashboards they publish and the savings they claim. Rohit Mishra measures his by the weeks nobody calls him.
His career began far from cloud bills. In 2009 he was a Unix admin at an Indian IT services firm, mounting filesystems and tracking hardware costs on a spreadsheet. By 2015 he had moved into AWS and started connecting workload decisions to engineering trade-offs. When FinOps emerged as a formal discipline around 2020, he was already most of the way there. Today he leads Cloud FinOps at Avaloq, a Swiss banking software platform whose clients are banks and whose regulators are unforgiving.
He is also, improbably, a train-spotter. Since school, Rohit and a small circle of friends have tracked India's railway fleet by engine type, route, and running time. What sounds like noise to most people, he hears as music. Ask him how FinOps actually moves through an organisation and the metaphor arrives before the answer does: a long train journey, he says, does not go from source to destination in one push. It stops. It re-evaluates. It waits for the other lines to clear.
The argument in what follows is that mature FinOps is not visible. It is absorbed. When it works, nobody notices. That is the point.
Make FinOps Boring: Why Maturity is Measured in Silence
A well-run train service is one nobody notices. The timetable holds. The signals clear. Passengers go about their day without looking up. Every FinOps programme has the same choice hidden inside it: be noticed, or be effective. Most choose noticed, because noticed is what executives reward. Rohit believes that trade is exactly the wrong way round. When FinOps matures, the noise around it tends to fall away. Getting there, he says, starts one level higher than most teams begin.
Q: You often talk about shift left. You also talk about "shift up." Which one comes first?
Shift up comes first. Without management support, shift left is very difficult. When I joined Avaloq, FinOps was in its very early stages, so I would go to the console every day and do the basic things. If there was one unattached volume, I would work on that and show some savings. That is how I earned the lock-in. You cannot move to a strategic conversation until leadership trusts that you understand the operational one. Shift up is what makes shift left possible.
Q: What does mature FinOps actually look like to you?
It is not better dashboards. It is not more reporting, and it is not a bigger line for cost savings at the end of the quarter. Mature FinOps is measured by the shrinking number of excuses. Teams used to say they had not implemented tagging because we had not given them the right inputs, or they had not actioned the feedback. Those are excuses. If a FinOps programme is mature, you stop hearing them. The dashboards that used to matter so much are still running. Nobody is talking about them anymore. That is the signal.
Q: You describe your goal as "making FinOps boring." How do you operationalise that?
I am a football fan, so the reference I use is the referee. After a great match, if you cannot remember the referee's name or face, it means he has done a very good job. FinOps is the same. If management is not talking to me for a month, it means I am doing my job very well. The way to get there is language. I do not walk into an engineering team with action items. I ask them: can you solve this? They hear it as a personal challenge, not a control request. They take the work because they own the answer.
FinOps in the Pull Request: Where Culture Actually Lives
Every FinOps team eventually discovers that dashboards do not change behaviour. Emails change behaviour for about a week. Reports change behaviour for about an hour. What changes behaviour permanently is the thing that fails a deployment. Railways learned this a century ago. Human vigilance is the wrong place to enforce safety; the signalling does the work, and the signalling does not take a day off. Rohit's second move, after earning executive trust, was to stop asking teams to do things and start making the system refuse to deploy without them.
Q: You went from sending dashboards to failing pull requests. What changed?
Everything at Avaloq goes through GitHub Terraform workflows. If you want to spin up a resource, it happens in a pull request. So we made the FinOps checks part of that pull request. If the tags are missing, the PR fails. If the backup policy is wrong, the PR fails. The volume of emails going from my team to engineering has dropped a lot, because the check is structural now, not behavioural. I always tell my teams: if FinOps is not part of your PRs, then FinOps is not in your organisation's culture. It is still a project, not a practice.
Q: How did you avoid the typical backlash teams get when FinOps tries to add new checks?
We did not try to add a new gate. There was already a governance pipeline for security checks in the Terraform modules, so we added our components to the existing set. Engineers were already used to the structure. Adding FinOps rules inside a framework people already accept is much easier than standing one up yourself. We also defined the allowed tag values upfront, based on our cost centres and customer structure. Engineers are not being asked to guess. They pick from a standard list. If the tag is wrong, the PR fails for the same reason any other compliance PR fails.
Teams at Avaloq were not applying the required tagging consistently. The FinOps team would send dashboards showing the gaps, then emails, then reminders. The non-compliance kept reappearing every quarter. Chasing it was endless and delivered diminishing returns.
Rohit's team worked with Avaloq's automation and operations teams to embed tagging and policy checks directly into the existing GitHub Terraform pull-request workflow. A submitted module missing required tags or failing policy validation does not merge. Email volume from the FinOps team to engineering dropped sharply. Compliance became a structural property of the pipeline rather than a behavioural ask.
Rate Before Optimisation: Where the Biggest Savings Actually Live
The FinOps Foundation has spent years training the industry to see usage optimisation as the primary lever: rightsize, reshape, eliminate idle. Rate optimisation is treated as procurement's job, a thing FinOps inherits rather than shapes. Rohit thinks the order is reversed. The most important meeting in FinOps, he argues, is the one where the next contract gets signed.
Q: Tell us about the rate optimisation project you ran with the vendor-management team.
A few years back, we entered a new multi-year commitment with one of our cloud providers. Vendor management was running the negotiation. I went to them and said: there are two sides to this contract. You can concede on prices for SKUs we barely use. But for the top ten SKUs we use most, you need the best price possible. I pulled the historical usage data and gave them the list. They asked me to join the discussions. On those top-ten SKUs we ended up with a significant discount. The multiplier effect over the life of the contract dwarfs the short-term optimisation work we had been doing before.
Q: You seem remarkably unbothered by the fact that cloud providers have an incentive to sell more, not to save you money.
I am very happy they are not doing it for me. That is why I have a job. Take AWS raising EKS support fees. Teams internally get upset. I say: they are offering you standard support for a fixed period, and after that period you pay more. A new version is available. There is a maintenance window. The provider is trying to make profit. Of course they are. That is the nature of the business. It is the same nature we operate under when we contract with our own clients. I do not see it as dishonest. I see it as my job to respond to it.
Avaloq's short-term optimisation work was delivering real but incremental savings. Rightsizing idle volumes, switching off unused resources, closing out waste reports: each meaningful, none game-changing. A much larger lever sat at the contract stage, but the FinOps team had historically been absent from those conversations. Rate discounts were negotiated by vendor management without usage-weighted input from the people who knew the workload best.
Ahead of a recent multi-year commitment, Rohit's team produced a ranked list of Avaloq's top ten most-used SKUs from historical data and handed it to vendor management. The FinOps team joined the negotiation directly. On those top-ten SKUs the final contract delivered a significant discount. The lifetime saving on that block of usage has exceeded the annualised impact of every short-term optimisation project Rohit had run in the preceding years.
India is Exporting, Not Emerging: Why FinOps Talent is Shifting East
The received wisdom places FinOps's centre of gravity in the United States, anchored by the FinOps Foundation and its annual FinOps X conference. Rohit does not dispute the origin story, but he is one of many practitioners who see the next chapter being written elsewhere. India runs one of the largest railway networks in the world. It also runs a significant share of the world's IT operations. When cloud spend began to climb, the engineers closest to the infrastructure were asked to solve it. Many of them, like Rohit, liked the problem enough to stay.
Q: At FinOps X Bangalore a few weeks ago, a line you heard stayed with you: "FinOps in India is not emerging. It is exporting." What does that mean in practice?
The engineers closest to cloud operations in India have depth and scale. When costs rose, management went to them with the problem. It did not go to finance, because finance was not going to solve deployment waste. So FinOps in India emerged bottom-up, out of the DevOps teams. The attractive part for us was the bird's-eye view. As a DevOps engineer you might own compute, or storage, or network. In FinOps you own all of them, plus the commercial logic sitting on top. That is why so many of my colleagues made the move, and why the ideas coming out of the Bangalore community are not copies of what happens in San Diego.
Q: Is it just scale, or is there something cultural about how India approaches cost?
It is part of the culture. You do not just buy the best thing. You buy the best thing at value. That mindset sits behind why unit economics is such a sought-after topic at community meetups here. People are not just chasing raw savings. They are looking at the metric. The other piece is professional pride. If I show an engineer that something they built has waste in it, they take it personally. They do not wait for an action item. They ask how to fix it themselves. That makes the FinOps practitioner's job easier. The lever is already inside the team.
Key Takeaways
Rohit's perspective lands with these essential insights:
Boring is the goal. Mature FinOps is measured in the absence of excuses, not the presence of dashboards. When the organisation stops noticing the function, the function has worked.
Shift up before shift left. Executive trust is the gateway, not the destination. Without it, shift left is a style choice with no teeth.
Pull requests are culture. If a rule cannot be enforced by a deployment gate, it is a suggestion. Culture lives in the build, not the dashboard.
Rate is the larger lever. The biggest savings live upstream of the console, in the contract. FinOps belongs in the negotiation with usage data in hand.
Vendors are not adversaries. Expecting a cloud provider to reduce your spend confuses their job with yours. The only lever you fully control sits inside your own organisation.
The north-star question. When the organisation stops talking about FinOps, is that because the function has failed, or because it has finally worked?
Implementation Roadmap
Earn
In the first weeks of a FinOps function, chase low-hanging fruit: idle volumes, unused resources, obvious waste. The objective is visible savings, fast, to secure executive trust. Without the mandate, nothing else compounds.
Codify
Once trust is secured, move FinOps checks into the deployment workflow. Tagging, policy validation, backup settings: if the pull request fails without them, compliance is structural rather than behavioural.
Piggyback
Do not build a separate FinOps gate. Add your components to the security and compliance checks engineers already accept. The acceptance layer is already there. Use it.
Claim
Get usage-weighted data into vendor negotiations before the next multi-year deal is signed. Identify the top ten SKUs by consumption. Concede on what you barely use. Win on what you use most.
Reframe
Replace action items with questions engineers can answer. "Can you solve this?" is a challenge. "Please implement this" is a ticket. The first moves faster than the second.
The Bottom Line
Most FinOps programmes are judged by the noise they make. Rohit judges his by the noise it has removed. The destination is the same everywhere: efficient, accountable, adult cloud spend. The signal that the train has arrived is that nobody on the platform is looking up anymore.
About Rohit Mishra
Rohit Mishra is Head of Cloud FinOps at Avaloq, the Swiss banking software platform. He began his career as a Unix admin in 2009 at an Indian IT services firm, moved into AWS workload cost analysis in 2015, and has been practising FinOps as a formal discipline since the start of the decade. He is a confirmed speaker at FinOps X 2026 in San Diego, a regular voice in India's FinOps practitioner community, and a guest of the FinOps in Action podcast series. Connect with Rohit on LinkedIn.
The perspectives expressed reflect the interviewee's personal experience and views. Cloud Value Lab publishes practitioner-led thought leadership at the intersection of FinOps, GreenOps, and AI Economics.