In my previous blog, I recounted how I had recently finished the book The Bassoon King by Rainn Wilson and how the ten life lessons or truths that he knows are “sure things” inspired me to think about my IT service management (ITSM) equivalents. That blog listed my first five sure things, which related to being a better ITSM leader, especially when starting to adopt ITSM within an organization.
Here I share my next five sure things – this time they are more personal in nature, they are more about you as an ITSM practitioner rather an ITSM leader, and are again a mix of my own, and industry, truths.
I recently finished the book The Bassoon King by Rainn Wilson. Wilson, best known for his portrayal of Dwight Schrute from the US version of The Office (and there’s no truth in the rumor that this character is based on me), devotes one chapter of his book to “10 Things I Know for Sure” in which he details for the reader the ten life lessons or “truths” that he knows are “sure things.” For example, treat people with kindness. After reading the chapter, I spent time reflecting on the ten things I know as “truths” as an IT service management (ITSM) practitioner and leader.
Here are my first five things (it was too much to put into one blog) that I think should be top of your list when thinking about your role as an ITSM leader, especially when starting to adopt ITSM within your organization. They’re a mix of my personal and industry truths that relate to bringing in ITSM into an organization.
It was over one hundred years ago that Taylorism, or scientific management, reached its peak of influence as the go-to management and organizational theory, with Frederick Taylor himself using a term that’s very familiar in today’s IT service management (ITSM) industry – “process management.”
One hundred years since that peak, ITIL and similar IT management frameworks are today’s embodiment of Taylorism, with their focus on efficiency of labor through division of labor and processes – where teams of people are organized into function-oriented units that are, in effect, a cog in a larger process wheel. A practical example would be a change management team as part of a larger ITSM operation.
For those of us in the IT service management (ITSM) space, DevOps appeared on our scene around five years ago. And at that time, to most in ITSM, DevOps was seen as an outsider pushing in to places it didn’t know enough about. Specifically, it seemed to be an entirely development-driven concept that suggested IT operations wasn’t actually needed – that getting development right meant NoOps was perfectly possible, where NoOps is “the concept that an IT environment can become so automated and abstracted from the underlying infrastructure that there is no need for a dedicated team to manage software in-house.”
In the absolute sense, this is perhaps even correct. If you could build an IT system that was perfect, in that it never failed, and is so flexible that it’s adaptable to every change in customer needs, environment, legislation, etc. – then surely all you need to do is build and test it, then let it go delivering the service without any need for tinkering, fixing, or updating.
If you’ve attended an ITIL Foundation course, you’ll remember learning about emergency changes, and the role of the ECAB – the emergency change advisory board. In many cases, the ECAB is presented as something of a “rubber stamp,” helping a change manager “cover their back” by getting an emergency action signed off by senior staff. What the relevant ITIL book (Service Transition) actually says is “Where CAB authorization is required, this will be provided by the emergency CAB (ECAB)” (do you think this would look good as a tattoo?).