FinOps in DevOps: Are we finally ready to make cost trade-offs explicit instead of reactive?

[cto_michelle]

I’ve been thinking a lot about the shift happening in how we handle cloud costs, and I’m curious if others are seeing what I’m seeing.

The data point that stopped me in my tracks: 78% of FinOps practices now report into the CTO/CIO organization—up 18 percentage points from just three years ago. This isn’t just a reporting line change. This signals that FinOps is finally being treated as a technology capability tied to architecture and engineering decisions, not just quarterly budget cleanup by finance.

Where We’ve Been

When I joined my current company to lead our cloud migration in 2022, cost was “someone else’s problem.” Engineering optimized for velocity and reliability. Finance reacted to the AWS bill every quarter and asked us to “find savings.” The cycle repeated.

We’d get a Slack message: “Cloud costs up 40% last quarter, what happened?” And we’d scramble to explain: new product launch, increased usage, some inefficient queries we’re fixing. Then everyone moved on until the next quarter.

That reactive approach worked when cloud was 5% of our operating budget. It doesn’t work now.

The 2026 Reality

Here’s what changed:

AI costs are exploding. GPU usage, data pipeline processing, model inference—these aren’t just line items. They’re architectural decisions with 5-6 figure monthly implications. And AI cost management is now the #1 most desired FinOps skillset across organizations of all sizes. We went from 63% of companies managing AI costs to 98% in one year.

It’s not just cloud anymore. We’re managing SaaS costs (90% of orgs now vs 65% last year), software licensing (64%, up 15%), private cloud infrastructure (57%, up 18%), even data center costs (48%, up 12%). FinOps has become multi-technology financial management.

The measurement problem is real. Try attributing container costs across dynamic workloads in a multi-tenant environment. Good luck. The infrastructure we built for agility makes cost visibility incredibly hard.

Are We Ready for Explicit Trade-offs?

I think we’re moving beyond “find the obvious waste” (though there’s still plenty) into a more mature question: Can we make cost trade-offs explicit parts of our architecture and product decisions?

Here’s what that looks like in practice:

Build vs buy with real TCO analysis. Not after we’ve already built it—upfront, as part of the decision. “We could build this workflow engine, or we could use Temporal Cloud. Here’s the 18-month cost projection for both, including engineering time. Which trade-off do we want to make?”

Storage tier decisions based on data. An architect choosing between S3 Standard and Glacier based on actual cost models and retrieval patterns, not just “this seems cheaper.” The cost difference might be $8K/month—is the faster retrieval time worth it for this use case?

Feature scoping with infrastructure cost. Product team wants real-time analytics for a new dashboard. We model it: “Real-time will cost $20K/month in streaming infrastructure. Near-real-time (5-minute delay) costs $3K. What’s the user value difference?” That’s an explicit trade-off.

The Hard Questions I’m Wrestling With

1. How do you make cost visible without creating analysis paralysis?

I don’t want every PR to require a cost impact analysis. But I also don’t want surprise $50K bills because someone spun up a new service without thinking about it.

2. Who actually owns the trade-off decision?

Is it engineering (we understand the tech), product (we understand the user value), or finance (we understand the budget)? In practice, it has to be all three—but that’s hard to orchestrate.

3. What are the right metrics?

Cost per transaction? Cost per user? Cost per feature? Infrastructure cost as % of revenue? I’ve seen teams bikeshed over metrics while ignoring actual waste. And I’ve seen teams optimize the wrong metric and make things worse.

4. How do you avoid the “cheaper is always better” trap?

Sometimes the expensive option is the right one. Paying more for managed services might be cheaper than engineering time. Higher infrastructure costs might enable faster iteration. Cost-consciousness isn’t the same as cost-minimization.

What I’m Seeing Work

The teams that are doing this well have a few things in common:

• Cost visibility in the tools engineers already use. Not a separate dashboard they have to remember to check. Grafana, CI/CD pipelines, PR comments—put the cost data where decisions are being made.

• Cross-functional ownership. FinOps person + senior engineer + product lead pairing on architecture reviews. Not gates—collaboration.

• Culture that treats cost as a constraint, like security or performance. Not an afterthought. Not a punishment. A real constraint that shapes technical decisions.

But even with all that, it’s hard. The incentives aren’t always aligned. The tools aren’t always there. The organizational muscle memory defaults to “optimize later.”

Are we really ready to make cost trade-offs explicit instead of reactive? Or are we just saying we are while still reacting to bills every quarter?

