The Conductor's Score: How Anderson Oliveira Turns Leadership Accountability into FinOps That Works

Ask most FinOps practitioners what blocks progress and they will point to tooling gaps, engineering resistance, or a missing business case. Ask Anderson Oliveira and the answer lands closer to the boardroom. "Maybe 90%, 95% is a leadership problem," he says. It is a claim that cuts against the profession's instinct to solve everything with better dashboards.

Anderson did not arrive at FinOps through the usual path. His career began in project management, where he specialised in schedule and cost management and studied Earned Value Management long before cloud economics had a name. When organisations shifted from capital expenditure to operational cloud spending, the discipline he had spent years refining suddenly had a new stage. By 2021, he was among the first wave of practitioners to join the FinOps Foundation and contributed to the first version of FOCUS, the cost and usage specification that is still shaping how the industry standardises cloud data.

Outside of FinOps, Anderson is a multi-instrumentalist and vocal arranger who conducts a cappella ensembles in his community. He describes music the same way he describes FinOps: a puzzle where math, rhythm, melody, and harmony must fit inside a single structure. The melody only emerges when every player follows the score and trusts the conductor to hold the tempo. That instinct for orchestration runs through everything Anderson argues about cloud economics. And his argument starts at the top.

When executives declare FinOps sponsored without defining what sponsorship requires, practitioners are left advocating without authority.

Many organisations claim to sponsor FinOps. Few define what sponsorship actually requires. Anderson sees a pattern repeated across the European market: executives hire a FinOps practitioner, declare the job done, and walk away. What follows is a practitioner stranded between optimisation opportunities and engineering teams with no incentive to act on them.

Q: You have worked across many FinOps engagements. Where do you see the biggest friction when organisations try to adopt FinOps?

If I had to estimate, I would say that the majority of the problems, maybe 90%, 95%, is a leadership problem. I see questionable behaviour when an executive says that they sponsor FinOps only by hiring someone to do FinOps. And then that person's job is to find optimizations and try to convince people to do those optimizations. That is not a good place to be. The right way to move forward is when leadership asks for accountability from their teams. That is where FinOps starts. Leadership requiring accountability gives teams the motivation to change.

Q: What share of leadership actually gets it versus those who simplify FinOps down to cost savings?

Executives need to deal with many things at the same time, so they tend to understand things in simple terms. Some are making FinOps equal to cost savings. That simplification is not beneficial for the practice. If executives look for cost savings, you will see many services being incentivized to provide cost savings solutions. Do not be fooled. It is easy to save 30 to 35% on your first year of FinOps implementation. That is low-hanging fruit. But those big savings are not sustainable year after year. Leadership will say, "They are not saving costs, so they are failing." They are not failing. They just did not understand FinOps.

A well-constructed budget does more for FinOps adoption than any platform on the market.

If leadership is the root cause, budget is the mechanism Anderson prescribes. Not as a constraint, but as the instrument that converts executive intent into team-level ownership. In his view, a well-constructed budget does more for FinOps adoption than any platform or optimisation tool on the market.

Q: You mentioned the budget as the foundation for accountability. Why is it so central to making FinOps work?

Budget is the instrument where you establish accountability and boundaries. If anyone has been through a budgeting process, you know it is a long negotiation. You have finance on one side, leadership on another, engineering on another, and they are trying to agree on how to share resources for the next period. It is time-consuming and stressful. But once the budget is ready and correctly broken down at the level where you are going to ask for accountability, you enter an execution mode. Leadership can see if things are going well. At the same time, teams understand that if they do well with their share, they contribute to the greater good of the organization.

Q: How does the budget change the dynamic for engineering teams specifically?

Engineering teams look at performance metrics, observability metrics. They want their workloads to serve the objectives they were created for. Now they need to add another dimension: is that workload spending what it is supposed to? Engineers are not sitting on the bench waiting for work. They are very busy with other work types. Bug fixes, enhancements, technical debt. Cost optimization is a work type too, but if there is no incentive to do it, they will do the other things first. Cost optimization is a backlog item that needs to be prioritized by the product owner. Without a budget-driven incentive, it will not rise to the top.

Most organisations celebrate early savings without reaching the stage where FinOps measures what truly matters.

Anderson's maturity model is deceptively simple: a three-step progression, each step building on the last. The challenge is that most organisations get stuck celebrating early cost savings without ever reaching the stage where FinOps starts measuring what truly matters: value delivered per dollar spent.

Q: You described a three-step progression for FinOps maturity. What does that look like in practice?

