I’ve looked at a lot of cloud cost management tools. Visibility platforms that aggregate your billing data and break it by service, team, and environment. Anomaly detection that alerts when something spikes unexpectedly. Rightsizing recommendations that tell you which instances are over-provisioned. They’re all useful in the same way that a good thermometer is useful — they help you understand what’s happening. But I’ve never seen a tool fix a cloud cost problem. I’ve only seen engineers fix cloud cost problems, and usually only when they understood the problem and cared about fixing it.
Early in my time at Capital One, one of the teams in my org got hit with a billing surprise that nobody saw coming — not because the engineers were careless, but because cost had never been part of how they thought about their work. The monitoring was fine. The engineers were capable. What was missing was a culture where cost was part of the job, not someone else’s quarterly problem. That gap was mine to close, and it pointed me toward something the tools couldn’t fix.
The organizations I’ve observed with genuinely good cloud economics share something that has nothing to do with their tooling. Their engineers think about cost while they’re writing code. Not obsessively, not in a way that slows down development or makes every PR a finance exercise — but as a normal part of technical reasoning, the same way they think about latency or failure modes or data integrity. Cost is a property of their systems, and they’re responsible for the properties of their systems.
That sounds simple. It’s not common. In most of the engineering orgs I’ve been part of or observed closely, cost lives primarily in the minds of the platform team or the FinOps function — not with the engineers making the architectural decisions that drive it. Good tooling doesn’t change that by default; it just makes the gap more visible.
The default in most engineering organizations is for cost to be someone else’s problem — the FinOps team’s problem, or the finance team’s problem, or leadership’s problem when the quarterly review comes around. Engineers get feedback on cost behavior months after the architectural decisions that created it, when the code is running in production and changing it requires actual effort. At that point you’re doing remediation, which is harder, slower, and less satisfying than doing it right the first time.
The cultural shift I’m describing means moving cost accountability upstream, into the engineering process rather than downstream in the review cycle. This has some practical components. It means engineering teams having visibility into the cost profile of their services — not the aggregate org bill, but their service, what it’s costing per unit of workload, what that number has been doing over time. It means cost being a normal part of design review, not a special gate you add for large projects. It means on-call engineers caring about unexpected cost behavior the same way they care about latency spikes, because both are signals that something unexpected is happening in the system.
The reason this is cultural and not just process is that process changes without cultural buy-in tend to produce compliance theater. You can add a cost review checkbox to your design doc template and watch every engineering team fill it in with two sentences and move on. What you actually want is engineers who are genuinely curious about the cost behavior of what they’re building — who, when they’re choosing between two architectural approaches, think to ask “what does each of these look like at 10x load, from a cost perspective?” Not because a process requires it, but because it’s part of how they think about building good systems.
Building that culture is slow work and it doesn’t start with tools. It starts with what gets talked about in planning and design reviews. It starts with whether engineering leadership visibly understands and cares about cost — because engineers read that signal. If the senior people in the organization treat cost as someone else’s domain, the message to the rest of the organization is clear: your job is features and reliability, cost is not your problem.
It also requires making cost visible in a way that’s actionable at the engineering level rather than the executive level. Telling a team their service represents 3% of the organizational cloud bill tells them almost nothing useful. Telling them their cost per transaction has increased 40% over the past two quarters, here’s where the growth is coming from, here are three recent changes that might have contributed — that’s information an engineer can act on.
The tools help with this. Good observability and attribution make the feedback loop faster and more legible. I’m not arguing against the tools. I’m arguing that the tools are infrastructure for the culture, not a substitute for it. You need both, and they’re not equivalent investments. The culture is harder to build and worth more in the long run.
The culture shift I’m describing doesn’t start with the engineers. It starts with whoever runs the engineering organization deciding, visibly, that cost is part of what good engineering looks like — and then making that real in what gets talked about in design reviews, what gets recognized in retrospectives, and what the senior people in the room are seen to care about. Engineers read those signals. If leadership treats cost as finance’s domain, the rest of the org will too.