Glitch! There’s a glitch in this or that or the other thing.
Throughout my years, I’ve been privy to technical support operations for a variety of systems. Now, as a leader of online education and learning management systems operations (among other systems) I hear the word glitch slung around liberally by support technicians. It makes my skin crawl thinking about what the user on the other end of the phone or email must be thinking. It has to be disheartening to be forced to use a system where glitches are the prevailing reason for error or dysfunction. Equally discouraging must be that users feel like these poorly supported systems have institutional backing.
Now, I’m not talking here about real systems problems. Those exist and get dealt with on a regular basis. I’m writing about the use of the word glitch to explain away problems so as to not deal with them. Glitch dismisses users concerns with an amorphous nondescript response. Glitch prevents systems improvement and updating. Glitch allows us to hold onto the old ways. Glitch does a myriad of other things that just equate to not doing our job in terms of adequate and professional support.
Glitches, like real problems that technology systems experience, demand that we as leaders and support professionals is to understand, address, and solve those problems head on. Not simply toss them into the pile of glitches that minimize our workload and irritate uses. When we needlessly glitch our way out of a problem we undermine our systems, ourselves, and our institutions. It is time we deal with the problem in a competent, professional, and supportive manner. Which is to say, not using glitch as a term of any meaning.
Glitch: An Etymology
I got wondering where does this word, glitch, come from anyway. It led me down an interesting intercultural path to discover that the word likely comes from the Yiddish word ‘Glitsh’ which means slippery place. The word was later part of the lexicon for radio broadcasters meaning some sort of error or guffaw on air. This evolved to the early days of the space program for a sudden voltage spike which caused errors in systems and hardware.
In the world around me, I hear glitch used to reduced systems performance issues and problems down in ways that pander to the end-users. It happens in institution-wide emails about real problems, “we’re experiencing a glitch”. It happens in support calls, “oh you won’t be able to do that because there’s a glitch” or “the system is glitchy today; try later”.
In terms of institutional systems, it is reductive and insulting to an end-user. Worse it undermines the whole system and institution.
Glitch as a Systems Confidence Issue
Consider for a moment a conversation I had recently where a faculty member expressed their disdain for a system my office manages the support and development but is housed in another office with decision making authority over the performance and investment. The discussion turned to a refusal to put much effort into advancing the use of the system. Can you imagine? I was taken aback by it but totally understood. This faculty member had been told the system was glitchy for years without seeing improvements made. After hearing that semi-semesterly slowdowns that bring the system to a crawl were glitches in the system for years. After hearing that he can’t do this or that or the other thing because of a glitch. After having his work erased or lost because of a glitch. Well, he just gave up. Who can blame him?
As a professional in support of teaching, learning, instructional technology, and online education, the conversation saddened me. To think, an intelligent person has last his faith, his trust, and his hope for a system that is plagued with discussions of glitching. I also completely empathized with him because the technical support teams are ingrained in a glitch culture to the point where they use it with each other and just go about their day. Even they, themselves, have lost confidence in the systems they support.
The lack of confidence does not end with system however. The conversation above expanded to questions of leadership, integrity, and the feelings of being abandoned by the organization in their plight for an improved system. This is likely the most dangerous aspect of losing confidence because of a glitch culture. It permeates the conversations and thinking about other areas of our work. If leadership can forsake us to glitches without making improvements, how can we expect them to not to forsake us in other critical areas?
This confidence shattering dialogue stemming from glitches extends to the eventuality that users of systems somehow deserve not to have these glitches fixed and develop costly (read: money and time) workarounds for things the systems would do it properly maintained and updated. Undermined confidence is a cancer inside and organization. Those support professionals that perpetuate the reductive and mythical glitch as their go-to explanation are only contributing to the problem.
Glitch as an Insult
I’ve worked in and around technology most of my career. I pride myself on being able to understand and relay complex information in ways that users can understand themselves. Yet I’ve also had the misfortune to work with technology professionals who prescribe to the “technology is magic and only wizards have magic” philosophy toward users. This mistaken belief system disables our support professionals from seeing users as equals which perpetuates more problems. So problems that are either really or perceived to be complex are reduced to glitch. Which really means – you won’t understand it. It might also mean – I don’t understand it (but that’s a post for another day).
Frankly, it is insulting to consider yourself an intelligent person and have someone dismiss your inquiry as a glitch. It sets the stage for people to believe one of two things.
- It is either a faulty system ~or~
- They aren’t smart enough to understand
In either case, the user is shutdown with this simple word, glitch. It is insulting.
Being a professional means boiling down your jargon and technical speak into easy-to-understand terms that accomplish the goals of easing the problem and building confidence. Something a glitch will never be able to do.
Fix the Glitch
In my conversations with and around technical support professionals, I hear about glitches a lot. I hear about them mostly in terms of not being able to do something or reverting to a cumbersome and outmoded method that ensures dependence on technicians versus teaching people how to use the tools of their profession. It saddens me to think that folks begin to become dependent on others to solve even minor problems without ever learning that there is an alternate reality in which they can feel confident in themselves, their tools, the systems, and their organization.
Just think for a minute if your faculty needed to rely on an electrician to flip on the lights in their classrooms because there was a glitch in making the light switch work once upon a time. Would that be something acceptable to the institution? The faculty? The students? No, it would not. Then why is it acceptable that we allow systems staff to foster a culture of false dependence under the the banner of a glitch. It is not. So how how can we fix this glitch culture and foster one that is confident both in the systems we use and how we use them? Let’s explore.
Ditch the Glitch
As leaders we must exemplify that using a glitch to explain problems to users is detrimental to our success. For the reasons I outline above, and more, we need to remove such laziness and dismissive dialogue from our support conversations. It erodes confidence in our systems and by extension in our teams and organization. Overcoming this erosion in confidence makes any future improvements more difficult, which further facilitates the error of the glitch culture.
Conduct support training focusing on customer service. I recently began a book club using Ken Blanchard’s Legendary Service. I’ve used his previous books as fast ways to understand and build a culture of excellence and promoters. I’m always struck by the change that comes when people put themselves in the path of great service. It builds an amazing momentum.
Conduct support training that focuses on accurately explaining problems in easy to understand terms, builds confidence, and inspires hope that problems will be solved. Follow that with verification checks performed by following up with users or staff. Provide the right coaching when things are going well and when they are not.
Add in net promoter indexing to your support and find out how people are really experiencing your team. This is something included in the service my team provides by asking how likely a user would be to recommend us to a colleague. They might not have a choice in who serves them but what if they did. Reality would suggest that we’re all replaceable and only in being the best can we avoid the inevitable.
Prevent the Glitch
All systems and software erode in time. This is especially true with routinely updated operating systems, applications, etc. In order to prevent these annoying problems, don’t let updates get away from you. Probably more on point is that software vendors are frequently updating their programs to make hot fixes and address errors. Staying current helps prevent these annoying problems.
Being active in that dialogue with vendors also gives you insight into when and how problems are being addressed. Which improves our dialogue with users about what is coming. Going back to the conversation above with the downtrodden colleague; I was able to update them accordingly about coming improvements and fixes to the common glitches they were experiencing.
Build User Knowledge
Rather than dismiss and insult users to establish your expertise, spend time growing their understanding of your work. This can be done on each and every support call by calmly walking people through problems, solutions, alternatives, and following through on real problems that need to be remedied at the systems or software level. You can also conduct meetings, workshops, and seminars to make provide training to users about the systems they use. Do both.
Make sure your are transparent about the systems, the weaknesses, and strengths. Gather users together to stay in touch with their perceptions of your systems and your team. This also gives you a chance to provide the most accurate information possible to users to foster a supportive and success-oriented culture and further banish the glitch from your world.
Maybe I am making mountains out of mole hills here. Maybe I’m not. What do you think when you hear glitch on the other end of support conversation? Send me a note and let me know how we can fix your glitch.