A friend was telling me about her tribulations with an IT support desk, trying to get her new office printer to work.

She told a familiar story of the support desk person bombarding her with questions and advice which was either irrelevant or well beyond her knowledge as an averagely tech-savvy customer.

I did my best, nodding and tutting sympathetically in all the right places, until finally her frustrated cry of “Why do they have to make it all so complicated?”, awoke my inner IT Service Manager.

“The trouble is that, unfortunately, IT often is complicated,” I heard myself saying, and instantly wishing I hadn’t. Back came the reasonable and predictable riposte “But it’s IT’s job to make sure it isn’t complicated for us poor *%^&&s  using it!”

IT services aren’t unique in this. There are plenty of products and services, from cars to taxation, where we customers get frustrated by the mismatch between our desire for the thing just to work and the apparent expectation of some service people that we should be at least sufficiently interested in and knowledgeable about it for us to appreciate how expert they are.

IT just happens to be particularly vexing because we rely on it so much.

And IT is getting more complicated, not only as it grows ever more functionally rich; it’s the sheer number of separate components which have to play nicely together in order to sustain an IT service.

There are several possible strategies for dealing with this complexity.

I believe the ones which work best are the ones which recognise that complete control of all the tech is no longer an adequate model for IT service management, and that this needs a different mindset for IT and customers alike.

They are strategies which get us over our mutual expectation that IT should know everything about the technology. They go all the way to not feeling awkward about just “turning it off and on again”.

We expect our IT support people to know all the intimate details about every IT component, and to be able to fix them, yet it’s become virtually impossible for them to maintain complete expertise over such a diverse environment.

We need to get away from any perception that the IT people have all the answers and can provide a binary solution to all IT issues – it’s fixed or it’s broken.

Instead, it’s about successfully orchestrating and navigating through the complexities to continue delivering the service.

The old IT mindset is reflected in what I call the ‘King Cnut’ strategy. You mandate the service components to be used throughout the stack in your operation, thus keeping complete control.

I tried this strategy as a Desktop IT manager about 30 years ago, standing firm against the tide of heretics trying to pollute our pure Windows estate with their beastly Apple Macs. Needless to say, I soon ended up picking up my deckchair and running for the rocks.

I can’t believe any IT department would still be following this strategy, but if you find yourself in an organisation where you can’t get anything much done unless you’re on their premises using their IT kit, I’m prepared to be converted.

More constructive strategies include equipping your IT Service people as Information Ninjas, giving them access to the training and sources they need to hunt out solutions in areas where they lack direct specific technical expertise. I blogged about this a while back.

I did a tiny bit of Information Ninja’ing  on an IT consultancy assignment for a small business with no onsite IT support.

Being the only one in the office with ‘IT’ in my job title, I naturally became everyone’s first port of call for most IT issues, even though I was actually there to deliver their IT strategy.

I found I solved a surprising number of people’s problems just by Googling and applying what I found. I was quite open about it, and no-one seemed to mind; They didn’t care how much direct technical knowledge I had, as long as their problem got fixed.

I think applying a similarly open and less precious approach to our IT Service Desks is a big help in meeting the challenge of complexity.

Automation can help too, but I’ve banged on about that enough in other posts. Suffice to say that I’m convinced that AI and innovations like digital twins could have a big role in mitigating our ITSM complexity conundrums.

Finally, there’s supercharging your incident management approach.

As a service manager I always got the cold clammies early on in a major incident when a senior asked the inevitable question’When will this be fixed?’ It’s an entirely reasonable question, and one which can be impossible to answer when you don’t yet understand the nature of the incident.

Supercharging your incident management doesn’t stop people asking it, but it can help you to answer a slightly different question which the one senior management really care about, “When will this stop impacting my business?”

Incident management means, amongst other things, deploying workarounds, invoking system or manual backups, or even, perish the thought, simply switching it off and on again.

Strong incident management means making sure these options will work by planning them in advance and putting in place robust processes for them. That doesn’t just mean documenting them and getting people trained in them, it means finding a quiet time once a year or more and live testing the critters.

Having prepared and tested incident management solutions gives you a much better chance of answering those awkward questions credibly and confidently.

All this seems straightforward enough, but I think our established IT mindset can get in the way for IT and customers alike.

In a crisis, IT can all too easily get diverted from focusing on the critical business incident to trying to get straight to the root cause of the technical problem.

Equally, our customers can feel somehow a bit short-changed if their clever and highly-paid IT bods aren’t coming up with arcane and complicated solutions.

The Starship Enterprise was well-known for losing its warp drive at awkward moments. Scotty would look pained and tell Captain Kirk it was impossible to fix it in time to avoid falling into a black hole or getting nabbed by the Klingons, before miraculously delivering a solution in the nick of time.

Star Trek would have been much more boring if Scotty had simply come up with the same standard workround to be applied calmly and methodically each time it happened.

Captain Kirk would probably have started asking awkward questions in the Enterprise Engineering Steering Board about why they had a documented fallback for something that’s not supposed to go wrong in the first place.

This ‘complex problem = complex solution” mindset can also lead us to waste time and effort creating technically elegant backups and workarounds which might not even work when the brown stuff hits the fan.

Spending millions on a backup for a multi-billion operationally critical system may appear to make sense, but how confident can you be that it will happily pick up the reins instantly when your main system has suddenly died in the middle of handling 500,000 transactions a second, and half of those transactions are incomplete?

As technical gurus we’re supposed to be able to make that kind of thing work, yet sometimes now we reach such a point of complexity that we can no longer make the 100% guarantees needed.

I’ve been guilty of this mindset myself. One IT service manager I worked with had a policy that any significant changes made within 24 hours of the start of a major IT incident should be fallen back wherever possible.

Initially I resisted, arguing that we should only fall back if there was a clear causal link to the incident.

It took me a while to learn that, like a butterfly wing in Chaos theory, it was often the changes with no apparent connection to the incident which lay at its root.

Like most IT consumers, I have very little direct control over most components of my IT services, so my incident management approach is honed to perfection.

Right now, my broadband is driving me mad, in a third world problems take kind of way, because often I go to watch Netflix and instead I get the whirling red circle of doom and a message to the effect of “You know you need more than a bit of wet string to Netflix, dude???”

When this happens, I have the drill nailed – restart the Firestick, restart the router, and if all that fails, uninstall and reinstall the Netflix app. That usually sorts it, and if it doesn’t. I let my inner Luddite take over and I watch a DVD or read a book.

I could switch to problem management mode and fix the root cause by changing my broadband service, except my partner’s deadline chasing on a major online project, and it works okay for her during the day, so I’m not going to mess with it.

That’s pretty much the same approach I’d take if I was in proper IT Service Management, looking at the bigger picture and doing whatever it takes to get the business back in the shortest time, even if that means running the gauntlet of the ‘so, basically you just turned it off and on again’ gags afterwards.

We’ve come a long way in IT by having complete mastery over the technology. Both we and our customers need to recognise that there’s just too much technology out there, and too much of it is out of our direct control, for us to maintain that.

Perhaps we need to be less like Scotty the Engineer and more like Sulu the Helmsperson, skilfully navigating our businesses through the asteroid fields of third party IT, to boldly go where no IT service desk has gone before?

If we don’t, I fear our customers may be spending a lot more time listening to IT people proving they know what they’re talking about while their problem lies unfixed.