Remember those miracles from the spring? The ones where teams stood up digital channels in days, migrated to remote work overnight, and duct-taped together solutions that kept the business running? Turns out that those miracles come with invoices. And they’re arriving now.
I’m not talking about cloud bills, although those are eye-popping too. I’m talking about the accumulated technical and organizational debt from nine months of just making it work. May shortcut showers become December liability flowers.
Variances of this scenario appear all over: an organization heroically built a customer self-service portal during the initial lockdown. It was clever. It was also built on a prototype framework, connected through spray-and-pray integration that worked most of the time, and secured with an authentication approach best described as “optimistic.” Suffice to say that as it scaled up, things didn’t exactly hold up.
The Debt You Can See
Some of this debt is obvious. It shows up in outages, slow performance, and security incidents. Like the SaaS tool that a department adopted in April on its metaphorical credit card, and now contains eight months of business-critical data that nobody can export. Or the API integrations that were hardcoded for a specific scenario and break every time something upstream changes.
This is the debt that gets attention because it hurts visibly. Executives understand outages. They understand security incidents. This debt gets funded, eventually, because the alternative is too painful.
The Debt You Can’t See
The invisible debt is quieter. It’s the kind that doesn’t cause outages. It causes friction that slows down the organization. Maybe the product team can’t build the next feature because the codebase from the spring has become unmaintainable. Every change risks breaking something, but nobody fully understands what, because the people who built it in a frenzy have moved on or burned out. Perhaps data that now flows through three different paths depending on when the integration was built and who built it. The reports don’t match, but everybody has learned to “adjust” the numbers manually. Somebody has a reconciliation spreadsheet. It’s always somebody.
Sometimes it’s process workarounds that became permanent without anyone deciding they should be. The manual step that was added in April because the system couldn’t handle an edge case. Nine months later, two people spend half their day on that manual step, and it’s now in the training materials for new hires.
This debt doesn’t announce itself. It compounds. Like real debt, the interest payments consume capacity that could be spent on new value.
Why Are We So Bad At Managing Debt?
Technical debt is certainly not a new concept. The term has been around since the early ’90s. Every technology leader is aware of it, yet, most organizations are terrible at managing it.
Part of the problem is visibility. Debt that lives in code, architecture, and process is invisible to the people who control budgets. You can’t put a screenshot of a poorly designed integration in a board presentation. “Trust me, it’s fragile” is not a compelling funding request. Fear, uncertainty, and doubt doesn’t always translate well.
The teams that created the debt during the crisis were rewarded for speed and deservedly so. They pulled off heroics when speed was the right call in March. But now it piled up. Nobody gets promoted for paying down technical debt. The reward system still favors new features, new capabilities, new shiny objects. Maintenance is career quicksand.
Part of the problem is language. When technologists say “technical debt,” business leaders hear “IT wants more money for stuff that doesn’t produce anything new.” We haven’t found the right way to explain that debt reduction is what enables the new stuff. It’s not optional.
A Pragmatic Approach
We start by making the post-COVID debt pile visible. You can’t prioritize what you can’t see. Create an inventory of the shortcuts taken during the crisis. No blame game, the decisions were right at the time, just to understand what being carried. Rate each item by risk and drag. Risk is the chance it breaks catastrophically. Drag is how much it slows you down every day. High risk should be fixed first, high drag soon after.
- Dedicate capacity on projects to chip away at it. You could plan debt reduction spikes, but I haven’t seen debt reduction programs be successful, they tend to turn a technical problem into a bureaucratic one. Instead, allocate a percentage of every team’s capacity to debt reduction. Twenty percent is a good starting point. Make it part of the regular rhythm, not a special initiative.
- Connect it to outcomes. Don’t pitch debt reduction as a technology hygiene exercise. Connect it to something the business cares about. “We need to refactor the integration layer” means nothing to a business sponsor. “We can’t launch the new partner channel until we stabilize the integration layer” is more likely to resonate.
- Track it. This sounds small, but it matters. If the only work that gets recognized is new features, that’s the only work people will want to do. Start acknowledging the teams that make the existing systems more reliable, more maintainable, more scalable. It’s not glamorous work, but it’s essential work. Like celebrating essential workers when the pandemic first hit.
Back to the Foundation
Now living with COVID seems to be the new normal, let’s take stock. Sure, the organization may have built an incredible shelter rapidly, but it’s based on a foundation designed for a garden shed. And now we have to live in it long-term. We’d better reinforce the foundation before it crumbles.
That’s the work of 2021, because the bill always comes. And newsflash, it’s not a cashless transaction. The only question is whether you pay it on your terms or on its terms.
