Except then you can get your wrist slapped for starting work on a ticket without prioritization. A rigid enough process slowly kills everything.

But then if you cannot work on a ticket because of prio, you cannot either work without a ticket, isn't it? I thought the point here was doing work with or without a ticket.

Without a ticket, the only people who see that you're working on that thing are the engineers reviewing your code. At many companies, this creates a lot less friction.

To put it a different way: it's better to ask forgiveness than permission. Creating a ticket is like asking permission (as the project managers will see the ticket and start asking questions about why time is being spent on low-priority things). Just going ahead and pushing code is asking forgiveness - sure, someone might notice after the fact that you did some work that you weren't assigned to do, but by that point it will be considered irrelevant, as long as your other responsibilities were handled on-time.

If you've never worked at a company where these political games are necessary - count your lucky stars!

> If you've never worked at a company where these political games are necessary - count your lucky stars!

I've worked at several places that use Jira, and none of this stuff ever happened. I've helped make sure that's the case, of course, but I don't think I've had anyone I've worked with question an individual ticket's priority.

Still…

The adult thing (hard but responsible) to do, is to create a ticket, then allocate time for feelings of the manager.

(including cost-benefit ratio comparison between “this dealing with the manager” vs “fixed thing” might be tempting)