Technical debt… It has many different definitions depending on which section of IT you work for.
However, in this article I’ll be using this definition:

In essence, if your company is swimming in technical debt, it’s because they have spent too much time putting bandaids in place to temporarily resolve things, rather than resolving them in a maintainable way.
And sadly those bandaids become long term more often than not, even though they were in no way designed to last that long. These patches often end up requiring additional patches on top of them, which only makes matters worse.

The entire Business Analyst role of IT is designed to best integrate new products into a working environment, to ensure there are minimal conflicts and to ensure items work to the standard set forth. These technical debt items greatly increase the complexity of the system as a whole causing significant risk that, when the evaluation of a new product is being considered, it may be tested against the temporary environment rather than the environment as designed. This then significantly increases the overall technical debt as you’re not only fixing the bandaid, but you’re also having to re-certify your production environment against a now “working as intended” solution.

Off the top of my head, I can’t think of an organization I’ve worked with that hasn’t had a significant amount of technical debt, and it causes issues far outside that of the technical aspect. The IT support teams, which are often already working with a minimal staff load, spent significant percentages of their time putting out fires as a result. The IT operations teams are also stuck in firefighting hell because one fix breaks another thing, and so on and so forth, which only serves to drastically limit the amount of hours that can be allocated to projects for the better of the organization as a whole.

Anyone who has worked in IT for any length of time has watched someone burnout from the role/job. Technical debt is a major contributing factor to this burnout, the stress levels it causes from yet another production outage, to yet another late night trying to fix an active exploit, to the on-call rotation that is almost a universal standard in this field because “you never know what may break when”. It all adds up, it erodes the concept of a work/life balance that is so essential for mental health, and given most organizations terrible documentation standards, every time someone burns out, a lot of the working knowledge of the environment walks out with them.

So what can be done? There are several best-practice items that are often overlooked by organizations in order to save on the ‘cost of IT’:

• Proper Development -> Testing -> UAT -> Production environment layout. I cannot stress enough how much this helps, because an upgrade of a system can be throughly tested by multiple levels of the organization. From the software developer (development), to the business analysts (testing), to the actual business units who are responsible for using this product on a day-to-day basis (UAT), you get many eyes looking at the system in many different ways, and the assumption level of the ‘way the product is used’ goes down drastically, thereby allowing for more issues to be discovered and resolve pre-production, which lowers downtime and odd behaviors once live.
• A complete Change Management workflow. This includes not only a deployment or change plan being presented to the business, but a proper testing cycle to make sure there are minimal unforseen issues during deployment/change, and a rollback plan should the deployment/change fail.

Both of these above items, at least in my experience, drastically reduce the overall technical debt levels, as time and care is taken at each step. But what it really comes down to is simple: Slow Down. It’s not even a complex thing, but this false sense of urgency that everything must be done yesterday is the reason for the lion share of this technical debt in the first place. Take the time, make well thought out steps, test those steps, then test them again with other people. What time you spend doing this will save you ten-fold later on down the line.

In the end, it comes down to that famous quote:

Take the time to consider if you should make these changes to your environment, are they really that necessary? Is there a better right fit for your organization that allows for a lower risk level? This needs to become a standard way of thinking, because the industry as a whole is burning out.