I’d love to hear what’s working (or not working) for others. Especially if you’re in a different context—smaller company, different industry, earlier stage. Does this resonate, or am I overthinking this?

---

Sources that shaped my thinking: State of FinOps 2026, FinOps trends to watch, FinOps Foundation

[eng_director_luis]

This resonates deeply, Michelle. In financial services, we’ve always had explicit cost scrutiny because of regulatory oversight, but even with that forcing function, connecting architecture decisions to quarterly budget impact has been a massive cultural challenge.

The breakthrough for us came when we made cost visible in the same tools where engineers make decisions.

What Actually Worked: Cost Per Transaction in CI/CD

Here’s the concrete example: My team was running integration tests for every feature branch, 24/7. Totally normal DevOps practice, right? Except each test suite spun up a dozen microservices in our dev environment, hit real databases (anonymized data), and ran for 30-45 minutes.

We added a “cost per test run” metric directly into our CI/CD dashboard. Turns out, each feature branch was costing ~$12-15 per test cycle. Developers were kicking off 5-10 runs a day debugging flaky tests. Do the math: 40 engineers × average 6 test runs/day × $13 = $3,120/day, over $60K/month just in dev environment test costs.

The behavior change was immediate. Not because we told people to change. Because they could see it. Engineers started:

• Consolidating test runs
• Optimizing flaky tests instead of just re-running them
• Using local mocks for unit tests, reserving integration tests for pre-merge validation
• Questioning whether every PR needed the full suite

Within 6 weeks, we cut that cost by 65% while actually improving test reliability (fewer flaky tests meant more signal, less noise).

The Trust Problem with Finance

Here’s the part that surprised me: The biggest resistance came from our finance team, not engineering.

Finance was worried that if engineers saw cost data, they’d become slower making decisions—analysis paralysis, or endless debates about whether something was “worth it.” There was also this (unspoken but real) concern that engineers would game the metrics or hide costs.

What actually happened was the opposite. Engineers self-optimized because they had the context. They made faster decisions because they weren’t guessing. And the conversations with finance improved because we were speaking the same language—data, not excuses.

The trust issue goes both ways though. Engineering leadership has to trust that finance understands why some costs are investments (new product features, scaling for growth) vs waste (abandoned experiments, over-provisioned infrastructure).

My Question Back to You

You mentioned “cost visibility in the tools engineers already use.” I’m curious: How do you balance shift-left cost visibility with avoiding analysis paralysis?

In our case, we only instrumented the high-leverage decision points (CI/CD, architecture reviews, production deployments). We explicitly didn’t put cost data in every PR or Jira ticket because that felt like it would slow everything down.

But I wonder if we’re leaving opportunity on the table. Or if trying to make every decision cost-aware would actually backfire.

What’s your thinking on where to draw that line?

[product_david]

Coming at this from the product side, I think we need to reframe the whole conversation: Cost should be a first-class product constraint, just like performance, security, or user experience.

But in practice? That’s not how most product orgs operate. And frankly, both engineering and finance share blame for why.

The Disconnect I Keep Seeing

From the engineering side: I’ve sat in architecture reviews where engineers debate the “elegance” of a solution for 45 minutes without once mentioning cost. They’ll optimize for scalability we don’t need for 3 years. They’ll choose the technically interesting option over the boring-but-proven one. And then they’re surprised when finance pushes back on the infrastructure bill.

From the finance side: I’ve also been in budget meetings where finance demands “15% cost reduction across all cloud spend” without understanding that some of that spend is directly tied to revenue-generating features. Cut the wrong thing, and you’re not saving money—you’re losing customers.

Both sides treat cost as someone else’s problem until it becomes everyone’s crisis.

What’s Working for Us: Cost Estimates in Product Roadmap Items

At my current fintech startup, we changed our roadmap process. Every product initiative now includes an estimated infrastructure cost impact, right alongside estimated engineering time and user impact.

Here’s a real example from last quarter:

Feature request: Real-time fraud detection dashboard for enterprise customers

• User value: High (differentiator vs competitors, enterprise deal requirement)
• Engineering estimate: 6 weeks (2 engineers)
• Infrastructure cost: $15K/month (streaming data pipeline, ML inference, additional database tier)

That $15K/month number completely changed the conversation. Not in a bad way—in a clarifying way.

We asked: “If this feature helps close 2-3 enterprise deals at $50K+ ARR each, is $15K/month in infrastructure a good trade-off?” Answer: Yes, absolutely.

