I take this even further. I think all maintenance should be framed by the business as: >What ideas do you have about how the solutions to these specific bugs/t

I take this even further. I think all maintenance should be framed by the business as: >What ideas do you have about how the solutions to these specific bugs/tickets/requests can simultaneously improve the existing system, even in ways unrelated to the specifics of the bugs/tickets/requests. How can we give business priority to those ideas? The difference is that if you challenge someone to not just meet a minimal set of criteria to "solve" a bug/ticket/request, but to use their wits to go further and not just solve it, but solve it in a way that creatively improves things around it too, then they'll be way more engaged. Almost all studies on this sort of thing have shown that you get higher quality work, people work faster in this set up, and they generally report feeling satisfied about it. This was a big part of the book Peopleware, where it talks about how in software at least, the notion that you have to trade-off speed of implementation against quality of implementation is a total myth -- just not borne out of any data measuring task completion time, degree of spec completeness, and bugs. To me, things like Agile tend to get politicized in a company and then get misused, to the point where rote emphasis on minimally clearing tickets ruins any chance to let people be creative about how they solve maintenance issues. And at the end of the day, even if you have great system architects, usually it is the maintenance developers who have really seen the nitty gritty of the codebase and have the most intuition about good refactoring design choices.