Technology Debt in IT Operations

There’s a new buzzword making the rounds in appdev circles called “Technical Debt” – basically, the concept that as a project grows/changes, that there is effort required to manage all the implications of the change, and the longer you ignore that work, the more costly it is to correct down the road.

I’m not above plagiarizing (my Facebook page is basically a subReddit) – and I think there’s a corollary to be found when it comes to traditional IT Operations.

Flying Buttress is a consultancy. People don’t reach out to us when they think things are going great internally, that they have everything covered. We get contacted for three basic reasons:

1) Things are a mess, and they need help.

2) They have a ton of work to do, and not enough internal resources.

3) They want an outside ear and outside eyes to give a different perspective or to provide advice.

Personally, my favorite situations are the encounters of the first kind. If you work in IT, you know the satisfaction that comes when you’re able to see the results of your efforts in a tangible way. The mess-cleaning situations are like any other cleanup operation; there isn’t a lot of complexity – plan well, spend well, and put in a lot of elbow grease.

But over 20 years, when I’ve seen bad IT situations, it is usually because firms have accumulated too much technology debt. One of the main concepts of proper IT management is that it requires a constant annual spend. Major fluctuations, either upward or downward, can have severe long-term effects (i.e., dropping a huge amount of money to replace all the computers which means they all end-of-life at the same time rather than in a controlled, staggered manner).

In Architecture firms, my *very* loose rule of thumb is that the IT spend for a firm in standard, non-aggressive IT mode is about 6% of NSR (Net Service Revenue). As revenue goes up, projects come in, bodies get hired, spend goes up; and conversely, bodies lost means IT spend down. But if you start grossly cutting that into the 2-3-4% range, you start accumulating technology debt.

It is not an uncommon situation. Things get bad over time, so leadership goes out and says “hey, we’re in trouble, let’s spend a bunch of money and fix all this”. Consultants brought in, new hardware purchased, and yes, things get better. And soon – sooner than you might think – that need for a consistent annual maintenance spend is forgotten. There’s a “coasting” effect of that injection of equipment that doesn’t always speak to the multitude of components that comprise IT operations.

If you’re Leadership, and reading this – I’m not making this argument to get you to spend money. I’m making this to save you money. Because in IT, that technology debt doesn’t just have a hard-dollar connotation. You will lose far more money over time in outages, lost data, speed issues, and general productivity than you will that 5-6% of NSR. I’ve seen it.

Here’s the dumb car analogy. I’m the mechanic. I’m telling you you need to spend about $100 a year taking care of the various parts on your car. This amount varies based on how nice of a car you have. You tell me, well, I just spent $300 two years ago getting the brakes done. That’s great, but you still need your fan belt changed, wiper fluid, and your left taillight is out. You can pay me $100 a year now to make sure those are taken care of, or we can wait until you’re broken down on the freeway.

I am willing to have philosophical discussions about the relevance and importance of technology to Architecture, but I’m also able to just view it in cold black and white numbers. And technology debt – especially debt that can come due at the worst possible time – is just not good for business.