Didn’t We Agree?

Feb 27

Recently I had the opportunity to work with one of my customers on an interview track where I was interviewing the FinOps team that was SWAT teamed in to help them on their FinOps challenges.

My mission was very clear -

“Stijn, interview these people like you would hire them for yourself. Like they would be in your company. They need to be good.”

Say no more! I would love to take you on my plan of attack. I would interview a team of 3 people with different roles.
1 would become the lead the other 2 would be hands and feet to inform, optimize and operate.

I want to take you on a journey on how I prepped, interviewed and measured. The most important take away will be somewhere at the end if you think… Get it over with what’s the final take away of this story. HINT: Scroll down ;-).

To start I want to give you some background on how I thought about measuring the team. The end goal is to make sure this team can execute together. The lead should understand what the hands and the feet do and he should be able to lead them like a Sheppard would lead his sheep through mountainous landscape to the green meadows. The execution needs to happen as instructed. The 2 engineers should be able to link the instructions to their actual work. They should be able to “translate” what the lead wants to reality. Measuring the 2 persona’s in the same way would not be a good idea. Therefor I came up with a 5 lens approach on how to measure the persona’s.

FinOps Assessment Scoring Model

Dimension	Weight	Why This Weight?
FinOps Framework Knowledge	30%	Foundation for everything. Can't structure work without it. Your map of the world.
Role-Specific Capability	25%	Lead needs strategy. Economist needs execution. Different jobs require different capabilities.
Automation-First Mindset	20%	Manual approaches don't scale. Determines if practice becomes bottleneck or enabler.
Tactical Execution	15%	Can they actually DO the work? Teachable but necessary.
Communication & Mindset	10%	Proactive vs reactive. Business language vs technical jargon. Strategic seat requires strategic mindset.
TOTAL	100%	Threshold: 3.5/5.0 for independent work

Role-Differentiated Weights

Capability Dimension	FinOps Lead	Cloud Economist / Engineer	Why the Difference?
FinOps Framework Knowledge	30%	30%	Same weight - Foundation is non-negotiable for both roles. Cannot structure ANY FinOps work without Framework grounding.
Strategic Direction	25%	10%	Lead: Core job - Designing roadmaps, sequencing capabilities, communicating maturity to C-level IS the Lead role. Economist: Context - Needs to understand WHY but doesn't design strategy.
Automation-First Mindset	20%	20%	Same weight - Lead drives automation culture and policy. Economist implements automation mechanisms. Both critical.
Hands-On Technical	10%	15%	Lead: Delegates - Must understand HOW but doesn't execute daily technical work. Economist: Executes - Writes queries, scripts, builds dashboards directly. This IS the job.
Cost Optimization	10%	15%	Lead: Oversees - Approves optimization strategy, reviews recommendations. Economist: Delivers - Analyzes data, identifies opportunities, calculates savings, implements changes.
Organizational Context	5%	10%	Lead: Nice to have - Helpful for stakeholder navigation but not core capability. Economist: Helpful - Speeds up resource attribution and recommendation acceptance.
TOTAL	100%	100%	Both sum to 100% but weights reflect different job requirements

Key Insights from Weight Differences

What this tells us:

Framework is universal (30% both) - No exceptions. Cannot do FinOps at ANY level without Framework foundation.
Lead is strategic-heavy (55%) - Framework (30%) + Strategic Direction (25%) = 55% on strategic thinking. Lead without strategy is just a senior practitioner.
Economist is execution-heavy (50%) - Hands-On (15%) + Cost Optimization (15%) + Automation (20%) = 50% on execution capabilities. Economist must deliver tangible results.
Automation is universal (20% both) - Lead drives culture/policy ("we automate governance, not manually gatekeep"). Economist implements mechanisms (tag-based policies, automated workflows). Both critical.
Strategic Direction is THE differentiator (25% vs 10%) - Biggest weight gap. Reflects fundamental job difference: Lead designs strategy, Economist executes strategy.

The Prepwork

Apart from the measuring I was also well prepared. I analyzed the CV’s rather deep and looked at how I could create questions based on their CV’s. This way I would never need to come up with stupid questions. I could always bounce back to my frame I created to do this interview.

