They have very little agency. Priorities are driven by OKR’s, which require measurability as one of the core tenants. If you want to accomplish something, you
must be able to point at a number somewhere, and have a plan to make it to up and to the right. Refactorings to pay down tech debt rarely can pass as OKR’s unless there is a true business need.
This is a feature, not a bug, as far as management is concerned. They’re often proud of saying things like “if you can’t measure it, it doesn’t exist.” There’s often managers that are very sympathetic to the idea of pushing for quality, but then they’ll ultimately say something like “but, if you can’t come up with a number to show benefit, perhaps it really isn’t worth pursuing ¯\_(ツ)_/¯” and we move on to the next feature.
The only way any real quality improvement happens, is if motivated individuals do the work basically on their own time. You will not get organizational support for it. If you’re lucky, it will pan out and an improvement will be made. If you’re not, maybe your refactoring causes a regression somewhere (nobody’s perfect!), someone notices, and if that person is particularly angry about it you’ll get yelled at for making “rogue changes” that cause bugs. If your rogue change was done in some other part of the codebase, you’ll probably have your access revoked (ie. others will be put on the approval chain to prevent you from making such changes again.)