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.
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.
Cutting wages is legally problematic in many jurisdictions, but certainly there's a case for reducing bonus payments by the reward amount paid to others if your code was later found to be at fault and it looked like negligence that caused it. Obviously, you'd need to be very careful here otherwise people would push back on anything that generates data traffic just in case usage of that functionality grew later on.
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.
I agree, but having a cap that is "the lesser of 15% of your base salary or $50K per year" means that people are going to start trading authorship of the rewards when they're anywhere close to this.
Like others have said, I think this will also encourage not thinking about optimising running costs when working on a feature - anything that does the job and doesn't seem outrageously expensive at first is fine. And then you wait until suddenly that service is costing a lot to run and pull the fix out of your back pocket.
Also, tying the reward to the savings quite so explicitly (and particularly having graduated levels) provides an incentive to ignore problems until it hits the next cost threshold. Even if you see the problem now, you might as well wait a year before reporting and fixing it, because then the bonus payout will be bigger. Also, then you're playing a game of chicken with other engineers who may also have noticed the problem but are also waiting for the best time.
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.
It might be a general priority of management but it's often a less salient issue day-to-day. Putting in such an incentive can be a good way to make sure it does get prioritized despite this.
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.
Cutting wages is legally problematic in many jurisdictions, but certainly there's a case for reducing bonus payments by the reward amount paid to others if your code was later found to be at fault and it looked like negligence that caused it. Obviously, you'd need to be very careful here otherwise people would push back on anything that generates data traffic just in case usage of that functionality grew later on.
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.
I agree, but having a cap that is "the lesser of 15% of your base salary or $50K per year" means that people are going to start trading authorship of the rewards when they're anywhere close to this.
Like others have said, I think this will also encourage not thinking about optimising running costs when working on a feature - anything that does the job and doesn't seem outrageously expensive at first is fine. And then you wait until suddenly that service is costing a lot to run and pull the fix out of your back pocket.
Also, tying the reward to the savings quite so explicitly (and particularly having graduated levels) provides an incentive to ignore problems until it hits the next cost threshold. Even if you see the problem now, you might as well wait a year before reporting and fixing it, because then the bonus payout will be bigger. Also, then you're playing a game of chicken with other engineers who may also have noticed the problem but are also waiting for the best time.
There is plenty of research that shows these sort of reward schemes are counterproductive.
oh really? could you point me to some examples? And what do you think would work better?
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.
It might be a general priority of management but it's often a less salient issue day-to-day. Putting in such an incentive can be a good way to make sure it does get prioritized despite this.
[dead]