Day: November 21, 2020

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.

IT always feels a bit behind the corporate 8-ball when it comes to justifying costs. There’s two main factors for this – the first is that for almost all firms, IT represents the biggest pure overhead money suck (behind labor), with usually zero net income to show for it. Second, IT workers tend to make more money that other support group functionaries, from entry level to skilled labor.

So for 99% of firms, when the c-levels look at the balance sheets, the IT spend is just seen as a painful cost of doing business, with it appearing a bit like the Pentagon’s Black Ops budget – money going in without a good understanding of *what it all means*.

None of that is going to change anytime soon. But with Architects and Engineers – who live and die by exact hour calculations, meticulous details, and precise metrics regarding WIP and profitability – it’s an uncomfortable state. And the default reaction is to try and get IT metrics through a ticketing system.

There’s a bit of built-in conflict here; never, ever do the execs want to force users to open a ticket to get help – but at the same time, they want to see exactly how busy IT is – how responsive it is, how many tickets we did this year compared to last, and more importantly, do we really need that tech in Buffalo?

While this makes perfect sense on the surface, for Architects and Engineers, this is a trap. And here’s why.

1) It is not the statistic you should be caring about. It is very possible that your team does 1000 tickets a year, and the staff hates IT. You can do 900 tickets a year, and the staff loves IT. What is it you really want? Do you want IT to be perceived as responsive, supportive, with excellent customer service? If so, the number of tickets opened/closed will tell you absolutely nothing in that regard. What will? Customer surveys, annually/biannual/quarterly. Identify what the users think you’re doing right/doing wrong, and adjust accordingly.

2) Your IT staff will focus less on customer service, and more on ticket creation/closing. Once IT realizes that the metric leadership cares about is tickets, *that* becomes their focus. User wants a mouse? Ticket. Forgot the wifi password? Ticket. Is it ridiculous to imagine that if a tech knows they’re “short” that month on tickets, that they create some? We all know how police work with their ticket quotas. Is that really what you want IT focused on?

3) It’s a slippery slope. The next logical progression to this becomes the “you need to open a ticket” comment. The phrase users hate hearing. Once ticketing becomes the be-all, end-all, however, the mandatory ticket comment isn’t far behind, either by de facto or de jure.

And that’s not for design firms. Architects and Engineers are high-touch professions. You’re used to getting the same level of service you provide to your clients in turn. That means that the IT guy is sitting out on the floor with everyone else and not in a call center in India, which would be a hell of a lot cheaper. When you’re on a deadline and can’t save a file, you don’t want to talk to “Rick in Bangalore”, you want to talk to a guy you know, and you sure don’t want to have to open a ticket to talk to him.

Tickets have their place. In very large firms, when you have a team or staff who never leave their cubicle, whose only task is to churn through ticket after ticket remotely supporting users, it can help. But that just doesn’t exist in firms under several thousand staff. And it certainly isn’t conducive to providing the highest levels of customer service.

It’s easy to understand the desire to try and tie down some aspects of the ethereal IT spending pit. But it needs to happen in reverse. What do you truly want from your IT organization? And is that goal measured by how leadership and staff feel about IT, or about whether Sally opens 8 vs. 10 tickets in a day?

This week’s interview is with Gautam Shenoy, BIM Director with Steinberg Architects.