Service Management Isn’t One Job, It’s Two
Oftentimes it’s the every day things I do in my life that teach me about service management. So let me tell you what happened this time. I had to pick up a friend from the airport. Rather than just turn up at the designated arrival time, I was smart and tracked the flight on the web. I saw that the plane took off and set off towards us, then I saw it turn around, clearly lining up to land back at the airport it had just left. Weird, I know.
So, to try and find out what was happening, I searched the web for any reported emergencies. Didn’t find anything about that flight, got distracted (inevitably) and came across a pilot’s mantra for behaviour when things go wrong: aviate, navigate, communicate. To be done, strictly in that order. That sounds like good common-sense behaviour for a pilot in a tricky situation:
- Keep the plane alive
- Find out where you are, where you should be, and what you might hit nearby
- Tell others/ask for help
I think the same principle applies to anyone working on the front line with unexpected situations requiring skilled attention. That includes IT or any other kind of support engineer fixing something with potentially significant impact. Analogous versions should (and do) exist for any kind of first responder role. For the “firefighting” aspect of service management it is good, sound advice.
Maybe you’d like to suggest an equivalent mantra for ITSM. To get you started, here are a couple of my suggestions:
- Fix → Restore → Tell
or maybe - Understand → Repair/Replace → Inform
Delivering the Information Our Customers Need
Recently we’ve seen many examples of airlines failing on the communication aspect. On the one hand, I would’ve expected the air travel business to be familiar with the pilot’s aviate → navigate → communicate mantra, but, on the other hand, perhaps over dependence on it across the wider industry is a mistake.
Of course, this isn’t just a concern for airlines. Everyone in service management can learn by seeing the broad picture and thereby avoid the trap of focusing entirely on fixing what’s gone wrong, and missing out the responsibility to keep our customers, users, and other stakeholders informed!
The Duality in the Job
The best way I know to help get it right is to clearly see that there are actually two distinct roles required when something significant and unexpected happens:
- Keep things going, understand the situation, threats and risks, and react to them: the fire-fighting role
- Tell people what is happening and, more importantly, what will be the impact on them, what their options are and how they can, or even should, react in order to minimize damage to their services, desires, and needs: the communication role
These are two separate roles, requiring different skills and attitudes, and especially requiring different empathies and supporting knowledge.
We absolutely need to appreciate the firefighting aspect of service management, but we also need to remember the other as well. Our customers and users need to know what is going on. After all, they have their own services to deliver, commitments to honour, and their own customers to support.
The second role doesn’t usually appeal to the technically astute hands-on engineer, but without it, the impact of a technical failure can grow tenfold very quickly as the business doesn’t have the information it needs to minimize impact on the end-customers.
I’m not suggesting there is any simple rule about which of these roles is the more important, or should be better paid, or who should get the most resources. In fact I think they are questions that can only be answered in context for specific situations, or at least specific industries, services, customer groups, and so on.
What I am thinking though, is that by seeing it as two separate roles, we stand a chance of delivering a holistic service management performance. One that’s balanced between firefighting and customer support.
Similar to the familiar ITSM roles of customer and user, we might find one person responsible for both, but it’s important they are aware of the two roles needing attention, each requiring a different mindset.
Getting the Balance Right
Just like the airline situation, if we have, say, a second-line engineering background pervading our service management team, we’ll most likely fail on the need to keep our customers informed. This presents a real potential for repaired infrastructure but disillusioned and unhappy customers – and a risk of losing those customers.
And, of course, if we worry only about telling people things, to the extent that engineers don’t get the time, resource, and space from interruption that they need, then things won’t get fixed as quickly as they could and should.
This kind of balance might not be easy, but it is essential in order to deliver a complete service management responsibility. A key first step to achieving that balance is to ask yourself some questions:
- Do you primarily see service management as only one of these two roles, or if you see both is one more important to you?
- In which of them do your skills lie?
- Can you see who in your organization is responsible for each, and how well do they get on with each other?
If you don’t see both, is that because your organization sees one role as pre-eminent, perhaps driven by the background of your CIO or CEO? Or maybe they only address one role and don’t see the other at all?
This all matters because, for most organizations, if the two roles don’t have good respect and support for each other, the overall service will suffer.
Please share your thoughts on these two roles in the comments below.
