At this year’s UK itSMF conference I’ll be presenting a session titled “Unhappy is the land that needs a hero”. If you think that IT service management (ITSM) is all about tools and processes, then you need to think again. The most overlooked area of ITSM is the one that’s about people. An organization that doesn’t get this aspect of service management right can pay a heavy price. So what sort of culture do you need to succeed as an IT organization, and what can you do to help create it (and avoid the curse of the IT hero)?
Almost every IT department that I’ve ever worked with has had a hero. You’ve probably met some of these heroes yourself. The hero is the one who fixes things when there’s a catastrophic failure that puts the whole business at risk. They have a perfect understanding of how all the bits of the IT solution fit together, and an uncanny ability to jump straight to the root cause of even the most obscure problem. Whenever IT’s in trouble the hero rides to the rescue, and solves the problem. Everyone praises them, and other technical people aspire to be like them.
Nobody stops to ask the fundamental questions about why the heroics were necessary in the first place.
In my session, I’ll discuss the attitudes, behaviour, and culture that result in the need for heroes in IT. I’ll tell stories about different types of hero, and how you can recognise them, and I’ll even tell you about the time I was one of them myself. I’ll explain how the hero culture invariably leads to more frequent IT failures, resulting in increased costs for both IT and their customers, and reduced customer satisfaction with IT. The first step towards fixing a hero culture is to recognise that you have one, and that this is not good for you or your customers.
What can you do to improve the IT hero culture?
Once you’ve recognized that your IT organization has a hero culture, and that it’s not that great for your business, what can you do about it? In my presentation I’m going to talk about several different approaches that you can adopt to help improve things. There are no quick fixes, but there are lots of different way to start improving:
- Managing technical debt. Gradually remove the legacy problems that might cause incidents. Technical debt accumulates every time you decide to accept something that isn’t quite right, and if you don’t manage it then it can get out of control. This can result in complex configurations that are difficult to understand, obscure error messages, inadequate documentation, and many other things that cause you to need a hero.
- Designing antifragile solutions. Create IT solutions that recover fast, ideally automatically, and regularly test your ability to recover. It’s not IT failures that cause problems for your customer, it’s the fact that it takes time to recover. Recovery can be difficult and may indeed require the services of a hero. But if you design a solution that recovers automatically from most failures, then you can deploy your hero’s excellent skills on something more valuable most of the time. For example they could help to design the recovery solution.
- Adopting a DevOps culture. Create teams that work across siloes and collaborate to solve problems. Organizational dependence on a single person, however heroic, is decidedly unwise, and collaborative ways of working can really help to reduce such dependency. Even if you don’t want to adopt the DevOps idea of frequent small releases to reduce the risk of failure, you can still take on ideas about collaboration across teams to reduce handovers, and to increase the availability of expert knowledge when and where it’s needed.
- Reward teams and quiet heroes. Make sure that you measure and encourage the behaviours you want. It’s easy to recognise the value that a hero provides, but can be much more difficult to recognise, encourage, and reward those people who work quietly but effectively, reducing risks and improving service quality. If you seriously want to reduce your need for heroics, then you need to think about how to measure and reward the right behaviors.
Although each of these approaches deserves its own presentation, I hope to give you enough insight into all of these ideas to get you thinking.
Find out more at ITSM16
If you’re attending the event (you can book your place here), then hopefully you’ll be able to attend my session – “Unhappy is the land that needs a hero” – where my three key takeaways for attendees are:
- Understanding the impact of a hero culture on IT and their customers.
- Being able to recognize the different types of hero
- Reviewing key ideas for how to start changing the culture to reduce the need for heroes.
Hopefully, I’ll see you at the conference.
Stuart Rance
Stuart Rance is a consultant, trainer, and author with an international reputation as an expert in ITSM and information security. He was a lead architect and lead editor for ITIL 4, and the lead author for RESILIA™: Cyber Resilience Best Practice. He writes blogs and white papers for many organizations, including his own website.
Stuart is a lead examiner for ITIL, chief examiner for RESILIA, and an instructor for ITIL, CISSP, and many other topics. He develops and delivers custom training courses, and delivers presentations on many topics, for events such as itSMF conferences and for private organizations.
In addition to his day job, he is also an ITSM.tools Associate Consultant.
