When we think of “Zen and the art of [insert punny or topical subject here],” it’s usually a (knowing or unknowing) reference to Robert M. Pirsig’s 1974 novel, Zen and the Art of Motorcycle Maintenance, or ZAMM (which, in turn, is a reference to Eugen Herrigel’s Zen in the Art of Archery). It’s a long slog of a book and (at its heart) is a discussion of the Metaphysics of Quality. I’ve read the book and enjoyed it immensely, but ponder how it became a bestselling book (more than five million copies sold worldwide). It might be an interesting study at some point (I question how many of those five million were read cover-to-cover), but… it’s not the reason for this blog post.
This blog post is serving as an introduction to (what I see as) an eventual series of posts discussing a form of Zen in IT support.
When he was writing the novel, Pirsig’s day job was as a technical writer of computer manuals. The inherent style of a technical writer is infused throughout the novel, making it immensely approachable for those of us who read or write technical documentation. It’s likely that’s why, as I was toying with ways to approach the true subject of this post, I found myself drawn to ZAMM to help me explain the art of IT support.
Like reading ZAMM, working in IT support can be a slog. This is true not only for the user, but also for the support staff.
The stress we have as users is clear: Humans like to be right, and we do not like to admit weakness. Doing so tends to induce stress. Thus, some users have trouble admitting when they need assistance. Many will admit they don’t know something, swallow their pride, and accept help. Some will enter the support transaction in a confrontational manner, immediately assuming the support provider is either at fault, beneath them, or both. And still others will simply wallow in whatever the issues are and never speak up, (or, when they do, it is too late to help, or the help comes at a much greater cost then it initially would have).
A person can be the most patient, knowledgeable, and capable tech available across the planet at that moment in time. Those qualities do not confer immunity to the stress of repetitive incidents and requests, or to the stress induced by an interaction with an automatically combative user or a user unable to grasp the simplest of concepts.
Within support we debate the question, “How do we better support our users?” to an almost mind-boggling and usually circular extent. We continually reinvent the wheel. Flowcharts are continually drawn, papers are presented at conferences on similar topics from conferences five years in the past, and then we repeat it all again.
Mainstream media and consumer advocacy groups hammer large organizations for long wait times, lack of empathy, and generally poor service. If a large service provider or manufacturer doesn’t have one of the top-notch support ratings, they will generally be seen as a greedy corporate monolith, solely interested in making money for its shareholders and kicking their customers to the corner as soon as the purchase is made.
Without quality the support staff and the users quickly find themselves at odds, antagonistic for innumerably inane reasons,… and burnt out.
We can debate what “quality” means for a long time (feel free to read ZAMM and, should we ever meet in the flesh, I’ll be happy to discuss the metaphysical meanings of “quality” with you over a pint (or five) of Guinness).
Within the context of IT support, I would argue that “quality” means something inherently holistic: A support structure designed to make it as easy as possible for the user to ask for assistance (while not feeling like a moron), for the staff to provide it (without coming across as pedantic twits with God-complexes), and for transferable knowledge to be exchanged easily.
The IT Infrastructure Library (ITIL) is a framework designed to align IT services with business needs. In my experience with it over the past decade, ITIL provides the baseline for the quality we’re looking to provide and our users desire. I’m not going to go into a discussion of ITIL in this post (it’s a very mature framework and that discussion is best saved for another day), but I am going to state (for user support) three of the major (user facing) portions of the framework are vital for the service provider to absorb: Incident Management (which brings Request Fulfillment along for the ride), Knowledge Management, and the Service Desk. Building those three areas allow all involved to reach a pseudo- (and very simplistic view of) Zen in IT (we can only allow for Zen in IT using ITIL, by the way… your mileage will vary, possibly horribly, if you attempt to apply any of ITIL to other areas of your life).
The aim is for support providers to be properly managing incidents and requests brought to them by their users, managing knowledge (both internally and externally), creating a true “service” desk (as opposed to a “help” desk), and (eventually) following the ITIL life cycle to its full extent. By implementing and absorbing these (not minuscule) things, it is possible to move beyond that level of the jaundiced eye of the customer and the burned-out, haughty nature of support and reach a higher level of interaction, satisfaction, and quality for everyone.Posted in: General