Cost Spikes as Incidents: How Sasi Kanumuri Built a FinOps Discipline That Lasts

Most FinOps teams treat a cost spike the way a finance team treats a variance report: something to look at next week, after the dashboards refresh and the chart looks cleaner. Sasi Kanumuri treats it the way an SRE treats an outage. Page someone. Run the post-mortem. Write the guardrail. Then move on.

He has been working at that bridge for the better part of a decade. He stumbled into FinOps at Uber in 2019, before the discipline had a name, when engineers wanted to optimize the bill but had no idea where to look. He has scaled the same playbook at Slack, Lacework, and AWS as a Cloud Economist. He implemented a FinOps consulting practice as a co-founder at Sunnylabs AI. He is now Head of FinOps at Supabase. Along the way he wrote a book about it, Scaling Cloud FinOps, and codified the practice into a six-pillar formula he carries from company to company.

Outside work he cycles indoors on Zwift, with YouTube in the background. Not for competition. For consistency. He treats the on-call rotation the same way: keep the feed open, pace yourself, and pause only when something needs you.

The thesis he tests at every company he joins is simple: optimisation without cultural embedding re-leaks every quarter. The signal that the culture has taken, in his telling, is not an optimisation number. It is the attention the work earns without asking for it.

FinOps as a discipline has the curious property of having existed before it had a name. Engineers were already chasing cloud bills in the late 2010s. Finance teams were already producing variance reports. What they lacked was someone fluent in both languages, willing to sit between them. Sasi found the role at Uber in 2019, more than a year before the FinOps Foundation incorporated. It is worth understanding what the job looked like before it had a job title.

The bridge job arrived before the title did, sitting between engineers who wanted to optimise the bill and finance teams who couldn't tell them where to start.

Q: How did you end up doing FinOps before FinOps was a discipline?

Uber was preparing to go public, and the engineers were willing to do the work to optimize spend. They just didn't know where to start. I loved math from my childhood, so I was able to pull AWS Cost Explorer numbers, dive deep into the reports, and find utilisation-level metrics and optimisations beyond what AWS provided by default through Trusted Advisor. I communicated those back to the engineering teams internally and we achieved significant savings. That was the real pivot for me. I had been a cloud architect. I became a translator between engineering and finance.

Q: And the role evolved further at Slack.

At Slack I was the founding engineer for the cloud economics team. That is where I built real muscle around TPM work and around finance. I do not come from a finance background. I learned it on the job, working very closely with our internal finance teams. That was just before Salesforce acquired Slack, so there was a lot of due diligence to sit through. By then I had stopped being a cloud engineer who happened to do finance work. I was a FinOps Engineer. The discipline just hadn't caught up to the name yet.

Most FinOps programmes start the same way. A finance director arrives with a bill nobody can explain, an engineering manager is told to make the line go down, and a quarter later the savings have already been undone. Sasi built his Six-Factor Formula to break that cycle. Not by optimising harder. By widening what FinOps is allowed to touch.

Six pillars, each with a job. The framework only works because each one feeds the next.

Q: Why did you need a new framework? The Inform-Optimize-Operate model already existed.

There isn't a defined way to start and scale a FinOps programme. Usually FinOps is born out of heavy costs. Finance comes with a stick and tells engineering: lower the costs. That is how a FinOps team gets inaugurated. But as soon as the savings are achieved, momentum is lost in most companies. Within the next quarter you see the same costs over and over. You can put automation in place, but it has to come through a set framework and process. That is why I took the time to build the Six-Factor Formula. We formalised it at Lacework. The whole framework is in the book I wrote, Scaling Cloud FinOps.

Q: Walk us through the six pillars.

It starts with cloud cost visibility. Tagging, dashboards, getting Snowflake, Databricks, AWS, and GCP all into a single pane of glass. Separate dashboards for engineers, separate ones for executives. Then cost insights: anomaly detection routed into team-specific Slack channels, and unit economics on top of that. We did a top-ten profit and top-ten loss customer analysis at Lacework, and that work improved our margins significantly. Then governance, which is where the #piggy-bank framework lives. Then optimization. Then automation. Then vendor management. The full spectrum. The FinOps Foundation's Inform, Optimize, Operate lifecycle still works on top of this. The six pillars give you the structure. The lifecycle gives you the cadence. Both run together.

The Six-Factor Formula is portable. The #piggy-bank is its cultural engine. It is also the part of Sasi's playbook he is proudest of having named. The mechanism is almost embarrassingly simple: a Slack channel, until you watch what it does to the rituals around it.

A single Slack channel turned cost discipline from a slogan into a habit, and a co-CEO's daily reading list.

Q: Why treat cost spikes as incidents in the first place?

