How I Started Building My FinOps Mental Model
And the resources that actually helped
When I decided to learn FinOps, I felt overwhelmed.
There was no shortage of content: frameworks, dashboards, tools, certifications, maturity models, and a lot of strong opinions. Everyone seemed to be “doing FinOps”, but often in very different ways.
What I didn’t need was more content.
What I needed was a way to think clearly about cloud costs.
This post is not a list of “best FinOps resources”.
It’s a reflection on the articles and ideas that helped me build a mental model, especially at the beginning, when everything felt abstract and messy.
I’m still learning. But these resources helped me move from confusion to clarity.
Tagging: where FinOps either starts… or quietly fails
Early on, I kept hearing the same advice:
“You need better tagging.”
That sounded simple enough, until I saw it fail in practice.
What finally clicked for me is that tagging is not a technical problem.
It’s a socio-technical one.
Several articles I read framed untagged resources as ghosts: they consume money, hide from governance tools, and disappear when someone needs accountability. That metaphor stuck with me because it matched what I was seeing.
But I also learned the opposite failure mode: tag chaos.
When every team invents its own tags:
trust disappears
reports become unreliable
people stop using tags altogether
At that point, tagging becomes noise, not signal.
The pattern that emerged for me was this:
Start with a small, non-negotiable core
Make tags visible before enforceable
Build trust first, guardrails later
Treat tagging as a program, not a checklist
The most important realization was this:
over-policing tags too early creates friction without savings.
Tagging only works when people understand why it exists, and see value from it.
Resources:
Unit economics: the mindset shift I didn’t expect
Another big shift came when I read about not looking at total spend.
At first, cloud cost conversations start like this:
“How much did we spend?”
“How much did we save?”
But several posts challenged that framing hard.
The idea was simple, but uncomfortable:
Total spend is meaningless without context.
The only number that really matters is cost per unit of value.
Cost per customer.
Cost per transaction.
Cost per feature.
That reframed everything for me.
Cutting cloud spend might look good in a report, but if unit costs go up, you’ve actually destroyed value. Conversely, higher spend can be a good outcome if unit economics improve.
Another insight that stuck with me:
raw cost data rarely drives action.
Engineers don’t care about invoices.
They care about tradeoffs.
When cost is connected to performance, scalability and customer impact.
It becomes part of engineering decisions.
That’s when FinOps starts behaving like a business discipline, not a finance report.
Resources:
Tools don’t fail, expectations do
As I kept learning, I noticed a recurring theme.
Many FinOps frustrations weren’t caused by bad tools.
They were caused by using tools to compensate for missing practices.
Oversized EC2 instances, runaway logs, inefficient serverless workloads, these weren’t caused by ignorance. They were the natural result of systems where:
cost wasn’t visible
ownership wasn’t clear
incentives weren’t aligned
One idea I really liked was the notion of a crawl phase done properly.
Not immature.
Intentional.
Basic tagging.
Simple showback.
Manual reviews.
Fast feedback loops.
The goal isn’t optimization at scale. It’s trust at scale.
That also helped me understand why FinOps so often struggles without leadership support. If cloud is treated as “just another IT expense”, FinOps never becomes part of normal operations.
And maybe the most important reframing of all:
Cloud costs are engineering outcomes.
Engineers control the levers.
Cost, performance, and reliability are the same conversation.
FinOps doesn’t exist to shame teams.
It exists to help them make better decisions.
Resources:
Nicola Sfondrini - Agile’s Ghost in FinOps: Over-Expectations, Wrong Metrics, and Cultural Blind Spots
FinOps as a practice, not a checklist
Across all these resources, one consistent message emerged:
FinOps is not about saving money
It’s not about dashboards
It’s not about tools
It’s about behavior.
It’s about asking uncomfortable questions:
Do we really need this?
What value does this deliver?
Who owns this decision?
That’s why ideas like the FinOps Forensic Operator resonated with me.
Not someone who watches dashboards, but someone who investigates, connects dots, and translates cost into decisions.
And it’s why cultural tools - training, shared KPIs, even gamification - often matter more than technical ones.
Resources:
Where I am now
I’m still early in this journey.
These resources didn’t give me a playbook.
They gave me better questions.
They helped me understand that:
FinOps maturity can’t be copy-pasted
Frameworks are inspiration, not instructions
Tools enable practices, they don’t replace them
If you’re just starting out, I hope this saves you some confusion.
And if you’ve been practicing FinOps longer than I have, I’d genuinely love to know:
What resource, idea, or experience helped you most early on?