Why an IT Hero Culture is Bad for Customers

Ironman hero
Share on facebook
Share on twitter
Share on linkedin

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?

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?

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 recognise 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.

Image Credit

Service Management and Security Management Consultant at Optimal Service Management Ltd.

Stuart Rance is a consultant, trainer, and author with an international reputation as an expert in ITSM and information security. He was an author for ITIL® Practitioner Guidance, the lead author of RESILIA™: Cyber Resilience Best Practice, and the author of ITIL Service Transition, 2011 edition. He writes blogs and white papers for many organizations, including his own website.

Stuart is an 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.

Want ITSM best practice and advice delivered directly to your inbox? Why not sign up for our newsletter? This way you won't miss any of the latest ITSM tips and tricks.

nl subscribe strip imgage

More Topics to Explore

One Response

Leave a Reply

Your email address will not be published. Required fields are marked *