What makes a great IT support function? What are the pillars for an effective infrastructure? What is the key to building an efficient support team? We could talk about new technology, hardware or software, or it could be a new approach, digital transformation. But instead, how about we get back to basics and look at our Knowledgebase.
I daresay that documentation although much discussed is, more often than not, the most neglected aspect of many organisations’ repertoires. I believe it to be the absolute cornerstone of an effective IT support team, one that we should invest not only time, but effort, into building.
Knowledge is of no value unless it is used (and to be used it must be found!)
Many a day has been spent by Support Engineers all across the world trawling through NTFS directories so disorganised that they can only be described as resembling the Mines of Moria. You’ve been desperately scouring incorrectly named folders in a futile attempt to locate that mystical ‘How to Guide’ that you know will have all the answers you need.
You know that if you can just find that one illusive file then you’ll appease the now livid Director breathing down the phone. In a sweaty panic you (at last) find the document you were looking for. You fix the issue, apologise profusely and then, as your heart rate returns to normal, you promise yourself you’ll create a directory in which to place these wonderful tomes of knowledge, so as not to force any other poor soul to endure what you just did.
Yet you don’t. The next call comes in, a new urgent email arrives in the inbox. Whatever the reason, it just doesn’t happen, and you only think about it again the next time the sky is falling. Stupid I know, but I’m in no doubt that this scenario sounds very familiar to anyone who has had the misfortune of being in a similar situation.
For Knowledge To Be Power, Documentation Must be King
You see, documentation needs not only to be accurate, but also easy to locate. And here’s why:
By building and maintaining a strong Knowledgebase, be that for internal staff or for external clients, we allow new starters to be more autonomous. This allows managers to continue with BAU, instead of having to spend an entire week explaining how to change a helpdesk ticket from ‘waiting’ to ‘fixed’. By creating a centrally accessible Knowledgebase and allowing users to effectively fix, or at least attempt to fix, their own issues, we are free to focus on the more important aspects of our jobs.
To follow on slightly from the last point, we save time and money on support by empowering our clients with knowledge. We stop firefighting small issues, we let those fires put themselves out. Our IT team are now operating free from the shackles of numerous support calls a day to get printers added, eating away at their valuable support cache. They are now free to focus on their strategic plans, their infrastructure. They will invest in their future, to stabilise and to remain current; they will invest in themselves, and by proxy, the rest of the business.
By maintaining our Knowledgebase, we encourage education, not only amongst clients, but amongst our own support engineers. This allows more junior staff to feel comfortable in undertaking more advanced tasks, safe in the knowledge that they are being guided by accurate, intelligent, legible information; we promote the empowerment of engineers, as well as users.
By maintaining a solid Knowledgebase, we are essentially building our team from the ground up, with knowledge trickling down from the top. Whilst this may sound like a complete juxtapose, consider the idea that senior engineers continually educate more junior engineers by use of documentation, creating a constant progression. Junior engineers continually gain knowledge, allowing them to grow at a far faster rate, leaving senior engineers to focus on improving & implementing infrastructure and services, creating a cycle of education, growth and prosperity.
So, my advice is that, even when it may not be a priority, get your documentation in order. I can assure you that if there’s one thing I’ve learnt in my ten years of doing support, it’s that if I had had such an ethos or implementation way back when I started doing first line, I would’ve been way further ahead, way earlier, way faster– I suspect.
Written by Senan Capone, Support Escalations Engineer, Conosco