There are specific topics that will get CIO and IT leaders to vent. Talk about show many spreadsheets bounce around through email, midyear budget cuts, or hundreds of projects everyone won’t prioritize, and you’ll get an earful. But there’s one topic that will get them out of their seats and red in the face with anger.

That topic is technical debt.

Technical debt, oh my! For CIO leading transformation programs, technical debt represents the legacy ways of doing things and their underlying systems. Trying to improve user experiences, become more data-driven, migrate to the cloud, address security risk, increase the reliability of data integration workflows, improve data quality, or pretty much any major upgrade is slowed down by the weight of technical debt.

There are a few reasons. First, there’s technical debt and legacy systems they inherited and now must maintain and support. So, that’s an easy target, especially if it’s a mission-critical system that’s been customized over the years, sitting on dated hardware without a reliable disaster recovery system. In other words, most ERPs that haven’t found their way to the cloud.

Another source of frustration is just how hard it is to get the funding, technology team resources, and business stakeholders to prioritize upgrades. Some technologies come up every year during the budget season or when the PMO reviews new initiatives, but never get the priority. That frustration goes to anger every time the system has a major outage, and the CIO now must be on bridge calls, join war rooms, console IT employees that lost their weekends over the issue, and communicate with angry business users. Yeah, that sounds like fun.

Lastly, there’s the technical debt we continue to create. For every hundred lines of code added, I’m willing to wager there’s at least 30 percent of technical debt added. It’s not all about developers with lousy coding practices or cutting corners to make a deadline. That’s one source, but much of the technical debt comes from dependencies such as when system or library upgrades also require code changes. Or there’s just a new and better way of implementing a function, and so the legacy model is now technical debt. Or the business is now expanding usage beyond its original goals, and now factors limiting performance, scalability, user experience, and security are all blocked by technical debt.

So this is why I elected to dedicate Episode 10 of 5 Minutes with @NYIke on 5 ways to better manage technical debt.

Over the years, I’ve published several articles on technical debt:

• What are Seven Types of Big Data Debt
• 15 Reasons Why StarCIO Agile Planning Drives Results!
• How to Capture and Manage Technical Debt in Agile Development
• 5 best practices to measure and manage technical debt
• How to Get an Agile Product Owner to Pay for Technical Debt