But we also asked: “Do we need real-time (sub-second), or would 5-minute delay work?” Turns out, for fraud detection, 5-minutes was fine. That version cost $4K/month. Boom—saved $11K/month before writing a single line of code.

That’s an explicit trade-off.

Pushing Back on “Cost Slows Velocity”

Michelle, you asked how to avoid analysis paralysis. Here’s my (maybe controversial) take:

The RIGHT cost conversations don’t slow velocity—they prevent wasted velocity.

I’ve seen teams sprint for 8 weeks building a feature that required expensive infrastructure, only to discover customers wouldn’t pay enough to justify it. That’s not velocity. That’s motion without progress.

If we’d had the cost conversation upfront—“This feature will cost $X in infrastructure, so we need $Y in customer revenue to justify it”—we could have either:

1. Scoped the feature differently (cheaper version)
2. Validated willingness-to-pay first (customer discovery)
3. Decided not to build it (kill it early, save 8 weeks)

All three options are faster than building something that gets shut down because the unit economics don’t work.

The Education Gap

Here’s where I need help from engineering leaders like you and Luis:

How do you educate product and business stakeholders on what’s actually expensive vs what just sounds expensive?

Example: Last month, our CEO heard “Kubernetes” in an all-hands and assumed it was costing us a fortune. Actual cost: $3K/month for our whole container orchestration, which is way cheaper than the alternatives.

Meanwhile, we had a “small data science experiment” running 24/7 on GPU instances costing $8K/month that no one outside of engineering knew about. It had been forgotten about for 5 months. $40K in wasted spend on something that sounded harmless.

Non-technical stakeholders don’t have the mental models to know what’s expensive. And honestly, a lot of engineers don’t either until they see the bill.

How do we build that literacy across the organization?

[vp_eng_keisha]

I love this discussion. Michelle, this is exactly the kind of organizational design challenge I’m wrestling with right now. We just created a “Platform Cost Engineer” role on my team—sitting between SRE and what a traditional FinOps person would do—and the whole process forced us to confront some uncomfortable truths about who actually owns cost optimization.

FinOps Can’t Be Bolted On

Here’s what I’ve learned: You can’t bolt FinOps onto an engineering org that doesn’t already have a culture of ownership and accountability. It just becomes another dashboard that people ignore.

At my edtech startup, we tried the “build a cost dashboard and hope people use it” approach first. Spoiler: they didn’t. Engineers were too busy shipping features. The dashboard was beautiful, had all the metrics, integrated with our cloud provider… and usage was basically zero.

So we tried something more controversial: We tied infrastructure cost efficiency to performance reviews.

Not in a punitive way—we weren’t docking people’s ratings for expensive decisions. But we added “cost awareness” as a competency in our engineering ladder. Senior engineers and above were expected to demonstrate understanding of the cost implications of their architectural choices.

Did it work? Yes. Did people like it? Mixed reactions.

The positive: Behavior changed fast. Senior engineers started asking FinOps questions in design reviews. Cost became part of the technical decision-making process, not an afterthought.

The negative: Some engineers felt like this was “finance creeping into engineering” or that we were prioritizing cost-cutting over innovation. We had to have a lot of 1:1 conversations about why this mattered.

The Equity Angle No One Talks About

Here’s something that’s been on my mind: Junior engineers often don’t have the context to make informed cost decisions, and that creates hidden barriers to their growth.

A senior engineer knows that spinning up a new RDS instance for a feature is expensive and maybe unnecessary (could use existing DB with better indexing). A junior engineer doesn’t know that—they just know they need persistent storage, and the quickest path is a new DB.

If we suddenly start evaluating people on cost awareness without giving them the tools and mentorship to develop that skill, we’re creating an unfair system that advantages people with more experience or access to information.

So part of our approach includes “Cost Office Hours”—twice a week, our Platform Cost Engineer + a senior engineer pair with teams on architecture reviews. It’s not a gate or approval process. It’s a learning opportunity. Junior engineers get to ask “dumb questions” about what things cost and why.

This is as much about building skills as it is about cutting costs.

Pushback on the “Explicit Trade-offs” Framing

Michelle, I want to gently challenge your framing. You asked: “Are we ready to make cost trade-offs explicit instead of reactive?”

Here’s my concern: “Explicit trade-offs” implies that all trade-offs are rational decisions made with complete information. But organizational politics and incentive structures often matter more than data.

Examples I’ve seen:

