First of all, what is technical debt?
Well, imagine I lose a bet, and I owe you a robot. That is a form of technical debt. But that’s not what we’re talking about.
The technical debt we’re talking about is basically anything in your company’s tech environment that needs to be fixed, updated, or replaced, but would be painful to do so – too much cost, time, or disruption – so it’s still there. It’s the IT equivalent to “deferred maintenance” on a house, like that leaky foundation the owner fully intends to fix, later… soon… next year.
In an ideal world, technical debt would be addressed before it becomes a problem. In the real world it tends to be addressed when (and because) it becomes a problem. Once it’s urgent, you find a way.
Of course, to even start addressing your tech debt you have to be aware of it. Business leaders may have a good understanding of what technical debt is, yet still not know how or where it’s affecting their company right now. Unfortunately, technical debt is often regarded as “small-picture” operational stuff, and that’s one reason it accumulates. Given finite resources, business priorities usually get more attention than operational priorities.
Tech debt: two buckets
So for starters, it’s helpful to look at tech debt as falling broadly into two buckets. Business leaders are usually aware of bucket #1 but not #2:
- “Front end” – This type of tech debt inflicts operational pain that everyone can see. It could be a faulty system for getting laptops to new employees, or an error-prone, manual accounting process, or some business platform that can’t scale. Anything that’s presenting a visible roadblock to business progress.
- “Back end” – This is the stuff that keeps IT people awake at night. Cracks in the dam that your end users have no knowledge of, yet. It could be an old server with no support contract, an inability to modify some critical-yet-ancient application, or a badly designed database that’s just going to get slower and slower.
Business leaders would be wise to make sure that a mechanism exists for regular dialog with the IT team for, well, for a lot of good reasons, but one of them being identification, documentation, and assessment of the above risk categories. Because, at the end of the day…
Technical debt is business risk!
There are times you have to take a step back to move forward. Fixing tech debt is a good practice partly because it almost always leads to implementing better business practices. On the flip side, the more your technical debt builds up, the more it introduces both security and operational risk:
- Security risk – because the longer an outdated system or process is in place, the more likely that it’s falling behind on security capabilities.
- Operational risk – because the longer an outdated system or process is in place, the more day-to-day operational roadblocks it will present, the greater the risk of downtime, errors, or data loss, and the more disruptive the eventual fix or replacement is going to be.
But my company is a startup – that means I don’t have any technical debt, right?
Sort of. It’s true that your startup probably doesn’t have “legacy systems” or processes that date back to the Eisenhower administration. BUT… this is important: the startup phase is a notorious breeding ground for future tech debt! What I mean is, If your team is slapping together bare-minimum IT systems just to get your operation off the ground, promising they’ll circle back and fix everything when things calm down… spoiler alert, things won’t calm down. You’ll only end up fixing these systems when they turn into problems later. For this reason, if you’re not building your “startup IT” on solid, scalable, best-practice foundations, today’s ad hoc startup IT has an uncanny habit of becoming tomorrow’s technical debt.
What are some common examples of technical debt?
- Using systems that are no longer suitable for the task, can’t scale, or can’t integrate – these are common issues that become apparent as companies grow
- Failure to adopt new technologies – Sometimes it’s not about what you’re doing, but what you’re not doing that your competitors are doing. This category existed before AI, but AI is the perfect example.
- Continuing to use “quick fix” or band-aid solutions indefinitely
- Continuing to use unpatched systems – “Patching” means applying vendor-supplied updates to fix bugs or security vulnerabilities.
- If you don’t patch a particular system – the longer it gets behind in its patching, the longer it will take to update, and the more likely that cumulative patches may introduce unexpected problems.
- If you can’t patch a particular system – for example, because it’s now “end of life” and no longer supported, or it’s dependent on some other system that’s incompatible with the patches – the system probably needs to be replaced.
- Continuing to use systems that were built on old platforms – this most often refers to custom applications, for example a 20-year-old home-grown business system developed in COBOL with poorly-written, undocumented code and lacking security. It’s a productivity roadblock, a support nightmare, and a security disaster waiting to happen. But… it does its job and would have to be completely rewritten!
And don’t forget business processes
Technical debt affects not only systems – it can also plague your processes and your data. Some examples:
- Processes that are manual but could (and should) be automated
- Data that is siloed but should be shared between systems
- Integrations that depend on clean, normalized, easily accessible data, but your data… isn’t
- Any process that’s not adequate to support your desired business capabilities
These are difficult problems because solving them usually means undertaking large projects. It’s human nature to postpone these because there are usually many more interesting and urgent issues that you want to apply your limited resources to.
How can a small company better keep track of, quantify, and prioritize their technical debt issues? Well this is where I mention I can help 🙂 There are ways to incorporate technical risks into your overall business risk management, and to structure your process for overseeing corporate projects and change, so at least your major “tech debt” issues have visibility, they don’t slip through the cracks, and are able to be addressed appropriately according to the level of risk.
