In my experience, all of this is a reflection of the work or team culture. You can replace the infra cost cutting with bug squashing and write the same article. As in, is the quality of the software something that the business cares about or not? I am not even sure if incentives are necessary if quality is a part of the culture and is the expectation.

In one gig I was on, the culture was all about features, features and more features. The CEO was pushing this culture hard and it showed. You can imagine the kind of product this resulted in. Huge amounts of technical debt, replicated functionality, a high bug count and very high staff turnover. The customers were not happy at all but he just didn't seem to understand or care.

Also, 7k for image storage is crazy.

Without a complementary policy to cut salaries for introducing inefficiencies, they just created the unbounded incentive for more inefficiencies that can lead to ever larger savings.

No one gets paid to not introduce inefficiencies, so this actually incentivizes sloppiness. You would need to introduce a post mortem process where the engineers who shipped the problem had to talk about what produced it and why in order to discourage it or something

I could very much see people becoming tribal, untrusting and uncollaborative due to not wanting to split the reward with others (or have it stolen altogether).

It seems to me that a profit sharing scheme would be more effective - everyone incentivized to reduce costs together. Then people would more freely share ideas and collaborate.

As a general concept, this seems fine, but in this case they seem to be paying people a cash reward for ignoring management priorities:

> The ticket sits in a backlog behind feature work because feature work has deadlines, stakeholders, and OKRs attached to it. Cost optimization has none of those things.

[dead]