• A VP pushing their pet project forward despite terrible unit economics because they’ve already committed to the board
• Engineering choosing the new, shiny tech stack because it’s more fun to work on, then post-rationalizing it with cost justifications
• Finance approving budget for highly visible features (even if ROI is unclear) while blocking “boring” infrastructure investments that would save 10x the cost

The data might be explicit. The trade-offs are still political.

I’m not saying we shouldn’t try to make trade-offs explicit—we absolutely should. I’m saying we also need to acknowledge the organizational incentives that make “rational cost decisions” harder than they sound.

My Question for the Group

David brought up a great point about educating non-technical stakeholders on what’s expensive. I want to flip that:

Is FinOps becoming another “you need a dedicated team” problem that only well-funded companies can solve?

We’re a Series B startup. We can afford to hire a Platform Cost Engineer. But what about Series A companies? What about bootstrapped startups? Are they just supposed to figure this out with part-time attention from already-overloaded engineers?

The FinOps Foundation and all these tools and frameworks are great, but they assume a level of organizational maturity and resources that most companies don’t have.

How do we make cost-aware engineering accessible to teams that can’t hire specialists?

[maya_builds]

This conversation is hitting different for me because I’m coming at it from a totally different angle: our startup’s biggest cloud waste wasn’t technical—it was building features nobody wanted.

The Real Cost: Building the Wrong Thing

When my startup failed (B2B SaaS, shut down after 18 months), we did a post-mortem on where money went. Everyone expected the answer would be “overpaid engineers” or “expensive marketing.”

Nope. The biggest financial waste was cloud infrastructure for features we over-built and customers never used.

We’d optimized our Kubernetes setup. We’d right-sized our instances. We’d implemented auto-scaling. All the FinOps best practices, honestly. But we were efficiently running infrastructure for products that had zero product-market fit.

Example: We built a “real-time collaboration” feature because a couple of beta customers mentioned it in passing. We architected it for scale (WebSockets, Redis pub/sub, the whole thing). Infrastructure cost: ~$4K/month. Development cost: 8 weeks of engineering time.

Usage after launch? Maybe 3% of users tried it once. No one used it regularly.

That $4K/month sounds small compared to what Luis and David are talking about. But for a pre-revenue startup, that was real money. More importantly, those 8 engineering weeks could’ve been spent on features customers actually needed.

We made the cost explicit. We tracked it. We optimized it. But we were optimizing the wrong thing.

Cost as a Design Constraint (In a Good Way)

I agree with David—cost should be a first-class product constraint. But I’d add: just like design constraints, cost constraints can actually make you more creative, not less.

When I worked at bigger companies with “unlimited” (not really, but felt like it) infrastructure budget, teams would over-engineer solutions. Need to store some user preferences? Spin up a new database. Need to process some data? New Lambda function. It was easy and fast, but it created sprawl.

At my startup, where every dollar mattered, we got really good at finding the simplest solution. Can we use an existing database table instead of a new service? Can we batch process overnight instead of real-time?

Sometimes the constraint led to better architecture, not worse.

The Human Factor: Engineers Want to Learn

Here’s something Keisha touched on that I think is underappreciated: Developers, especially early-career ones, want to learn new technologies. And that’s often more expensive than boring-but-proven solutions.

This isn’t malicious. It’s human. If you’re a junior engineer and you get to choose between “implement this with boring old PostgreSQL” vs “try out this cool new distributed database everyone’s talking about,” the new thing is way more appealing. It’s more fun. It’s better for your resume. It’s more interesting to talk about.

But the new thing is usually more expensive (licensing, operational complexity, learning curve mistakes).

I don’t think the solution is to tell engineers “no new tech ever.” That kills innovation and morale. But maybe we need a concept like “learning budget” vs “production efficiency budget”?

Like: “We allocate $X/month for experimentation and learning new tech. If you want to try [shiny new database], that comes from the learning budget. If it proves valuable, we’ll move it to production budget. If not, we sunset it after 3 months.”

That way you’re explicit about the cost of learning and innovation, while still encouraging it.

My Question for Engineering Leaders

Michelle, Luis, Keisha—you all lead teams at different scales. Here’s what I’m curious about:

How do you balance “learning/innovation budget” with “production efficiency budget”?

Or to put it more bluntly: How do you let engineers experiment with new tech (which is often more expensive but necessary for growth and retention) while also keeping costs under control?

Because I think this tension is real. You can’t just optimize for cost—you’ll lose your best engineers to companies where they get to work on interesting problems with modern tools. But you also can’t ignore cost entirely—that’s how you end up with $50K/month bills for side projects nobody uses.

How do you navigate that as a leader?