When you start treating cost spikes as incidents, that is when you get them to work through metrics. You can cultivate a culture of cost awareness in engineering teams when you create that incident management process and route cost into the process they are already following. MTTR for a cost incident becomes a metric the FinOps team can showcase. It forces you into the existing post-mortem and RCA framework. You put guardrails in place so it doesn't happen again. That is how you embed cost awareness. The infrastructure was already there. We just routed cost into it.

Q: How did you get leadership to take the channel seriously?

I get buy-in in different ways at different companies. Usually the starting motive is the same: optimize spend, make sure we are efficient. I use that as the anchor to begin. But the real thing I am building is leadership being able to see my #piggy-bank channel and celebrate along with engineers. At Lacework one of the co-CEOs told me the #piggy-bank was his go-to channel to track and celebrate cloud efficiency. A priceless recognition. The day a CEO says that, you know you have moved from a project to a practice. There will be reluctance at first. Patience is the key. You have to be patient and egoless to do this work.

Most FinOps writing treats vendor negotiation as a procurement function. A different building, a different quarter, a different skill set. Sasi treats it as the sixth pillar of the same discipline. The logic is direct. If you optimize the architecture without optimising the rate card, you have left half the lever on the table.

Don't pay list price for anything. Every line on the contract is a place to ask for more.

Q: At what scale should a company negotiate directly with a cloud provider versus going through a reseller?

When you have less than three million dollars in spend, you are not going to be at the table with much ammunition. Below ten million total commit, I would recommend going through a reseller. People call those platforms the Costco of the cloud. You get the PPA discount the reseller has already negotiated for its book of business. You don't have to negotiate with the cloud provider directly. You still get the discount. Once you are hitting ten million and showing year-over-year growth, that is when you engage with cloud service providers directly. CSPs like forecasting growth and baking it into discounts.

Q: And once you are at the table, what is the lever?

Don't go in with the forecast number you are already comfortable with. Be very conservative. Over-committing is the mistake. It doesn't give you leverage and it doesn't give you room. When you show growth but come in with a lower commit than you can actually deliver, that is when the room opens. You can say: we are willing to do a little more, can you do additional percentage points on the discount? You also have to be vocal about what you want. They will not volunteer it. You have to specify the ask. Don't pay full price for anything.

AI cost is the bill no enterprise has fully read, and the team responsible for reading it may not exist in its current form much longer. Sasi has been doing FinOps long enough to recognise both shifts at once. Compute always gets reframed before it gets recharged. And every operational discipline eventually disappears into engineering. DevOps did. SRE did. FinOps is on the same path.

The AI bill is sitting in the future, somewhere between 2028 and 2030. Nobody has read it yet.

Q: How are you thinking about AI cost right now?

Right now, enterprise customers get significant discounts in the first few years when they sign up. That is the subsidy phase. The elephant in the room is what happens after. My gut says between 2028 and 2030 we will see enterprise customers either moving out completely or enforcing hard guardrails around token usage. Right now your engineers are free to consume whatever number of tokens they want. There is going to be a point where companies realise this is costing more than they are getting out of it. The reckoning is coming. It just hasn't shown up on the invoice yet.

Q: Does the Six-Factor Formula scale to AI cost?

The framework applies to anything where there is cost involved. I haven't scaled it to AI yet. I have done some analysis on token consumption and optimisation, but I have not built it into the framework as a discrete workstream. That is an undetermined point for me at this time. The shape of the AI bill in three years will tell us whether we extend the framework or replicate it.

Q: Where is FinOps heading in the next five years?

When I started my career, DevOps was treated the way FinOps is treated today. Then the shift-left started. Infrastructure moved closer to engineering, engineers got empowered to do the work themselves. FinOps will follow the same path. Teams will get leaner. Scope will get broader. You don't need ten people to own this. You can be effective with two or three. We will see FinOps people sitting next to engineers on PRs, doing the code review alongside them. In five years it will be embedded in every organisation. Whether they have a separate FinOps team or not, they will be doing FinOps in one way or another.

Q: What role does AI play in that shift?

AI could accelerate it. More agents, more MCP servers, more ways for engineers to talk to the bill. That is ambiguous territory for most of them today. The benefit lands when AI is integrated into Slack, or whatever workspace tool they are already using. An engineer can ask: what are my costs, how are they trending week over week. You save them the context switch into Cost Explorer. That is where I see the traction. For FinOps people themselves it matters less. We are already married to the tooling. But for engineers, AI is the bridge.

FinOps that does not stick costs more than the savings it produces. The Six-Factor Formula and the #piggy-bank are Sasi Kanumuri's answer to a discipline that re-leaks every quarter. The framework is portable. The channel is free. What it requires is patience, the trait nobody lists on the job description and the one that makes everything else hold.

Cloud Value Lab publishes practitioner-led thought leadership at the intersection of FinOps, GreenOps, and AI Economics. If you are a practitioner or subject matter expert interested in sharing your perspective, reach out to David May.