[Archelaos]

I think "cleaning up x" should just be handled as any other to-do-list item. That means evaluating its cost and benefits in context with the other items on the list. Then do what is on position one, then on position two, then on position three, ... Re-evaluate the list from time to time.

[wpietri]

Fine in theory, but often bad in practice, because in a lot of places prioritization is done by people with little or no technical background and lots of incentive to show progress.

There are a lot of ways to do this, but my general preference is a black budget plus explicit "credit card" usage. E.g., the team has high standards for any new feature work and quietly spends 15% of their time every week on continuous technical improvement. If the product manager wants to break the normal standards and take on technical debt (e.g., rush have feature X ready for trade show), then you break the work into "rush to add feature X" and "clean up feature X mess". The first gets done before the trade show, the second after.

And personally, if a product manager doesn't honor the deal, I say they get their credit card taken away for a while, because they've proven they can't be trusted to do right by the team and the company.

[Archelaos]

Actually, I have an explicit agreement that I can spent around 10% of my time on issues of my choice, without having to check with the management. And sometimes, for bigger refactoring work, I have negotiated explicit to-do-list items. On the other side, in the process of re-evaluating the to-dos, I myself often recommend to postpone refactoring when I see the need for implementing a certain feature fast or when I have the impression that the code quality is "good enough" for the moment. Since management trusts me that I can appreciate the business perspective as well, I actually have little trouble asserting myself when I think a particular refactoring issue should be prioritized.

So in my case, it works in practice.

[wpietri]

No, treating as "any other to-do list item" does not work fine in practice. And you know it, because you spend 10% of your time on work specifically kept out of the normal to-do list flow.

And I'm glad you have a very good relationship with your business stakeholders, but please recognize that's not the modal case, and that giving advice as if it were is going to be bad for people with other circumstances.