Every FinOps hire is a symptom. It means that at some point, probably across many points, a team built something without asking what it would cost to run at production scale. The FinOps practitioner exists to compensate for that gap after the fact. And after the fact is the most expensive time to fix anything in software.
This is not a criticism of FinOps practitioners. The people doing this work are genuinely good at what they do — cost allocation, reservation management, anomaly detection, chargeback modelling. These are real skills applied to real problems. But the discipline only exists because those problems were created upstream, and nobody stopped to ask the right question before the architecture was committed. That is where I have a problem.
Cost is a system requirement. It belongs in the design conversation alongside latency, availability, and security. If you would not accept “we’ll think about reliability later” as an answer in an architecture review, you should not accept “we’ll think about cost later” either. The two are the same type of deferral. One just produces incidents. The other produces invoices.
The structural analogy I keep coming back to: if a civil engineer submitted a bridge design without calculating material costs, we would not hire a specialist to “manage the material spend” after the bridge was built. We would ask why cost was not in the original design. We would treat it as an incomplete specification. Cloud architecture is the same. A design that does not model its running cost at production scale is an incomplete design. Full stop.
[DAN: Add a specific moment where you realised cost was not being considered at design time in an organisation you worked with — what triggered the realisation, and what it took to shift the culture. This personalises the argument and makes it credible rather than theoretical.]
The FinOps industry exists and will continue to exist because cost discipline in architecture is not universal, is not consistently taught, and is not enforced at the design gate in most organisations. That is a real problem, and FinOps is a real response to it. I understand why the discipline exists. I just do not think it is the right long-term answer. The right long-term answer is architects who treat cost as a first-class design constraint — who can say, in an architecture review, “this pattern will cost approximately X to run at this scale, and here are the trade-offs of the cheaper alternative.” That is a skill. It is learnable. And it is currently undervalued.
The goal is not a better FinOps practice. It is an architecture practice where FinOps is unnecessary.
