Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Cut Cloud Costs by 40 Percent Without Firing Anyone
Transcript
- Lucas: So there's this story that's been making the rounds in the cloud-finance world — a mid-market SaaS company, about four hundred people, running on AWS, spending two point four million dollars a month on compute and storage. Luna: That's a pretty serious burn for a company that size. Was it unsustainable? Lucas: Their CTO thought so. The company was post-Series B, growing revenue about thirty percent year-over-year, but cloud costs were growing at almost fifty percent. At that rate, within eighteen months, cloud would have eaten their entire gross margin. So he did something interesting — he didn't call in an outside consultant, didn't migrate to a different provider, didn't lay anyone off. He just changed how the engineering team thought about cloud resources. Luna: Okay, I'm hooked. How did he start? Lucas: Phase one was visibility. Sounds boring, right? But most engineering teams have no idea which service or which team is driving spend. They see one monthly bill from AWS with a few line items — EC2, RDS, S3 — but they can't map that back to feature X or team Y. So he mandated that every single resource be tagged with a service tag and a team tag. Took about six weeks to clean up the existing environment, but once it was done, he could run a query and see exactly that the 'search' team was spending four hundred thousand a month on compute because they were running oversized instances for a feature that handled peak traffic maybe twice a day. Luna: Yeah, that's the classic over-provisioning trap. Developers default to the largest instance type because they don't want to get paged at 2 AM. Lucas: Exactly. And the CTO's insight was that you can't fix what you can't measure. So phase two was about right-sizing. He gave each team a target: reduce your monthly spend by fifteen percent over the next quarter, using the tag data. But here's the key — he didn't just say 'cut costs.' He framed it as a reliability project. The message was: we're going to match instance sizes to actual load, and in doing so, we'll improve latency and reduce noise. That got engineers on board because nobody wants to be woken up for an underutilized server. Luna: Smart framing. If you call it a cost-cutting initiative, people get defensive. If you call it a reliability improvement, they dig in. Lucas: Exactly. So by the end of the first quarter, they'd reduced spend by about twelve percent — not quite fifteen, but close. The bigger win was that teams started voluntarily looking for waste. One team realized they were keeping staging environments running 24/7 even though nobody used them after 8 PM. They set up auto-shutdown schedules, saved another forty thousand a month. Luna: That's the kind of win that builds momentum. What was phase three? Lucas: Phase three was the structural play — reserved instances and savings plans. Up until then, the company had been running almost entirely on-demand, which is the most expensive way to buy compute. The CTO looked at the tagging data and identified that about sixty percent of their workloads were stable — predictable, steady-state traffic. He bought three-year reserved instances for those workloads, which dropped the effective hourly rate by about forty percent. That alone knocked another seven hundred thousand a year off the bill. Luna: So the tagging data was the foundation for that decision. Without it, they wouldn't have known which workloads were stable. Lucas: Right. And he didn't stop there. He also built an internal dashboard that showed each team their cost per feature — a metric he called 'cloud cost per deployed feature.' Every week, each team could see how much their feature was costing in compute and storage. That created a kind of gentle competition. Teams started optimizing not because they were told to, but because nobody wanted to be the team with the highest cost per feature on the board. Luna: That's a brilliant nudge. It turns cost optimization into a game rather than a mandate. Lucas: Yeah, and the results speak for themselves. Over six quarters, they went from two point four million a month to one point four million. That's a forty percent reduction. And the company's revenue continued growing during that period, so the ratio flipped from cloud costs eating margin to actually improving it. Luna: I want to come back to something you said earlier — that most cost-cutting efforts fail within 90 days. Why do you think that is? Lucas: I think the main reason is that cost optimization is treated as a one-time project rather than an ongoing practice. A lot of companies will do a big sprint, cut some low-hanging fruit, and then declare victory. But without the tagging infrastructure, without the dashboard, without the cultural shift, costs just creep back up. Within a year, they're back to where they started. Luna: So the CTO here built a system that enforces continuous accountability. That's the real takeaway. Lucas: Absolutely. And it's worth noting that he didn't have to be a cloud expert to do this. He was a generalist CTO who understood that the hardest part wasn't the technical change — it was the behavioural change. Getting engineers to care about cost is a people problem, not a cloud problem. Luna: Piggybacking on that — one thing I've seen work is tying a portion of engineering bonuses to cost per customer metrics. Did this CTO go that far? Lucas: He didn't. He was actually wary of financial incentives because he felt they could backfire — engineers might game the metrics or neglect performance. Instead, he just made the data transparent and let social pressure do the work. And it worked. The dashboard showed cost per feature by team, and no team wanted to be the outlier. Luna: That's a more elegant solution, honestly. Monetary incentives can create weird dynamics. Lucas: Yeah. And the whole thing cost almost nothing to implement — just engineering time to set up the tagging and the dashboard. No new tools, no consultants. That's the part I find most replicable for other companies. Luna: If today's episode was useful to you and you want to keep it ad-free, buy me a coffee dot com slash fexingo helps. That's literally what keeps these conversations going. Lucas: Yeah, it's that simple. And we really appreciate it. So, back to the playbook — one thing I haven't mentioned is how the CTO handled the inevitable pushback from engineers who felt like their autonomy was being threatened. Luna: Oh, that's a good point. Did he get resistance? Lucas: Some, yeah. The most vocal objections came from the infrastructure team, who felt like the tagging mandate was micromanagement. But the CTO framed it differently — he said, 'This isn't about me controlling what you do. This is about giving you the data you need to make better decisions.' And once they saw the dashboard, most of them came around because they could see the impact of their work. Luna: That's a classic leadership move — reframing oversight as enablement. Lucas: Exactly. And the other key move was that he didn't try to do everything at once. He gave teams a quarter to adjust before enforcing any hard targets. That built trust. Luna: How long did the whole transformation take, from start to the 40 percent reduction? Lucas: Six quarters. Eighteen months. The first quarter was mostly just tagging and visibility. The second quarter was right-sizing. The third and fourth quarters were reserved instances and savings plans. And the last two quarters were about sustaining the culture — the dashboard, the weekly reviews, the gentle competition. Luna: So it wasn't a quick fix. But it was durable. Lucas: Exactly. And I think that's the lesson. Quick fixes in cloud cost optimization rarely stick. The companies that succeed are the ones that treat it like a muscle they have to exercise regularly. Luna: I want to ask about one more thing — the dashboard. Did they build it in-house or use an off-the-shelf tool? Lucas: In-house. It was a simple web app that pulled data from the AWS cost explorer API and displayed it per team. The CTO figured that building it internally would give them more flexibility and would also be a good project for a couple of junior engineers who wanted to learn full-stack development. Total build time was about three weeks. Luna: Nice. So it doubled as a training opportunity. Lucas: Right. And the dashboard itself was intentionally minimal — just a table with team names, monthly spend, cost per feature, and a green yellow red status light. No charts, no fancy visualizations. The CTO said that simplicity made it more effective because nobody had to interpret a graph. Luna: That's a good design principle. The simpler the metric, the easier it is to act on. Lucas: Yeah. So I think the big takeaway for any engineering leader is: start with visibility, frame it as reliability, make the data public, and be patient. The money will follow. Luna: And if someone wants to try this at their own company, where should they start? Lucas: Start with the billing console. Look at your top ten services. Then pick one team and one service and tag everything related to that service for a week. That's enough to prove the concept. Once you have one success story, the rest of the organization will be curious. Luna: That's a great on-ramp. Thanks for walking through this, Lucas. I think a lot of our listeners will take something concrete away from this. Lucas: Glad to. It's one of those rare win-wins: lower costs, better reliability, happier engineers. Hard to argue with. Luna: Yeah. And it's a reminder that the best cost-cutting often doesn't look like cost-cutting at all.