Well refactoring should never be a ticket it self. It should be done in order to facilitate, even enable, the construction of a new feature. Perfomance should be a feature request, IMO. If the user can't use a feature, or se a result, due to performance, the should be requested by the PM it self, no? Reliability as well, should fall under the same logic.

The problem is that some refactors will languish eternally as they don’t serve an immediate feature goal or even a bug fix—even if taking on the abstract refactor work broadly enables whole sets of features and fixes to be done more effectively.

In my current work experience, this means having a fairly deep mental model of how a given refactor might impact various seemingly unrelated efforts, and knowing how and why to advocate for them. This advocacy doesn’t translate into a literal ticket (and that’s not how my team manages all work items and their prioritization), but it definitely translates into “I’ve identified a specific unit of work which doesn’t immediately serve these goals, but would broadly improve their velocity and success.”

Next to no one wants to hear that kind of advocacy, because their Babel Fish generally formulates it as “stop or slow immediate progress for abstract goal”. But that’s what the debt part of tech debt is: you have to sometimes prioritize getting out of your own way before you can move forward in any direction.

As far as performance as a feature and corresponding request, sometimes you need far too much technical detail to even know what to ask for. I’m saying this having just landed an optimization which completely obliterated the existing Y axis on one of our monitoring systems. There was some vague sense of where some of the optimization target might be, if users or even the team were able to make the connection. It took dedicated time just profiling a bunch of fixtures, without anything to go on besides “some stuff is slow, for example ___”, to understand the broader performance story which went well beyond known bottlenecks.

Part of being an engineer is, or at least should be, some freedom to dive in to make these kinds of connections independent of specific features and specific detailed feature requests (performance or otherwise). Even if the only “work product” is just a report on what you found, at least it might be cross-referenced for when it does correlate to specifically ordained work items.

My experience is that customers want features shipped yesterday and the critical bugs affecting them fixed asap. Companies want money to flow in and penalities not to kick in. Refactoring serves neither of these goals so it's rightfully in the middle of the pile with uncritical bugs and is done when there is time.

You described my situation exactly as it is. Is this a common case for product centric companies? Is it less prevalent in tech companies?

I'd say it's common for all companies that create software.

Didn’t your engineering team have and agreement with the product manager to devote a portion of resources to tasks added to the backlog by engineering such as technical debt? You need to find a balance between new features and bugs and improvements.

In my experience that is just extremely hard to do. It's usually better just to do refactoring outside of the whole sprint / backlog process.

Yeah it shouldn't be like that but in practice that's the only way it happens.