Actually, I didn’t intend that comment to be “as asshole as it may have sounded.” :-D When you have put together a team of people to help maintain a piece of old source-code (and this is virtually my entire experience) then one of the problems that you face is that “the source code ... basically all of it ... Sucks Large.” Yes, it does. And so, everyone wants to “fix it.” They have their own notions, and they are probably entirely accustomed to the idea that they simply have the liberty to exercise those notions to “fix it.” But to make the whole process actually move forward I think that you really do need to have a rigorous command-structure that stretches quite a bit higher-up than any individual software developer sees, or needs to see. However, this means that the individual programmers need to be made to realize that the hierarchy is there for a reason and that they need to follow it. This might be a very-new mode of thought to some of them.
There are, of course, strong egos at play here these are, after all, race horses but I did try to say in a later paragraph that my reasons were technical as well as political / HR. The opinion that “code is not being written as it should be” should be treated as valid, but scrupulously handled within the established process and never as an exception to it. Hence also my admonitions to stick strictly to tickets and not to add-in unrelated changes merely because you can’t stand the way that one particular thing smells. (It all smells ... that’s why we’re here.) Contribute to the process, move it forward, but voluntarily choose to assume that you have a narrow role in it unless otherwise stated. Believe it or not, others will appreciate you for doing that.
Seriously on a big project, you might, with the utter best of intentions and in what you thought to be your best (albeit, independent) judgment and (you assumed) discretion ... unintentionally create a Great Big Mess! Such that you would, of course, be horrified to learn that you had done so. Well, so it goes.