Approximate time to read: 3 minutes
With nearly 30 years of experience working within support, I want to share a number of simple discoveries that I’ve made about how it can be improved.
So, let’s talk about how you can ensure that issues are resolved as swiftly as possible, without unnecessary interruption.
For this, I’m going to start off with a true story. A story of how major IT incidents were dealt with by my previous employers.
They’d get a lot of middle management in a room, replete with conference phone, and they would, without doubt, achieve nothing other than bother those people, still sat at their desks, who were attempting to actually fix the issue. They’d ring them up for updates or, worst still, make them come into the room, where they’d be grilled by everyone there. Most of those in the room wouldn’t be the most IT literate and would, for example, ask developers, who hadn’t yet been able to recreate the problem, exactly how long they’d take to fix it and get annoyed when they couldn’t give an accurate answer.
As an aside, they called that room “The War Room”, just to make it sound more important (and management used to have a regular get-together, which they called the “Star Chamber”. If you don’t know how inappropriate that is, please feel free to Google it).
Sadly, I was often roped into those meetings myself and, one time, it was on a Saturday, so was done entirely by phone. I was on it for 11 hours. 11 straight hours. In the end it was resolved by an engineer replacing a single ethernet cable in the back of a server. No-one on that call, myself included, helped resolve it.
There was also the time, when I worked for IBM, when, in the middle of a crisis, the 2 developers working on a fix were expected to attend a 10 minute meeting which occurred every 30 minutes. Meantime, I was tasked to produce a spreadsheet of exactly what the developers would be checking for – which I had to speak to them to compile (I didn’t).
Now, compare and contrast this with my work at Automattic, where a client reported an outage, which we immediately started looking at. They decided, internally, to have a video call, which they invited us to attend. But we declined it – instead we said we’d keep them up to date via the ticket that they’d raised in the first place. This ensured we were focused on the issue at hand and not distracted by side meetings.
The reality here is that this kind of meeting is a result of needing to be seen to be doing something and it’s endemic in many businesses, sadly.
Some think the solution to all of this is to get the right people in these meetings – those trying to fix it rather than those trying to manage around it. But how much advantage is there to taking these people away from their comfortable, desk environments and sticking them in a stuffy office, where they can be regularly interrupted? Or, in this case, having to worry about the discussion going on in a video call rather than getting their head down and resolving the actual problem in hand?
Let’s use a comparison. Your car has broken down and you take it to a garage. A mechanic gets to work on it – if needs be, he’ll get advice and/or help from colleagues. What doesn’t happen, is lots of garage managers get together to discuss how it can be fixed, regularly pulling the mechanic away from what’s he doing to explain things. The mechanic here is the expert and he’s left to get on with what he knows.
But there is a time when this does work – a deadlock. You have different parties involved and each is blaming the next. But in this case, no work is taking place – you need to get those parties together to work out exactly how to move it forward. Once that’s done, disband and let them get on with it.