—/ Thoughts
FinOps for Engineering Managers
Maximizing SaaS margins through architectural discipline. On cost observability, serverless vs. Kubernetes trade-offs, and the silent killers of SaaS margins.
An AI-led conversation — a format I chose to keep things honest and to the point.
In the current economic landscape, Engineering Managers are being asked to look beyond velocity and focus on unit economics. Why has FinOps become a core competency for EM roles in Nasdaq-listed SaaS companies and startups alike?
Because in SaaS, your infrastructure cost is not an "overhead" — it is your Cost of Goods Sold (COGS). For a public company, Gross Margin is a primary driver of valuation. If your engineering team builds a feature that scales horizontally but doubles your AWS bill without a proportional increase in revenue, you haven't built a feature; you've built a liability.
An EM today must treat "Cost" as a top-tier architectural constraint, right alongside Latency and Availability. In a startup, FinOps is about survival and runway; in an enterprise like Docebo, it's about efficiency at scale and protecting the bottom line.
Cost as a first-class constraint — not an afterthought. That's a mindset shift.
How do you bridge the gap between the Finance department's spreadsheets and the Engineering team's pull requests?
It starts with Cost Observability. You cannot optimize what you cannot see. We need to move away from the monthly "surprise" bill and integrate cost metrics directly into our developer dashboards.
Developers should see the cost impact of their architectural decisions in near real-time. If a developer optimizes a SQL query or a caching strategy, they should be able to see the downward trend in the cost graph. By tagging resources properly — by team, by service, or by customer — we turn a vague "Cloud Bill" into actionable "Unit Economics." This empowers teams to take ownership of their own "bin-packing" and resource allocation.
When choosing between Serverless and Kubernetes for a new SaaS service, how does the FinOps perspective influence the decision?
It's a trade-off between Granularity and Predictability. Serverless, like AWS Lambda, is the ultimate FinOps tool for early-stage startups or low-volume services. You pay exactly for what you use. It eliminates the "idle cost" of running servers that are doing nothing 90% of the time. However, at extreme scale, Serverless can become significantly more expensive than provisioned infrastructure.
Kubernetes, on the other hand, allows for better "bin-packing." You can squeeze multiple services onto the same compute nodes to maximize utilization. But K8s comes with a high "management tax" — you need engineers to maintain the cluster.
As an EM, my rule of thumb is: Start with Serverless to prove the product-market fit with zero idle cost. Once the traffic patterns become predictable and high-volume, migrate to a more managed, provisioned environment to optimize the margin.
Serverless to validate, provisioned to optimize. Clean framework.
What are the most common "silent killers" of SaaS margins that you've encountered?
There are three that I see repeatedly. First, Over-provisioning for "Just in Case" — engineers naturally fear downtime, so they provision 3x the capacity they actually need. Implementing robust Auto-scaling is the only cure for this.
Second, Data Transfer and Egress Fees — many teams ignore the cost of moving data between regions or out to the internet. An inefficient architectural design that bounces data across availability zones can quietly add thousands to a monthly bill.
Third, Orphaned Resources — in a fast-moving startup, we often spin up "Stage" or "Dev" environments and forget to tear them down. Without automated lifecycle policies, you end up paying for "zombie" databases and disks that no one is using.
"Zombie" databases. Every team has them and nobody talks about it.
For an EM looking to implement a FinOps culture today, what should be the first step?
Stop treating cost as a "Finance problem." Make it a "Definition of Done" requirement. A feature isn't done until its cost impact has been estimated and its resources have been properly tagged for tracking.
A feature isn't done until its cost impact has been estimated and its resources have been properly tagged for tracking.
When you align engineering incentives with the company's financial health, you stop building "cool" tech and start building "efficient" tech. That is the hallmark of a mature engineering organization.