> Second, preventing or mitigating an incident early (even by just knowing the right feature flag to turn off) can save huge amounts of money: both immediate lost revenue during the incident and future lost revenue from customers who would have pulled their business or refused to sign pending contracts.

Not to be sarcastic but just to offer an observation: in a sufficiently large or bureaucratic organization, preventing an incident from happening can rarely get you any credit or visibility. Such achievement falls into the bucket of "what you're supposed to do". So, those who navigate company dynamics well would rather let the incident happen and then be loud on the follow-up action items. The trick is not to turn an incident into a diaster, so it's a dedicate act.

I learned this early in a conservative org. Preventing things is risky. Just keep the solution ready for when things go wrong because then you'll get approval.

The examples of high impact all seem like things unlikely to receive recognition.

If you save a sales deal, they'll cheer the sales staff. And pay them a commission, which you will receive no part of.

Also, disaster is a good signal to the higher ups that there are problems in your org. If you keep putting out every fire with heroics, your boss will know (maybe), but his boss's boss's boss will see that your org is doing great and everything is all code green.

If you let a few things burn down, your boss's boss's boss will notice the fire, and things may improve. It's perhaps the easiest way you have of communicating with them.

It’s about what people notice. In town governments I’ve heard of cutting popular programs that will provoke an outcry only to get credit for reinstating them, while possibly smuggling through other actions that are necessary but unpopular.

Many carears are made and bonuses paidout with heroesim trick.

Can't solve a problem that doesn't exist yet