As said, not all questions were equal and to make sure the 3 could not brief each other I decided to add some scenario questions in the questionnaire to make sure I could test the knowledge separately from each other and making sure the way the people reacted was adequate. As you could see in the measuring my radar was well calibrated on FinOps Framework lingo. I’ve had too many conversations where my counterparts focus very hard on pure workload optimization as the topic and think that is what FinOps is about. As a result, I wanted to make sure I would not go down the rabbit hole as well as having all things ready to pop a question that was maybe not expected of that would bridge to another part of my weighing criteria.

The Conversations

In general, I’m an easy going person. However I tend to dive into the I can help you understand my point of view real quick. To avoid this I always started off with the CV and some highlights that I’ve seen. Taking notes helped me keep focus on my questions and the answers. In some cases, I rephrased the answers to validate if what I understood was also wat they really meant. However, I would listen to some of the important hooks to my measurement domains. If they would say optimization, RI or saving plans I would try to ask a question that would go deeper in this topic to end my first section of questions with a Framework question. All of them were soliciting for a FinOps job so you can safely assume they understand the framework or at least that they looked at the website and got back to work thinking. Wooowww this framework is huge! I need to understand this outside in and vice versa. So I always build up… did you hear from the FinOps Framework? I’ve seen on your CV you followed a lecture on FinOps so you know about the Framework, right? The answer was 100% of the times. Yes! Nothing strange…

When I asked the questions I heard all answers but was never able to derive any capabilities or domains from the framework not even some sort of general direction of the build up in domains and capabilities, no principles, no personas,…

This left me with a strange disconnect after the conversations.

Questions racing through my head after the conversations:

*Am I wrong to assume that "knowing the Framework" means you can actually name the four domains or a capaiblity of 2?
Am I being too strict? Is Framework knowledge really that important, or am I overvaluing it?
Did they lie on their CVs? Or do they genuinely believe they "know" the Framework despite never studying it?
What does the vendor mean by "FinOps expertise" if Framework knowledge is completely absent?
Am I wrong to think that 10 years of "FinOps experience" should include basic Framework fluency?
Am I out of touch? Is the rest of the industry doing FinOps without Framework and I'm the only one stuck on this?
Is this pattern just these three people, or is this industry-wide?
Or... didn't we agree? Didn't we agree as a community that the Framework was our foundation?

Why 30% Framework Weight? Because It's Your Map of the World

Let me show you why I weighted Framework knowledge so heavily - not as theory, but how I actually use it every single day.

Recently I had a conversation where at one moment the question popped-up. "Stijn, shouldn't FinOps be part of my architecture? I started knodding and smilling. I won a soul! I immediatly said to the person that is the perfect conclusion and I'll tell you more. This is not my answer to the question but that is the community answer to the question. It even got a full capability in the FinOps Framework. Of course, I elaborate further on how this inclusion would help me create better estimations, plan workloads, forecast adapt budgets and so on. While I'm telling the story I point to capabilities like Estimating & Planning, Budgetting, Forecasting, Onboarding Workloads,... Everything is interconnected and that's what makes this so good...

This is why Framework absence in these interviews shocked me. Not because I'm a purist, but because I couldn't imagine doing FinOps work without this map.

That Brings Me to My Conclusion

After sitting with these questions for a while, I realized: I'm not being too strict. The industry has not fully understood FinOps as a job. Some of the so called SWAT teams are not SWAT teams that understand FinOps they can deliver optimizations but lack backing of a framework to understand the bigger picture. They can execute but will never understand what to do when and in which order. They will be unable in a conversation to say hold my beer - what you just said fits my framework nice and it fits here. They will never be able to push back with arguments that make sense because you know how good looks like. You understand that the framework is unique implementation at many customers as it needs to fit the DNA.

We agreed - explicitly, as a community through the FinOps Foundation that the Framework was our operating model. Four domains. 22 Capabilities. Maturity phases. This wasn't aspirational. This was definitional. But somewhere along the way, "FinOps" became a catch-all term for "anything related to cloud costs." And that drift is destroying the discipline we built.

Because if "FinOps" means whatever vendors need it to mean to win contracts, then it means nothing. If "FinOps expertise" doesn't require Framework knowledge, then what expertise are we actually measuring?

We agreed. The agreement still stands. Convince me if you can build a practice without being grounded in the framework.

Stijn Depril