> developers find themselves having to write tests and fix bugs because the priorities of upper management didn't allow it

Well there's your problem. If fixing those bugs isn't aligned with the priorities of upper management then you are either working on unimportant bugs or your org is screwed. You going rogue certainly isn't the solution.

I see this a lot. Developers place their priorities and biases over actual business direction. And then feel shocked when they are told their contributions weren't impactful. I've shipped enough dead code that nobody really used but it checked a box on a sales call to know that quality software isn't always what we're selling.

The problem is dishonesty. I've never worked for a company that would at least admit "our primary focus is selling rather than software quality". I know it should be implied, but when work is advertised as "looking for ninja pro engineers dedicated to their craft to help build top notch software", no wonder people get misaligned on values.

Have you ever worked for a company that was faced with running out of money? Things get real pretty quick when you hear you only have X months of runway.

Then upper management needs to be forthright in their priorities. Have you ever worked somewhere that didn't tell their developers something like "we expect clean code and quality software"? I don't think I've heard of somewhere that owned up to the fact that their primary interest was to pump out software despite a lack of code maintainability. I'm sure that the teams that produce hot garbage for Oracle tell themselves that they care about code quality.

In that case, developers are expected to read between the lines, which is quite an antipattern in doing business with any company. If you're essentially being lied to, the deal can only get worse from there.

Developers having a level of autonomy to address problems is what you consider "going rogue"? I guess it looks that way if I squint, but if developers can't decide on their own to address problems, that's not somewhere anyone should want to work. I wouldn't even want to be the slavedriver who sees their developers who are solving legitimate problems as escaping the plantation. A good manager should, rather than see this behavior as rogue, try to work it in to the existing process. A healthy development cycle should allow developers to allot a level of time or effort to address issues, and even junior developers can know better what needs to be addressed than someone who hardly touches the code.

You're right, going rogue isn't the solution; it's a sign that leaving the organization may be the solution.

There is a balance between the developer's priorities and that of the business. A business that doesn't care about a developer's judgment is totally myopic and self-deluded into thinking that it knows best about the nuanced facets of its operation. Concurrently, developers have been paid to do a job, and if they divert too much from what that job is, that can be doing wrong to the hand that's feeding them. Yet, if they are being set up to fail by the company(e.g. insufficient time allotted to maintenance), they are faced with the choice to "go rogue" in an attempt to save themselves and perhaps the company if they can see a rude awakening up ahead. As much as you may see this as transgression, this kind of situation is ultimately set up by the employer and they are solely responsible. We're not talking about employees doing their own side projects on the company time; they may literally be trying to save the company from itself.

Employees are going to going to exert some form of autonomy even when it's not granted to them. Those who are in positions of power can choose to harness that initiative instead of viewing it as a threat.