A couple of strategies have worked for teams I lead. One is to simply let the system fester until it falls over due to the debt and causes a customer to compla

A couple of strategies have worked for teams I lead. One is to simply let the system fester until it falls over due to the debt and causes a customer to complain loudly, or if you have a competent Product owner/manager with your team she recognizes the need to pay it off before it becomes an issue. This is useful in an environment where product or sales want to deliver more quickly than good engineering allows. Note: document what is tech debt and why it exists as you build features. Make it clear while the features are built that the speed of development is not sustainable and use your documentation as support. Keep metrics (e.g. profile your code) and document how to make them better. You should know what is and isn't tech debt in this scenario. Document it so that you cover your butts and demonstrate the willingness to help the team achieve it's product or sales goals while you demonstrate the technical proficiency that gives non-technical folks confidence in your team. Another is to simply keep a well documented log of items that are recognized as technical debt after the fact. Along with this, document how paying the debt off benefits the business. In both cases perhaps the most important thing is this: build relationships with product, engineering leadership and sales to have the social capital to be heard and allow your technical competence to carry sufficient weight for getting time to work on debt.