Anti-Patterns in Tech Cost Management: Bonus! Don’t do rewards programs
Series Index
Introduction
Anti-Pattern 1: Not considering scale
Anti-Pattern 2: Bad cloud strategy
Anti-Pattern 3: Inability to assign/attribute costs
Anti-Pattern 4: No metrics or bad metrics
Anti-Pattern 5: Not designing it in
Anti-Pattern 6: Cost management as a standalone
Anti-Pattern 7/8: No ongoing reviews (current and potential)
Anti-Pattern 9: Across the board cuts
Anti-Pattern 10: “A tool will solve the problem!”
Anti-Pattern Bonus: Don’t do rewards programs!
A few thoughts: Three things you can do right now, for yourself and your team
Wrap up
This one is more of a rant than a real anti-pattern, but it has gotten some attention and I’ve at least heard it discussed. I first encountered it in the A Cloud Guru “AWS Cost Optimization Deep Dive” online course. For those of you unfamilar with them, A Cloud Guru were once a pretty good provider of AWS certification courses. Typically what they offered was far better than you could get from AWS or their “certified” providers. Then the founders sold the platform to Pluralsight and it’s declined into a bunch of enshittified “courses” that provide no useful information while appearing to have added so much.
[Note, not blaming the founders — a great bunch — for selling. I would have too. But Pluralsight’s “stewardship” defines the word “enshittification.”]
Anyway, the cost optimization deep dive is neither deep nor does it really get anywhere close to talking about real optimization work. But at one point, they do talk about how great it is to run rewards programs to compensate people for finding ways to reduce costs. Which on its own would not be terrible, but I’ve heard this idea thrown around in the wild as well, and it is a horrible thing to do.
Managing costs is your job!
Back to the definition at the start of the talk: engineering is where economics meets science. If you are an engineer, addressing costs responsibly is your job. Just like addressing bugs in software is your job. Certainly your ability to do both is something worthy of consideration when discussing your compensation and career progression, but you really don’t want to be giving people specific incentives around those things.
Remember what I said earlier about engineers being great at gaming metrics? Compensate people for bugs found, and they’ll surely make sure there are plenty of bugs to be found. Compensate people for cutting costs and they’ll surely figure out ways to inflate costs up front so as to be rewarded for cutting them later.
Even worse, I can come up with hundreds of ways to cut costs to generate a short term bonus for me while leaving the long-term impacts to somebody else. This is what my colleagues on Wall Street refer to with the acronym IBGYBG. It stands for “I’ll Be Gone, You’ll Be Gone.” I mean I can save a lot of money with a more “streamlined” backup strategy. Or by reducing redundancy and resilience. And if I know that I’m leaving right after that sweet reward comes my way, I can be pretty sure it will not happen while I’m there.
Seriously, it’s a dumb idea. Whoever is running the A Cloud Guru piece of Pluralsight was an idiot for putting it in the course, or really for allowing that entire pile of useless advice to be published as a course at all.
Just don’t do it.
There is still time to join us at the SoCal Linux Expo (SCaLE 21x) in Pasadena on March 14-17. My talk will be on Saturday the 16th. I will also be speaking at UpSCaLE on Friday night, and running the Observability track on Saturday and Sunday.
It’s $90 for four days of great content. (If you know me, ping me as I may have a few discount passes left.)