If you had told me a few years ago that my professional life would revolve around cloud billing files and “Unit Economics,” I would have likely been skeptical. At the time, I was more project focused on a world defined by timelines, deliverables, dependencies, and stakeholder alignment
Projects had clear start and end dates. Success was measured by whether things shipped on time.
But as organisations moved aggressively to the cloud, I began to notice a gap. Projects were finishing, yet costs were only just beginning. The technology teams moved on to the next initiative, while finance was left staring at a growing bill with very few answers.
There was a missing link between the people building systems and the people paying for them.
That gap is where my FinOps journey started. It wasn’t just a career pivot — it was a shift in how I understood the relationship between technology, cost, and value.
Lesson 1: Certifications Are the Map, Not the Territory
One of the first steps I took was pursuing FinOps certifications. They were incredibly useful. They gave me a shared language — Reserved Instances vs Savings Plans, showback vs chargeback, and the familiar Inform → Optimise → Operate lifecycle.
But the real learning began when theory met reality.
In a certification exam, the solution to overspend is often straightforward: right-size the instance.
In the real world, the answer is more nuanced:
“We can’t right-size this right now the lead engineer is worried about peak load during the holiday season.”
That’s when it clicked.
FinOps isn’t just about calculations and frameworks. It’s about understanding why people make the decisions they do.
The lesson: FinOps is math but also majorly psychology.
Certifications teach you the rules. The field teaches you how to apply them without breaking trust.
Lesson 2: Tagging Is a Culture, Not a Task
Early on, I thought tagging was a simple hygiene issue just another checklist item engineers needed to follow. I couldn’t have been more wrong.
Poor tagging quietly destroys FinOps efforts. Without reliable metadata, showback reports become educated guesses. Accountability disappears. Optimisation turns into speculation.
But here’s what surprised me most: you can’t force good tagging.
What actually works is visibility.
When engineers can see the real cost of the services and features they own, behaviour changes naturally. Cost stops being abstract and starts feeling personal not in a negative way, but in an ownership-driven way.
The lesson: Stop asking people to tag resources. Start showing them what untagged resources hide.
Visibility creates accountability far better than enforcement ever will.
Lesson 3: The “Aha” Moment of Unit Economics
One of the most defining moments in my FinOps journey came when I stopped talking about total spend.
I remember sitting with a product owner and, instead of saying, “Your cloud bill is $10,000 higher this month,” it was “Our cost per active user has dropped by 15%, even though total spend increased.”
The conversation changed instantly.
I was no longer the person pointing out a problem. I had become someone helping the business understand efficiency, margins, and trade-offs.
The lesson: Always tie cloud spend to business value.
Without context, you’re just reporting costs. With context, you’re enabling decisions.
That’s the difference between being seen as cost control and being seen as a strategic partner.
Lesson 4: FinOps Is a Team Sport
Project management prepared me well for one key aspect of FinOps: collaboration.
- In FinOps, you sit at the intersection of three very different perspectives:
- Engineering wants speed, reliability, and performance.
- Finance wants predictability and cost control.
- Business wants growth, outcomes, and ROI.
Success doesn’t come from siding with one group over another. It comes from translation.
My role gradually shifted from managing delivery to managing trade-offs helping finance understand technical risk, and helping engineers understand financial impact.
The lesson: FinOps works best when someone is willing to be the connective tissue between cultures.
Advice for Anyone New to FinOps
If you’re just starting out, here’s what I wish I had known earlier:
Here is my advice:
- Be Curious, Not Accusatory: When you see a cost spike, don’t ask “Who broke the budget?” Ask “What changed in our architecture?”
- Learn the Architecture: You don’t need to be a developer, but you must understand how your cloud is built. You cannot optimise what you do not understand.
- Find the “Quick Wins”: Don’t try to solve the whole enterprise in week one. Find a neglected sandbox environment or an unattached storage volume. Show the savings, build the trust, and use that momentum for bigger battles.
The lesson: FinOps works best when someone is willing to be the connective tissue between cultures.
Lastly The Journey is the Destination
My journey from Project Management to FinOps has been a lesson in becoming a “Human API.” My job is to translate between the world of Finance and the world of Engineering so that both can succeed.
The field is still young, and the rules are still being written. Whether you’re an engineer, a finance pro, or a project manager, there is a seat at the table for you. The question isn’t whether you’re ready; it’s whether you’rewilling to start.
Because in FinOps, just like in the cloud itself, it’s still Day One.
