Have you ever gotten in trouble for not working on "ticket" items. There are some places that managers will jerk your leash for working "whatever you want".
I make it a point on our planning sessions and reserve a task here and there for things like this.
Or explicitly plan a task to be done in quick& dirty way and acknowledging we will another task to clean it up later.
Works great for me
At a previous startup we had “bug bash Fridays” where we would either let the devs find bug tickets in Jira that they wanted to fix or could self report problems that they had noticed. While most devs don’t seem to enjoy fixing bugs, this was shockingly well received and good for morale.
There are a lot of approaches to this. The way I'd approach something like this, is to find something fairly trivial and just do it. Then ask what you should do with it. I've always found starting a conversation about untracked, but completed useful, change and how to get it done "the right way".
I think the main reason why managers don't devote resources to fixing smaller tech-debt issues is that they can't correctly measure the value of such fixes or reason about them.
As an extreme example, the task of "Update the SSL certificate" is a low priority item that doesn't deliver any value, right up until about an hour before the certificate expires, at which point it suddenly becomes the highest priority task that everyone needs to drop all their other tasks for.
A slightly more realistic example would be the task of automating the certificate update process, or writing tests for that process, both of which might fail a short-sighted manager's heuristic of asking "Are there more important tasks right now?".
(Then, when something inevitably goes wrong due to the lack of automation or lack of testing, the manager blames whoever was supposed to be responsible for manually updating it, or blames the person who wrote the automation code but wasn't given the time to test it, while telling their own boss "There was nothing I could have done to prevent this!").
So, to align everyone's incentives, and make the problem less abstract, I propose the "jelly bean method". What this involves is having a jar of jelly beans, and whenever a manager tells you to ignore some technical debt to work on a "ticket" item instead, you should say "Sure thing, boss. That'll cost you 2 jelly beans". Then you take your jelly beans, and go work on the ticket, ignoring the tech-debt. However, when the next ticket estimation session happens, you bring with you the jar of jelly beans, and you weigh how full the jar now is, and use that as an inverse scale factor for all your estimates. For example, if the jar is half full, then you double all your estimates, and if it's a third full, then triple them.
Of course this isn't a scientifically rigorous methodology, and it won't make the estimates more accurate, but it should have the effect of making the manager and the team more aware of the long-term costs they are adding to the development process, which should make people less hasty to add tech-debt without accounting for it in some way. The system even allows for giving developers days or sprints where they can pay off the tech-debt: you just have to buy more jelly beans to fill up the jar a little. And even if the system doesn't have the desired effect and the level of tech-debt spirals out of control, at least you get to eat a few delicious jelly beans to take your mind off it.
Also, absence of problems isn’t a metric that leads to recognition from leadership (unless you’re inheriting a problem with the explicit mandate of fixing it). How do you attribute cause to the absence of problems? Would they have never existed anyways (in which case the opportunity cost was a bad decision)? Or do they not exist because of your efforts? It’s unfortunate, but the system doesn’t incentivize problem avoidance; only problem solving.
