Teaching Technology Troubleshooting is Like Teaching Math

Teaching Technology Troubleshooting is a Lot Like Teaching Math

I was sidetracked on my way to researching how to provide teachers “preventative strategies” to make the use of video, audio and social media tools more trouble free. I came across this blog post by John Spencer. In his 11 Reasons Teachers Aren’t Using Technology he makes the point that what holds teachers back isn’t always lack of skill or motivation but “What they lacked was a belief in their own ability to create tech-integrated lessons.”  It struck me that no teacher, even a great one, who doesn’t have some confidence in their ability to create the lessons themselves will ever get past the troubleshooting phase. They may try it once or twice but but may give up once things go sideways, as they often do with technology, even if they were given a list of troubleshooting tips or some training on how to prepare for technology. I think those things are valuable but by themselves are not going to truly make someone comfortable troubleshooting technology issues.

I’ve also observed that troubleshooting is not just about following a list of steps. There is an understanding of how technology works that comes partly through practice and increasing confidence. You can tell someone to check the internet connection if their web pages aren’t opening but  they won’t necessarily know why they are doing it or when looking for the wifi symbol in similar situations would be a good thing to try. It’s similar to teaching students the algorithm or the P.E.M.D.A.S mnemonic for division without them ever really grasping the conceptual knowledge behind division. It will be more of a challenge for them to transfer their division “troubleshooting” skills to dividing fractions or finding ratio and proportion without that conceptual understanding. At least not with the long term retention we’d like them to have. The same is true for troubleshooting technology. Understanding that mobile devices need wifi and what kinds of problems can be traced back to that connection can speed up the troubleshooting process.

I tried to think back to how I learned about technology in the hopes that it might give me some insight into how I learned my troubleshooting skills but that didn’t help. I’ve always been an early adopter of technology. As Rogers’ work on the Diffusion of Innovation (Rogers 1971) states, the early adopters are risk takers and are willing to fail and they often have the social capital to influence others. I know who those teachers are in my district that I can hand almost any technology too and they’ll figure it out and help others get excited. We couldn’t do it without them.  They troubleshoot fairly instinctively. None of the early adopters I talked to could really pinpoint how they learned it. They just get it. I don’t know that we can always teach that.

Roger's adoption/innovation curve graphic
Roger’s adoption/innovation curve

I think we may need to take a two pronged approach to help the rest of the right side of the adoption curve:

Troubleshooting as a Hardware/Network/Software problems

Let’s face it…sometimes stuff just doesn’t work. Devices need updates, websites disappear, plug ins are out of date, someone forgot to plug in the cart last night, or there is just something weird going on. Some of those are purely in the realm of the technology department and someone needs to be called in, and others can be handled in class. I didn’t have time to create one but I can envision creating a If this…then that type of sheet or poster that could go into classrooms or be attached to our computer carts to give teachers some quick troubleshooting steps to try. I’d model it after the Problem Solving Board idea  on AskATechTeacher.com. Jacqui Murray has created some great resources for teachers and regularly posts about new technology and how to teach any number of cool projects and basic skills.

Where we can, we need to help teachers learn to diagnose problems. Perhaps an interactive checklist of steps that we could ask teachers and students to use to identify where in the process the problem is occurring. Each question could be clicked on for troubleshooting possibilities.

For example, these 5 might be the main steps:

  1. Turn on the computer
  2. Check for wifi connection
  3. Log in with district credentials
  4. Click on the icon or tile
  5. Open the browser

If you couldn’t do one of the steps (you might have to use the list on someone else’s computer), you could click on it to get a list of options. For example:

  1. Turn on the computer
    1. Try plugging the device into the extra power supply and give it a minute or two and try turning on again.
    2. Make sure the power button on the cart was turned on.
  2. Check for wifi connection
    1. Make sure the ethernet cable is plugged into the marked port in the classroom
    2. Ensure that the cart is turned on
    3. Look for the wifi icon in the lower right of the screen
      1. If it’s not on, click on it and choose the Mobile Lab network and click Connect

I suspect, if you could get people to use it, that it wouldn’t take long for the troubleshooting steps to start making sense. Simplicity and repetition would be the key.

Troubleshooting the Human Element

I once heard about an acronym that sums up this type of problem P.B.K.C (Problem Between Keyboard and Chair). Sometimes names get misspelled or students have trouble typing an entire web address or they just don’t click on the right button.  A blog post by Scott Meech, “Scaffolding Your Lesson Plans – Lesson Learned from Traditional Teaching” brought up a very good point related to teaching with technology:

As I began to utilize technology in my classroom, the more it was apparent that I had to have a similar outlook with my non-tech experiences.  Too often I would ask students to use technology by creating a project and then not revisit those skills in some fashion.  I didn’t scaffold the learning throughout the school year and develop their skills by building upon previous activities. Students created some amazing documents, videos and podcasts, but I noticed that this didn’t always translate into long term learning with technology.

That thought gave me a little epiphany. We don’t do that with teachers either.  We offer one and done courses on technology skills that sometimes neglect to connect to relevant content in their classrooms and we don’t revisit or scaffold that learning for them. He goes on to say that teachers need to learn to use the technology well themselves if we expect them to teach students to use it.

So, what if we started by picking one program we really wanted students to learn to use and concentrated for a whole year just on that tool. We could offer various levels of PD around the tool but we’d keep coming back to it. We’d use the database of who has attended training to follow up and offer more advanced classes (both in person and online) to encourage teachers to continue learning about the tool and how it could help their students. If we modeled troubleshooting as part of that learning and revisited problems they had in class so they could share their solutions and learn from one another. Hosting troubleshooting forums in internal social media forums such as Yammer, would allow teachers to contribute when they’ve encountered a similar problem or just search on issues to see if someone has already posted a solution. This would be a great place for the early adopters to step up and monitor those forums.


Murray, J. (2015, May 23). #81: Problem Solving Board. Retrieved August 07, 2017, from http://askatechteacher.com/2015/05/27/81-problem-solving-board/

Meech, S. (2011, October 21). Scaffolding your Lesson Plans – Lessons Learned from Traditional Teaching! Retrieved August 07, 2017, from http://www.techlearning.com/default.aspx?tabid=100&entryid=441

Spencer, J. (2012, July 14). 11 Reasons Teachers Aren’t Using Technology #edchat #edtech. Retrieved August 07, 2017, from http://www.spencerauthor.com/11-reasons-teachers-arent-using/