Leveraging Support

Clippy & Bill GatesI could have sworn that I have written about this before, but a search of my blog didn’t return anything. Oh well, if I did write about this, please point it out if you find it so I can see if my viewpoint has changed / wavered at all.

A common ‘trait’ (for lack of a better word) that I have come across in IT folks in the past is a hesitation to engage vendor support. I know I was guilty of this early on in my career, but now I definitely try to avoid this. So, what do I mean by this?

Say we have a support contract with vendor X, and I as your manager task you with upgrading the firmware on it, but you keep running into errors. For simplicity’s sake, let’s assume that these are software errors (e.g. no physical hardware issues). All too often I have seen techs throw time at the problem, chewing up a valuable resource (your time). This is crazy in cases where you have support contracts.

If you run into an issue, engage support – they are the subject matter experts, not you. If you are concerned about how long it may take to get a response, then open a ticket sooner, especially if it only takes 5 minutes. Worst case if you solve the problem before hearing back, then you can just close the ticket (or ideally review your solution with support). If you still have an issue, then you have at least been processed by the support queue.

‘No worries – I got it fixed’

If you do end up solving the issue, how do you know that your fix was a proper one? Let’s use a simple, and hopefully very unlikely example. Say you are receiving an error about a degraded disk array. You fiddle around with things, and you get rid of the warning. As it turns out, you removed a failed disk from the array and assigned a hot spare. This would get rid of the warning, but if you aren’t familiar with what you did, you won’t realize that you don’t have a hot spare anymore. Once again, an overly simple example and one that I hope I wouldn’t see I the wild.

But they cost too much

One argument that I have seen against support contracts is something along the lines of ‘we don’t contact support enough’. In this case, I would encourage you to look at a) how often you do contact support, and what the costs are, and b) how many times would you have contacted support if you could.

I ran into the above situation a few years back where we had a SAN running out of software support. At the time we could handle just about everything we needed to, so it didn’t seem like a big deal. Then we ran into trouble. After all was said and done, it turns out that we could have avoided some pretty big downtime by running a few commands, but we didn’t know. In this case, we couldn’t pay for incident-based support either.

Looking back, the cost of the extended support was fairly significant for us. It is hard to say if we actually lost that much in downtime, but it did prompt the issue. Because of that, now when we procure new hardware, we make sure that we have support on it for the expected life of the equipment in production (vs. a standard one or three year contract).

Fixing an issue vs. getting an issue fixed

Honestly, though, I think the most common reason why techs don’t engage support is because they don’t want to appear unknowledgeable. From the managerial standpoint, I don’t expect you to know everything all the time, but I expect you to get issues resolved when they are within your area of responsibility. If that means engaging support, then do it. If that means an added expense, find out how much, what’s the time frame, and will it solve the problem – if everything looks good, then do it.

tl;dr – if you have an issue within your area of responsibility, get it fixed. I don’t care if you fix it, or a support tech fixes it.

Leave a Reply