Prioritize, yes, but don't starve lesser priorities. Let individuals decide, say, 10%-20% of their effort spend and don't question it. That figure, conveniently, corresponds to the Friday they're spending not productively working anyway.
Prioritize, yes, but don't starve lesser priorities. Let individuals decide, say, 10%-20% of their effort spend and don't question it. That figure, conveniently, corresponds to the Friday they're spending not productively working anyway.
Maintenance is NEVER prioritized by anyone in management. They think "What, we put in the bug fixes, what more do you want!" but they never put in the "Hey, if we reorganize some code here, things will be a lot faster and easier to extend".
Devs on the ground can consistently see "Hey, this system right here, is a major issue that'll cause us a bunch of problems in the future" and that does not matter. Because, quantifying how much money is lost by not fixing the issue is really hard to do. You can't reliably say "If I spent 10 hours fixing this, I'd save 100 hours implementing new features".
It's this sort of short sighted vision that has dev teams running on 20 year old software with a bunch of known CVEs, handcuffed because the answer to "What will upgrading to the latest bring us?" is almost always "some bugs in transition but mostly piece of mind that we won't be vulnerable to a cyber attack."
Where it becomes more insidious is in planning for broader efforts, where even the ROI is nebulous. People seem hesitant to invest in experimenting to estimate ROI, which limits the topics and questions teams even bother to ask and gives a very skewed, short-sighted view to management.