Anti-Patterns in Tech Cost Management: Across the board cuts
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
One of the approaches I’ve seen to managing costs is the “across the board cut.” Like other “across the board” decisions that don’t take individual circumstances, contributions, and specific inefficiencies into consideration, this one is almost always wrong.
This kind of across-the-board target ignores those differences highlights that the decision makers don’t know where the costs/inefficiencies exist, or they don’t care and can’t be bothered to find out, or they would target their initiatives more precisely. Usually, they don’t come from a bad place. Typically, they result from changed business circumstances that demand greater attention to costs than had generally been paid in the past. However the key here is “generally.” As the Duckbill Group note in the quote above, no organization is completely consistent. Organizations with strong cost control will have teams that are doing it poorly. The reverse is true as well.
The damage done by these kinds of initiatives can be considerable. As Corey Quinn notes in the tweet on the slide, the implications of a fixed-percentage cost will vary considerably across teams. Often the justification for them is that everybody should experience similar pain, but since teams are rarely all starting from the same place, the pain they experience will vary widely. Furthermore, these initiatives will most severely punish those who have been doing the right thing and managing their costs well. When the directive hits, they will have less “fat” to cut and will likely be the first called out for their failure to meet the target. The teams that have allowed bloated infrastructure to remain will find it easy to cut quickly.
Over the long term, managements who attempt to solve problems in this way will create perverse incentives. I’m familiar with one company that consistently over the years would identify a need for costs cuts at a certain time of the year, tied into their earnings cycle. Everybody knew that if it was not a great year for revenue, there would be demands for 10-15% cuts ahead of earnings, sometimes accompanied by layoffs. The results were predictable: potential savings were “back pocketed” for future use; underperforming employees were allowed to hang around so they could be laid off when the timing demanded it. The overall cost structure was always too bloated.
In my experience, you can do this at most twice before everybody will catch on and start “banking” savings to use later, so you’ll always be too bloated. As I noted in the discussion of metrics, engineers are amazing at gaming numbers and will do so in ways that are hard to detect. In an extreme case, I know of one organization where some percentage of their compute capability was always busy calculating Pi to the millionth digit. It could be dialed down to meet the latest target, then slowly dialed back up. This isn’t how you want your engineering teams to work.
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.)