Okay, so like many of you, my team's cloud bill was this scary, monolithic number we'd groan about every month. We had the usual dashboards, but they were ignored. The engineers saw cost optimization as a boring, punitive chore.
Then we had a wild idea: what if we made it a game?
We started by hooking up our cloud provider's billing data (via their API) to a simple internal web app. The core concept was a **public leaderboard**, but with a crucial twist: it wasn't about who spent the *least*. It was about who *saved the most* from their own previous baselines.
Here's how we set it up:
* **Teams as "Players":** Each engineering squad was a team.
* **Weekly "Score" Calculation:** We tracked their spend vs. their average spend from the previous 4 weeks. Percentage decrease = their score.
* **The "Moves":** Any action that reduced cost counted. This included:
* Deleting orphaned resources (big points early on!).
* Right-sizing underutilized instances.
* Committing to a schedule for non-prod environments.
* Switching storage tiers for old data.
* **The Reward:** Bragging rights, a silly trophy icon on the internal Slack, and a quarterly team lunch funded by... you guessed it, a portion of the actual savings.
The shift was almost immediate. Engineers started digging into their own services, competing to find waste. It went from "Ops' problem" to "our game." We even saw pull request comments like, "Hey, if we tweak this query, we could move from a 4x to a 2x and get 10 leaderboard points."
Our biggest win? One team refactored a batch job and cut its runtime by 60%, saving over $8k/month. They were heroes for a week 😄.
The tools we used were pretty basic: the cloud billing API, a bit of Python to crunch numbers, and a simple React frontend. You could do this with a spreadsheet and a Slack bot if you wanted. The magic wasn't in the tech stack; it was in framing the problem as a challenge instead of a scolding.
Has anyone else tried something similar? I'm curious what "moves" or rules you'd add to the game.
one stack at a time
Interesting idea, but I'm already cringing at the perverse incentives you're baking in. Tracking percentage saved from a rolling baseline just encourages teams to create artificial fat to trim later. What's to stop a squad from inflating their baseline for a few weeks by spinning up a bunch of nonsense workloads, then "saving" a heroic amount by turning them off and collecting their quarterly lunch? You've gamified the metric, not the actual, sustainable cost control.
And let's talk about that "any action that reduced cost counted" rule. That's a fast track to technical debt and hidden costs. Someone gets "big points" for deleting an "orphaned" disk, but six months from now, a critical, undocumented legacy process fails because that disk wasn't orphaned, it was a quarterly batch job's storage. The real cost of that incident won't appear on your fun leaderboard.
This feels like a short-term dopamine hit that distracts from the harder, more structural work of architectural review and resource planning. It's treating a symptom with a sugar pill.
Skeptic by default
You've raised valid concerns that are classic pitfalls in any gamification effort. The baseline gaming risk is real, and focusing purely on deletion actions can absolutely backfire.
Our approach counters the baseline inflation by using a fixed historical quarter for the baseline, not a rolling window. It's locked in, so you can't game future periods. On the deletion risk, we found the scoring needed a governance layer. Points are only awarded for resources tagged by the owning team, and deletions require a brief log entry in the ticket. It's not perfect, but it creates a traceable record.
The goal isn't to replace architectural reviews, but to build engagement that makes those deeper conversations easier to have.
The fixed baseline is a smart move, it cuts off the most obvious gaming loop. I'm curious about the log entry though, is it just a free-text field? Without a structured format, those entries might not be much help when you're trying to audit a year later. You could end up with "deleted old disk, seemed safe" which isn't exactly forensic.
grep is my friend.