Technology Support as Teaching
April 24th, 2007 | Published in Education, Nonprofit Tech, Technology Zen | 2 Comments
I’ve been thinking a lot about technology support lately. Really a lot. Part of it is being prompted by my own technology support experiences with my satellite “broadband” provider (which have been largely frustrating). A lot of it has been because I have lately been exposed to situations where I have felt organizations haven’t gotten the support they need, which, in our world, I think is all too common. As I move out of doing implementation, and into more evaluation, planning and facilitation of technology change within organizations, I wanted to spend some time articulating what I have tried my best to practice when I’ve been in a place of providing technology support.
All technology providers have to deal at some level with support. Whether they implement a system, or build it, they will inevitably have the job of supporting that technology. Providers have many different ways of handling that challenge. Unfortunately, the most recent trend, which I have experienced all too much (and I’m sure you all have too), is to simply follow a script with the person who needs support. It drives me simply nuts that every single time I call my satellite provider about a problem with the service, and I’m saying “I’m seeing 80% packet loss, and doing a traceroute suggests that it’s about 2 hops after your modem” and they respond with “OK, first, we’re going to clear out your browser cache. Go to preferences …” It has been a challenge to resist uttering strings of obscenities.
But also, the question is - is providing technology support simply just an end in itself, or is it also a means to another end - that is, can it be a means to empower clients in appropriate technology use to further their mission?
I realized, in thinking about all of this, that the model of technology support that makes the most sense to me is to think of it similarly as a teacher-student relationship. I know, I’m a born educator, and I’m sure someone out there is saying “if you have a hammer, every problem looks like a nail…” But I do think there is some validity to this approach. Certainly, if you are a technology provider that values empowerment of your clients, this is probably a good model to consider.
So what is it about a teacher-student relationship that we can learn from to provide really good technical support? From my perspective, there are four elements to a technology support process with this as a model:
- Assessment - where is the client - both in terms of technology knowledge, as well as in terms of what they need at the moment?
- Empowerment - as you help them with a problem, teach them about the problem, and ways to troubleshoot (or possibly solve) the problem themselves in the future.
- Relationship - an ongoing relationship with the client
- Solution - providing the solution to their problem
First, Assessment. Where is this client, now? First, there is the question of what they know. If you have a relationship with them (see #3) you’ll already be familiar with their technical expertise - so you’ll know where to start. But there is more than that to assessment. What is going on for them? Is this a problem that is critical to their work, or a “pebble in the shoe” kind of problem - annoying, but not urgent? Are they trying to get a grant out, and they are scared they won’t meet the deadline because of a technical issue? Are they angry? All of these are important to know and understand, so it’s possible to meet them where they are. That’s one of the hallmarks of a good educator - meeting a student where they are, tailoring the education to meet the needs of the student. It’s also, I think, a hallmark of a good provider of technology support.
Second, Empowerment. One of the most common problems that someone who has built websites has, is the client calls up, and says “the website is down”. And you hurriedly go to your browser, and, voila, the website isn’t down. So now you take them through all of the steps to figure out why it was they can’t see their own website. You can choose to take them through this problem so that they figure out at the moment what’s up, and who to call, or you can take them through it so that next time it happens, they won’t need to call you, because they’ve figured out the problem really belongs to “insert_some_other_technology_provider_here.” Or, they’ll call you because the website really is down. Teaching them about the technology behind the problem they are having, and helping them to understand what’s involved in it, not only empowers them to deal with problems more on their own, but it also empowers them to solve other technology problems, and be more engaged in technology planning in the future.
Third, Relationship. All of this works within whatever relationship you have with a client. As mentioned above, if you’ve worked consistently with a client, you know what their level of expertise is - this makes assessment easier. Also, you remember how much work you got done when a substitute teacher came to class? Not a lot of learning, but certainly a lot of spitballs. Consistency in relationship is as important to students as it is to people who get support from a technology provider. Usually, of course, with the huge technology providers, that sort of thing isn’t possible. But with smaller providers it certainly is. Sometimes, even with larger providers, they manage to get around this by having detailed logs of conversations with you. I’ve found that quite helpful in the past - it has surprised me when someone has said something like “I see you called a couple of months ago with a problem regarding x. How has that worked for you since then?” It was nice to feel like someone actually bothered to write it down, and for the person talking with me bothered to read it. In the past, for me, my ongoing support relationships with clients have been the way that I have learned the most about their organizations. It has allowed me to be proactive in working with them on technology, and incredibly informative in helping future planning. The relationship is a two-way street: just as they let us know about challenges they face with their technology problems - it’s important for us to tell them about the challenges that we run into in working to support them. There is a level of trust that’s important to this relationship. Honestly, it is the relationship I cherish most highly (even more highly than whatever they pay me).
Fourth, Solution. This is where the provider-client relationship differs most from the teacher-student relationship. Of course, in the end, the client needs their technology problem solved, as quickly and efficiently as possible. But I’d argue that good assessment of where the client is, and where the problem fits in their work and organizational lives, empowerment of them to troubleshoot problems on their own, and an ongoing, stable relationship, will make the eventual solution of the problem a lot easier, more economical and less stressful for both the client and the provider than it might be otherwise.
Technorati Tags: nptech, techsupport
Tags:
April 25th, 2007 at 1:51 pm (#)
Hi Michelle,
“and I’m sure someone out there is saying “if you have a hammer, every problem looks like a nail…” But I do think there is some validity to this approach. Certainly, if you are a technology provider that values empowerment of your clients, this is probably a good model to consider.”
I agree. In my work people learn evaluative thinking from me. As my client relationships evolve, I take on new tasks as people learn things. Of course I keep lots of the most technical work (ie: creating graphs or crunching numbers) and we split the tedious work (ie: data entry and reminding people to “do stuff”.)
Empowering my clients to think evluatively hasn’t put me out of business. It opens additional doors.
April 26th, 2007 at 12:46 pm (#)
I think one reason people don’t follow this model is that they are too busy to think about the long term and instead just try to get the immediate task done. (I recently blogged about shortsightedness and one example in that entry was me not providing education as tech support when I probably should have: http://www.ctcvista.org/node/739 .)