Community Champion
Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Categories: software
I thought I had written about this before, but I couldn’t find anything, so I figured I would tackle the topic – technical debt. We talk about debt on projects often in terms of how the project is being funded, but technical debt is different. It’s when you introduce a technical problem that will need to be resolved at some point in the future – debt that some other project or team is going to have to deal with (or maybe Phase 2 of your project). It’s where you make a short-term choice because it helps you in the moment, but it’s not the right strategic or longer term choice.
These are some ways that you could be creating technical debt.
Introducing manual processing
If your system expects users to do manual processing of data, such as receiving in paper forms when previously the submissions were digital, that’s technical debt. Especially with the march of AI, we are going to want to eliminate manual work, whether that’s reporting or data entry. And giving users processes and systems that are worse than what they previously had is never a good idea.Duplicating records
If your project duplicates data that is already in another system, that’s technical debt. You could/should be identifying which system holds the main record and linking back to that with system interfaces.Double keying for data entry is a similar thing – if you are expecting users to type the same information into two or more systems, that’s increasing the likelihood of user error. Eventually the smart product owner is going to want to automate the process or build an interface to pull the data.
Increasing support tickets
If your project has some kind of feature that you know has the potential to increase support tickets, that’s likely a sign that something will have to be fixed at a point in the future. For example, introducing an error message that people will call up about because it isn’t clear or because they can’t resolve it themselves. Or not being able to reset their own password and needing someone from tech support to do it for them.Parallel processing – 2 systems doing the same or similar things
This is a bit like duplicating records, but it’s more about what the systems actually do. For example, if you have two systems that process invoices, at some point in the future it would be smart to standardise the company on to one invoice handling system. Because otherwise you are paying for maintenance and user licences for two systems, including resourcing that work and having system administrators for each. That’s just not efficient, so think about whether your project introduces something similar to what you already have in place.Inefficient interfaces or integrations
Are you building system interfaces or integrating apps? Make sure you’re doing it in the most efficient way, or you’ll be back in a few months trying to unpick bad coding and streamlining it.Or more often than not, you won’t be back to fix that and your colleagues will live with the project’s bad choices for years. Sorting out a messy interface is never going to be top of the list for a strategic CIO, unfortunately.
Building on old versions that need (or will need) an upgrade
If your project relies on old tech, platforms that will be decommissioned or are slated for an upgrade, the chances are that someone will have to redo your work in the future to move it (or make it suitable for) the new version. Could you reorder projects so your initiative happens after that upgrade is done and you only have to do the work once?What else do you see in your organisation’s projects that you would classify as technical debt, and how do you get those items on the radar for management so they make the right choice?
Posted on: February 17, 2026 12:00 AM |
Permalink