IME, it just becomes about: "I shouldn't have to do all this to make my one little change." You need the team on board that there could be unexpected slowdowns

IME, it just becomes about: "I shouldn't have to do all this to make my one little change." You need the team on board that there could be unexpected slowdowns, due to the scope of the work being greater (or I guess you can look at test coverage during planning stage). I've been on one team that had the philosophy: "if we touch a file, all the technical debt becomes the responsibility of the team implementing" Not to say it was perfect, because if people skip technical debt once, they're likely too again later. However, so many managers in some fields would get all wound up about the potential for "unexpected issues", that we lost site of the big picture. This is how change works efficiently. Since the work was organized by file it actually becomes common sense to make everything right in the file, including in some cases unrelated changes to meet static (lint) analysis (though of course this leads to even more testing work). If it was something small, it takes so much more effort to plan a cleanup story, and execute that. Additionally, it's highly likely to be de-prioritized. Basically you want to clear the sink after you start doing dishes.