First, provide visibility on cost. Can you show cost by team, by business unit? Is it accessible? Is it timely? If not, let us work on that. Once you have visibility, you have all the ingredients to establish a budget by team, by business unit, by whatever breakdown fits your organization. Now you can set objectives and track costs. The third step is unit economics. Not only budget, but does the workload provide the value it was intended to provide? Measure performance not based on cost savings, but on how much value you are delivering.

Q: You have spoken about the shift left approach, where engineers think about cost before they deploy. What does effective shift left look like?

Engineers like to do the right thing. They want to have the best solution. They know how to build something performant because they have means to measure that. They know how to build with security because they can measure that. But engineers often lack visibility of the cost, and it is the role of a FinOps practitioner to provide them with it. For shift left, we need to equip them with ways to estimate cost before they even deploy anything to any environment. I heard this week at FinOps X an outstanding use case where engineers put an MCP server into their deployment pipeline. When they run the pipeline, it automatically calculates the cost of that pull request. They can see how much it will cost before deploying, and then they have a chance to have a conversation. Is this reasonable? Can we do it differently? Can we deploy that in a different way to reduce the cost impact? That is the real shift left. The furthest left you can get is discovering how much something will cost before it is deployed.

Q: You researched other industries that have operated on OpEx models for decades. What did you learn?

I interviewed a friend of mine who is a plant manager in manufacturing. He taught me more about FinOps principles than I could learn anywhere else, and he has never heard of FinOps. In manufacturing, budgets are present and they have efficiency measurements. In IT, efficiency measurement equals unit economics: how much value you deliver for every dollar spent. The question is, what is the value your workload delivers? That is an easy question to ask with a very difficult answer. I see many people referencing unit economics, but very few putting it into practice.

AI is requiring cost visibility per request, per second. A frontier FinOps has not yet solved.

The FinOps Foundation announced its 2026 roadmap at FinOps X in London just days before this conversation, signalling a clear expansion beyond cloud into data centres, SaaS, and broader technology economics. At the same time, AI workloads are pushing the boundaries of what FinOps can measure. Anderson sees both opportunity and risk at the frontier.

Q: The FinOps Foundation is expanding its scope beyond cloud. What is your view?

I have mixed feelings. When you open up the definition of something, you risk losing sight of the problem you are really trying to solve. FinOps becoming everything and everywhere is concerning. But from the other side, the business is requiring the benefits that FinOps brings. FinOps introduced the concept of providing real-time cost and usage data. Before FinOps, financial cycles happened monthly, quarterly, or yearly. Cloud brought near real-time visibility. Other areas of technology now want the same granularity. Monthly is not enough anymore.

Q: AI economics seems to challenge the entire measurement framework. How do you see that playing out?

AI is now challenging FinOps. Cloud providers normally provide cost data every four hours or daily. But AI is requiring us to see cost per request, almost per second. How many tokens are we consuming at that moment? I am seeing a spike in cost for AI workloads and LLMs in a crazy trend. We do not know exactly what to do with it yet, but we know we need to measure it and observe it in a matter of seconds.

The discipline will not mature until procurement, product, and finance practitioners join the conversation.

Anderson speaks about the FinOps community with the warmth of someone who found his place in it early and never stopped building. But he also sees gaps. Too many voices in the room belong to one persona, and the discipline will not mature until the full ensemble shows up.

Q: The FinOps community is growing fast. What stands out to you about its character?

What I love about this community is that everyone is trying to solve the same problem and feeling the same pain. There are no divisions over politics, religion, economy, or anything else. FinOps is pure logic. A diverse group of people can sit at a table and discuss FinOps for hours without conflict. There are no geographic boundaries. People from the US speak at European events, Europeans speak in South America and Asia. It is open.

Q: What advice would you give someone trying to enter FinOps today?

Start with the FinOps Practitioner certification. Then look at the personas: practitioner, engineer, leadership, finance, procurement. Make it a T-shape. Understand all of them broadly, then choose one and go deep. If you make a mistake, go back to the top level, choose another, and go deep again. I want to see more FinOps procurement people, more product managers, more finance people stepping up and speaking. I met people at FinOps X who felt they were not part of the community. They absolutely are. They have complementary skills that we need.

FinOps will not advance as a discipline until leadership stops treating it as a cost savings exercise. Organisations that build accountability through budget, measure efficiency through unit economics, and equip engineers with cost visibility before deployment will capture value their competitors are still leaving on the table. The score has been written. The question is whether leadership will conduct it.

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.