A hot topic for sure, but this is a highly simplified view in my opinion. (remember too that everyone's experiences vary) >There are tools that can evaluate yo

A hot topic for sure, but this is a highly simplified view in my opinion. (remember too that everyone's experiences vary) >There are tools that can evaluate your existing software code and determine estimated levels of technical debt. If your IT department is not using this, force them to do it. If they can’t, hire someone who can Tools shouldn't be a requirement, a culture of open dialog should be. Your team knows where the risks are, make sure they are comfortable raising issues and are able to prioritize them AS A TEAM. >Lastly, now that you now about the silent killer, make sure that you adopt the software development practices necessary to insure that excellent code quality is baked into the product. Adopt BDD/TDD and Continuous Integration and Delivery. For my teams I like to put the CI foundations first instead of last. This lays the groundwork for TDD. Also understand that the dynamics of changing a team to BDD/TDD is a much larger undertaking ( with plenty of risks all in its own right ) and can take months of hard work and time investment. Setting up CI gets all the delivery roadblocks out in the open and enables the team to focus on repeat-ability and reliability. A simple accounting exercise in documenting all the instances of technical debt does nothing to directly resolve these issues and is a burden in its own right. While sometimes useful, it should be a living document and part of the teams process, not merely a one-and-done step. A wholly separate topic is explaining technical debt to business users who may not be truly familiar with SDLC.