A bundle of colorful ethernet cables tangled together in a ball.

Tangled cables, an unfortunate part of living a networked life. Photo by Bruno Girin via Flickr Creative Commons.

As an Academic Technology Specialist, I am often asked things I know nothing about. My job title, admittedly, is confusing. Do I work in IT? Do I work in audio-visual engineering? I do neither of these things: I’m an educator who builds curriculum, develops resources, and consults on how we teach with technology in all of its forms. My background is in English through both of my degrees, so I’ve accumulated nine years of humanities education (with a smattering of some social science) and not much else. I took as few science, engineering, or math courses as I could possibly get away with, without so much as a single STEM-oriented hobby. And yet my title makes it sound like I could just as easily work in IT. Or audio-visual engineering. Or a help desk. As a result, I got questions about hardware, software, cables, plugs, adapters, screen resolutions, outputs… you name it.

90% of the time, I have no idea what I’m doing.

When I first started my job, I felt really insecure about not knowing literally anything about how any equipment worked. I was hired as a “technology specialist,” and while I understood that my job was to be critical of technology, to assess its usages and applications for writing pedagogy, my field of true expertise, I still felt somehow pressured to be good at all things related to technology. If it ran on electricity, I felt like I needed to understand how it worked. I have less of an anxiety about that now that I’m a couple of years into the job, but I’m still spending a lot of time learning on the fly.

So, what do I do when I get asked questions I don’t know the answer to? How do I help resolve problems when I literally have no clue what the first step is?

I’ve compiled a list of ways that I’ve managed to build confidence in myself and to start to solve problems even when I am totally lost on what to do.

  • Only say “I don’t know” AFTER I’ve given something new a shot; try “Let me see if I can figure it out” as the first response instead:” It used to be my impulse to say “I don’t know” immediately when I didn’t know how to do something. But saying “I don’t know” as the first reaction doesn’t exactly inspire confidence and it’s actually not always accurate. Indeed, if I’m not sure how to do something, it’s probably more accurate to say, “I don’t know right now.” My answer has become, “Hmm, let me see if I can figure it out” in order to show that I may not have the answer right away, but I’m doing the thinking and problem-solving work in the hopes of getting to this answer. Usually, if I just give myself space to take a breath, assess the situation, and use any of my prior knowledge, I can make some strides to figure out a technical issue.
  • Don’t be afraid to go slowly. When I’m approached with a last-minute technical question, the person asking me is usually in a bit of a panic. “I can’t get this thing to work!” or “Can you help me get this set up? My presentation starts in 5 minutes!” are pretty typical ways that I hear requests framed. As a baseline anxious person myself, I can let other people’s anxiety rub off on me pretty easily, and so in my first year on the job, I found it a really stressful experience to be asked to help with something at the last minute, particularly if I didn’t know what was going on and if I wasn’t sure how to solve the problem. But more recently, I’ve given myself permission not to rush: if a presentation starts late, it’s OK. If I need time to make something work, that is more worthwhile than going quickly, feeling flustered, and being unable to solve the problem. After all, rushing often clouds my judgment and anxiety can paralyze me, so reassuring the person who has made the request that solving the problem may take some time and require a bit of thinking (not to mention some Googling on my smartphone…) has been helpful for giving me the space to make a real difference.
  • Take full stock of the situation. I used to panic if I could not immediately recognize the technical problem in front of me, from unfamiliar equipment to an error message on a screen that I had never seen before. But what I’ve learned is, if I really don’t know where to begin, I should take stock of everything I have at my disposal. Is there any part of this I recognize? Is there anything adjacent to what I recognize? Which things seem to be functioning well? Which piece seems to be causing the disfunction? If I’m dealing with hardware, this might mean touching everything in sight: does anything seem to be loose? Does anything appear to be out of place? Is anything making a loud noise? The problem, more often than not, is tightening something, putting something back, or shutting something down. Taking stock of the situation allows me to solve quick and easy problems that may seem complex (even if I don’t really know the root of the problem).
  • Consult a search engine. I often say that every time I run into a technical problem, the best thing I can possibly due is just hop on to a search engine and look up the problem. Most problems are not so uncommon that no one has written about it before, though it can take some combing of user discussion forums to find the right answer. Trial and error is critical, and looking at search engine results can often let me know which trials to attempt (particularly if I’ve already taken full stock of my situation and tried the foolproof steps that I know work).
  • Be positive! This can be a hard one for me because I’ve long felt ashamed of myself when I don’t have the right answer or I can’t be immediately helpful. But maintaining my positivity, even when I’m lost, has gone a long way. If it’s taking me a while to solve the problem, I try to make a joke or make light of the situation while offering an actionable alternative. There is, often enough, a clear workaround anyway that might just involve thinking flexibly and creatively.
  • Don’t be afraid to ask someone else for help. Even when I’m perceived as the main support person, I’ve learned not to be afraid to ask someone else for help if I think I could use more support. It is not my responsibility alone to solve other people’s problems, and I recognize that a collaborative effort can often yield the solution. Plus, when a solved problem is shared, the victory feels all the sweeter!

I still get frustrated when I’m asked to solve a problem I don’t initially understand. I still don’t exactly love the process of staring into opaque black boxes, fumbling around with tangled cables, and mashing random and unresponsive buttons. But I’m trying to understand these experiences as ways that I can grow and become more flexible in my own thinking.

Just today, I managed to get slide content projected onto a wall, and a colleague exclaimed, “Wow, I could have never done that!” While those around me began to heap me with praise (seriously, there are no other occasions where I receive more praise than when I get a projector to work), I immediately responded, “I think you could have.” Initially, I wondered if that was a mistake to say. I didn’t want the colleague to think I was accusing her of being lazy or accusing her of being unwilling to solve the problem. I could understand why she asked for help, especially since she was feeling overwhelmed. At the same time, I meant what I said: with enough perseverance and calm, I bet she could have figured it out too. Maybe it would have taken her longer than it took me. Maybe it would have felt more frustrating or more enraging. But given my journey to solving technical problems without any technical background, I’ve become an even stronger believer in anyone’s ability to learn something they know very little about.

Is my knowledge or understanding of audio-visual equipment deep? No. Do I understand all of the world’s hardware and software? Not even close. But I can get by and I can figure out when I’ve reached my limits. That, to me, is an unintended benefit of having a confusing job title and learning more about how to learn… on the fly!