There’s a lot happening in the tech space right now that we could be discussing. And I’m well aware that it’s a mixed bag of positive, scary, productive, wrong, misguided and hopeful. (How much of each is still TBD. Thank you, current state of AI development.)
But as someone who’s worked in the technology space for a LONG time, there are few tech topics that truly light up my insides and make me come alive. So I was jazzed to see multiple people in my networks recently touch on one such idea: tech debt.
Tech debt? But that sounds so dry.
Conceded. It sure does.
But for those who don’t know, tech debt is the white whale for diligent, highly-organized systems pros everywhere. And while it rarely gets the attention or public discourse it deserves, it is nonetheless a pressing, relevant topic for lean, mission-driven organizations. Some could argue even more than AI.
Tech debt is the cost of
choosing the quicker, easier solution today
that will hamper you tomorrow.
Odds are you’ve experienced the consequence of tech debt at your organization, which can take many forms. Things like:
- Fields in your database that are no longer relevant
- Forms and webpages hidden on your website that no one uses
- An automation that used to be helpful, but now just creates digital noise
- Dashboards that no longer match how your org tracks its data
- Custom code that sits idle in your system, but references various elements
It could even be licenses or a subscription your org still pays for, that no one actually uses. You get my point.
The idea is that tech debt happens when teams make tech choices that don’t serve their long-term interests & sustainability, because they prioritize short-term gains.
Which is not always the ‘wrong’ choice, by the way. Sometimes the shortcut or bandaid makes sense, particularly in the impact space (when the cost of doing tech the “right” way is your org’s impact).
But so much tech debt happens accidentally. And the result is digital assets that no longer get any play at your org. They languish in your systems, occupy space and create drag within your platforms.
The impacts of tech debt are often a function of time. As orgs evolve, as process falls to the wayside and maintenance slips, features your org once sought become irrelevant. Users cease using them. If they’re lucky, they may even forget those features existed…unless their existence creates new problems down the road.
Because that’s the main risk. Too much tech debt in the wrong places can handicap an organization’s ability to deliver on their mission, work effectively and manage costs.
And much like traditional consumer debt, the longer you leave it alone, the harder it becomes to claw your way out of.
Who does tech debt actually impact?
Spoiler: everyone. But let’s go in order.
Tech debt tends to create the most headache for your techies, who are either tackling it head on OR have to build new features around it day-to-day. (By the way, it’s rare that anyone actually has time to tackle tech debt head on.)
But it can also create pain for your general users. This includes staff who are expected to perform tasks in your system, but get hampered by legacy functionality – like old fields or automations. At best, this causes confusion around how they should use your system. At its worst, it creates additional unnecessary work.
And let’s not forget leadership, because no one comes out of this unscathed. Even if your c-suite doesn’t touch your systems at all (so often the case with higher-ups), they still rely on the data those systems provide.
And as the drivers for tech progress at your org (put another way, they sign the checks), leaders also have a vested interest in spending “smart” on technology & ensuring staff optimize their time. Tech debt impedes all of this, acting like an invisible leech that drains the capacity and potential of what your technology tools can achieve.
So what can organizations do to mitigate?
Tech debt is a specter that looks and behaves very differently, depending on the org. Mission, staffing, tech capacity, project track record and future plans are some of the factors that determine how consequential tech debt is to your org’s bottom line.
Along with that, tech debt impacts change quickly. Abandoned features that weren’t a problem yesterday can easily present challenges today, like causing delays or even preventing you from launching altogether.
That’s why organizations with too much to do & not enough time are best served by taking a dual approach to tech debt: anticipating it for future projects, and addressing it for existing, high priority areas.
1) Consider the tech debt potential for all new projects
Even if you can’t clear all the existing drag, just remember that there’s always an opportunity to prevent new tech debt from ever accumulating.
When embarking on new projects, make tech debt consideration an explicit part of the scoping process.
Your tech peeps will have the best sense of what those tradeoffs could possibly look like, on a data and configuration level. But even if you’re not so technical, keep in mind that remnants of tech debt are usually the result of the following:
- The abandonment of a process or task, aided by specific tech
- Failure to maintain or upgrade tech, to the point where it becomes unusable
- Failure to update data in a timely or consistent manner, causing it to become stale
- Failure to sunset (clear out) tech that is no longer relevant to your team, causing it to occupy space
Therefore, the key to assessing the potential for new tech debt is to generally understand:
- How likely it is that your tech project endures. (Hint: tech sticks better when it produces tangible rewards, is properly rolled out to staff and carries some type of leadership mandate. Tools that are optional tend to masquerade as consensus & collaboration, but typically don’t stick.)
- The complexity of what you’re building vs what it costs to maintain. If the tech is more complicated than your team can handle, then you either need an outsourcing plan OR a simplification plan. Don’t assume your tech build is one-and-done, because so rarely is that true.
Note: if an external consultant is the one building your tech, this complexity question becomes especially crucial. You don’t want to be saddled with a solution that’s impossible to alter or maintain, simply because you didn’t take time to understand & weigh in on the general approach.
2) Identify your existing, high-priority areas
If you’ve ever fantasized about tackling a certain, massive tech debt relic in your org, then you are a true impact techie. And you probably have a well-organized closet too.
Most of us know that we will never achieve this level of downtime. Our orgs can’t afford it. But some debt screams louder than others. If auditing your entire system just isn’t an option, then focus on the tech debt that’s actively costing you in resources today. Or soon-ish.
When I say “resources”, this could be time and money. But more likely this will represent true technical resources, like usage or storage. For example:
- Your enterprise platform has an outdated integration that’s consuming limited daily API calls
- Your AI system is trained to process unnecessary amounts of information, which consumes your org’s tokens
- You’re on the verge of maxing out field limits for an object in your CRM.(Fun fact: this one is from personal experience. You know the tech debt is out of hand when your org is actually about to hit that 500-field Salesforce limit.)
Once you have your short list of tasks, slot those into your workplan as best you can. Figure out if you can dedicate a certain amount of time per week or month. Recruit a consultant or temporary hire if your org can swing it.
Tech debt that’s tackled gradually, or even partially, is still better than tech debt left entirely to rot your system.
And if feasible, consider leveraging that reparative work as a learning opportunity. For an intern eager to gain technical experience, or even someone on your team who’s interested in dealing more on the tech side, tech debt remediation can do double duty by helping your org’s stack AND helping folks develop their technical acumen. Win-win.
Just make sure to disaster-proof the cleanup process for them first.
Wrapping Up
Before we go back to the real world of everyone talking about AI (boo!), there’s one more important thing to understand about tech debt.
Unless your org has incredible resources – not just funds, but technical expertise + process expertise + project expertise + time – you will never be able to truly avoid tech debt.
Or, to put it another way that sounds more palatable. Your org can’t always prioritize enduring tech builds over expedient ones. That’s just the reality of delivering impact in an environment where resources are constrained. Tradeoffs have to be made.
But in order to be effective, orgs need to know how to decide when to make those calls. And the best way to practice is to make tech debt a regular, intentional and anticipatory part of the conversation. Don’t let it become the afterthought that it so often is, especially if you’re one of the orgs sprinting ahead with AI. (Tech debt is dysfunctional on its own. AI can easily amplify that.)
Leave a Reply