Doing nothing at work

A good honest approach is just to build a few complex but essential tools so that other engineers have to keep coming back to you. It's a good way to stay relevant. You become really good at identifying misuses of that particular tool and it makes you look way smarter than you are when you can identify bugs in other people's code in mere seconds. This tends to happen naturally as you become more familiar with all the common gotchas that people tend to run into when using your tool.

Ideally you want your tools to be reliable and useful but complex... That way, whenever other devs run into bugs while using your tool, they keep coming back to you and you can point out their mistakes. The mistakes must be almost always be on their side for the strategy to work; this is key. Your code has to be rock solid.

If they find a genuine bug in your code, hopefully a small edge case, you have to be very humble and apologetic about it and you should praise the developer in the team meeting for identifying this complex bug.

This approach is better than getting credit for fixing your own buggy code; that only works with management and junior devs but other senior engineers will hate you.

The approach of building complex but reliable tools gets you credit over and over (often much more than twice) and the approval you get from other devs eventually finds its way to managers' ears. Smart leaders know that this is a better signal than flashy demos.

The leaders who just dish out praise onto specific devs for producing prototypes quickly tend to learn their mistake sooner or later. Many young founders tend to go through this phase though when they praise superficialties.

Even when you can, you can't prove the impact. As a real example, our team has extensive presubmit infrastructure to catch and block some classes of configuration error that have caused customer data corruption in the past. There have been CLs which were caught by those presubmits and meant that we didn't have outages, but there's no dollar amount tied to an outage that didn't exist.

Meanwhile, team X did something similar that caused data corruption, had N customers affected for such a period of time, scrambled to root cause, roll back, and restore from backups, getting customers back up and online. Look how responsive and great they are!

The impact is how many outages overall. If you only prevent one outage then maybe it's not that meaningful.

Your last paragraph, your right that happens in the short term. In the long term those teams get reputations for being a shit show, there will be high turnover, good engineers won't transfer in, people's compentaencies start to get questioned, other teams will avoid working with that team and develop their own solutions, and higher up people will start to look at what's going on.