At the start of the year, dozens of users come through our office with small computer issues. They need to clear a bad printer job, restore network access, install a new toner cartridge, fix access to mail, update their operating system, and so on. Most students prefer to resolve the problem quickly and get back to work (or play). However, a teaching opportunity usually presents itself, one that may build the student’s capacity to resolve the problem herself in the future. I usually opt to take a little time to teach the student the cause of the problem and the steps needed to resolve it. However, many times the student’s eyes glaze over — he would rather just get the solution and move on.
A similar problem exists with regard to backing up files and preventive maintenance (software patches, antivirus definitions, and adware/spyware scans). Some users perform these tasks diligently. Others never perform them. The tech team has to decide how much of this to require in some manner or actually perform for users. We do not want the poor habits of a few users to drag the entire network down for all users! Up to this year, we have required all laptop users to give us their computers for a few days, and we perform the updates and scans ourselves — clearly an enabling practice for many users. This year, we have taken a small step toward increased user responsibility by installing a Cisco CleanAccess network device that blocks a user from accessing network resources if she is not up to date with the latest patches and defs. Of course, there is a small convenience and performance hit associated with this device, so its use is not ideal. However, it may strike the right balance between protecting our network and building user responsibility for the integrity of their own systems.
The hard road to self-sufficiency is to do less hand-holding in certain cases. If users adopt an overly service-oriented approach to tech staff, then we sometimes simply refuse to resolve the problem ourselves and instead teach a solution that they may implement themselves. I wish there were an easier way to teach this lesson, but it sometimes is necessary to remind users of their responsibility to learn more about the computer system that they are using. Sometimes, one must work delicatly to avoid pissing off a user who has a frustrating problem that needs attention.
Sometimes, users conceive of the tech team as a service center that exists solely to fix problems. We prefer to think of ourselves as builders of systems and trainers of users. We create the capacity to get things done both in terms of the capabilities of our systems and the knowledge of our users. As school technology programs grow larger, it becomes impossible for a handful of tech professionals to resolve every problem that occurs on campus, nor is it consistent with our educational mission to do so. Students use their computers off-campus, during the summer, and in college. They should learn to manage their equipment while with us in secondary school.
Students and adults often hold another interesting misconception that confounds this issue: that computers behave in a predictable, rational manner. I am often asked, “will this solve the problem every time?” or even “why did this happen?” Most often, we don’t know the answers. We resolve many problems through trial-and-error and workarounds. Sometimes, this characterizes our entire approach to the field. I am not sure what is the best way to teach against this misconception that computers are orderly, but it throws many users for a loop.
I hope that increased communication with users will help build a road to self-sufficiency. After all, tech professionals typically consult external documentation on a regular basis to solve unusual problems. I am probably going to start a department blog or Moodle site as I did at UHS in order to keep the user community abreast of tips and important changes on our network. I would also like to try building a school tech knowledgebase for the first time — install good knowledgebase software and take user submissions to help build a library of commonly-encountered problems and step-by-step solutions. It would be great to direct users to this resource and build a habit of checking documentation before asking for help.
Richard Kassissieh is Director of Technology and Learning Innovation at