> The other way is to just go skunk and fix a problem. Then if the fix works and people appreciate it, you get more latitude the next time you want to fix something.

This might surprise you but people don't like you fixing their mess behind their back. They take it as personal insult. They correctly recognize that you think what they did is messy and bad and you fixing it looks to them like an attempt to dethrone them from whatever little position they have carved for themselves within the organization.

I'm not a fan of secret work like that. It can definitely depend on the size and composition of the team, though (and the size of the fix / improvement). Once a team gets sufficiently large, people going rogue with side projects like that can cause more harm than good, in my experience. Hurt feelings / resentment, because somebody else had already planned to fix that issue ("why didn't you just bring it up so we could discuss it first?"). It conflicts with some new feature another team is working on ("if we knew you were working on this, we would have done things differently; let us know next time"). Multiple people might decide to tackle the same problem concurrently, without knowing others are doing the same. You misunderstood something fundamental or lack some context that invalidates the entire solution that could have been cleared up by discussing it with the team first.

And then maybe the biggest problem is the whole "putting in extra voluntary work" thing. Higher risk of burnout because you're spinning too many side project plates. Either your main work gets impacted, you start putting in overtime, or management starts thinking they're not giving you enough work, if you have all this time to do side stuff.

The risk here is that your fix might significantly improve the code in some way but also introduce a new bug or break some obscure feature. As a dev you're always sticking your neck out when you improve code in ways that aren't directly tangible to users or management. Leadership & management need to buy into the concept that code cleanup and refactoring are necessary but always carry some risk.