FinOps for engineers: make cost a metric, not a meeting
The Lizrd team · · 2 min read
FinOps has a reputation problem with engineers. Too often it shows up as a monthly meeting where someone from finance shares a spreadsheet, asks why the bill went up, and everyone nods and moves on. Nothing ships. Next month, same meeting.
That’s not FinOps failing — it’s FinOps in the wrong shape. The version that works looks a lot more like how engineers already handle latency, error rates, and uptime.
Cost is just another signal
Engineers don’t manage latency in a monthly review. They instrument it, set expectations, and get told — in the flow of their work — when something regresses, with enough context to act.
Cost deserves the same treatment:
- Continuous, not periodic. A number you check once a month is a number you react to, late. A signal that’s always current is one you can act on early.
- Owned by the team. The people who can change a resource are the people who should see its cost. Finance shouldn’t be translating dashboards into tickets.
- Actionable, not abstract. “Spend is up 8%” is a meeting. “This node group is over-provisioned; here’s the diff” is a pull request.
The translation tax
The reason cost stays a meeting is the translation tax: turning a finance observation into an engineering change is slow, manual work. Someone has to figure out which resource, whether it’s safe, and how to change it — for every recommendation.
Kill that tax and the meeting disappears. When a recommendation arrives as a concrete change with the evidence and rollback attached, it competes on equal footing with any other ticket — and it can just get merged.
Where the tooling fits
This is the bar we hold Lizrd to: cost shows up as engineer-ready recommendations, each a specific fix rather than a category, and the realized savings are validated after the change lands. Finance and engineering finally read from the same page — because it’s the same page.
FinOps isn’t a meeting you attend. It’s a metric you engineer.