■ Problem: Cost recommendations arrive after deployment is done. 40% of FinOps practitioners named getting engineers to act as their biggest challenge.

■ Solution: Move the decision point toward design. The FinOps Foundation covers this area in its Architecting & Workload Placement capability.

■ Result: Less persuading. Cost gets discussed when there's the most room to change it.

A nightly batch job that ran fine in staging made the top line of the monthly cost report three weeks after it went to production. The instance type had been chosen at a design review two months earlier, and cost never came up in that meeting. Changing it now means scheduling a redeployment first.

Where Shift Left FinOps points

Shift Left FinOps means putting cost decisions next to the design, not the bill. It's less a brand-new concept than a name for a problem that keeps showing up in the same place.

In the FinOps Foundation's State of FinOps survey, 40% of respondents said their biggest challenge was getting engineers to act on cost optimization recommendations. In the same analysis, 52% were tackling it through culture and collaboration (FinOps Foundation, Encouraging Engineers to Take Action).

The recommendations arrive too late. A suggestion that shows up after the architecture is set and the deployment is done reads, to the person receiving it, as a request to undo finished work. Showing the numbers and deciding what to do with them are two different things, as we covered in an earlier post.

What gets decided at design time

In its 2026 Framework, the FinOps Foundation renamed the former Architecting for Cloud capability to Architecting & Workload Placement, and it now brings placement considerations into design and architecture before deployment commitments are made. The capability is about designing and modernizing solutions with cost awareness and efficiency to maximize business value.

The capability page also says this: "Value and cost efficiency is best achieved by architecting it into a system's design or as early in the life of a system as possible." (FinOps Foundation, Architecting & Workload Placement)

Instance family, region, storage tier, managed service or self-run. These choices sketch the outline of the bills for years to come. What you can do in operations is adjust inside that outline.

Moving from Crawl to Walk

The same page splits this capability's maturity into three levels.

• Crawl: placement follows default patterns and rules of thumb, without a documented trade-off model
• Walk: a documented model weighing cost, value, sovereignty, resilience and sustainability guides the decision
• Run: what was built is tracked against what was modeled, and the pattern library keeps improving

What separates Crawl from Walk is one document. A page that records which criteria you used and what you gave up. It's also something you can write before buying any new tool.

Back to that batch job. If the design review checklist had one line for "estimated monthly cost of this setup," there would be no redeployment two months later. Adding that line costs ten minutes of meeting time.

▶ Talk to OpsNow about your cloud costs

Frequently Asked Questions

Q. Isn't Shift Left FinOps just pushing cost responsibility onto engineers?

No. It puts cost information in front of engineers at the moment they make the decision. The FinOps Foundation describes the ideal as engineers seeing the expected cost of cloud resources as part of design and development work. It's about handing them the inputs for the call.

Q. How do we estimate cost at design time when we don't know the usage yet?

You're not trying to predict the exact amount. Comparing the relative size of two or three candidate setups is enough. The FinOps Foundation also suggests that testing in development environments can give early signals of cost changes.

Q. Where should we start?

The lightest starting point is adding a "cloud cost impact" line to your user story template or design review checklist. That's where the habit of treating cost as one of the constraints to optimize for begins.

Q. Does that mean optimization in operations is no longer needed?

It's still needed. It just works inside the outline drawn at design time. The two are a matter of order.