Month: August 2012

I recently attended a workshop for teachers where they learned how to flip their classrooms. I don’t like the term “flipped classroom” (a topic for a future post) but I do like the idea that teachers can create content in other media than print, and they can capture demonstrations and lectures for future reference. At the end of the workshop, one teacher said something that I’ve been pondering ever since. She said, “I won’t remember how to do this, but I’ll remember why, and when I’m ready to do it, I’ll ask for help.”

Too often we spend our precious technology professional development time walking teachers through a step-by-step tutorial for using a particular tool rather than talking about why to use it, and I’ll admit that I sometimes fall into that  trap. Software “training” (another term I dislike) is effective only when the trainees are in a position to start using that software right away and for a particular purpose. In a business, when the company switches to a new accounting program, they send everyone who has to use it to a training session. The employees then return to the office and begin using that software immediately as a major part of their work. This does not happen in education. Teachers may attend a summer workshop where they learn how to use a piece of hardware or software, but it may be weeks or months before they can use that tool to teach a particular skill or concept. And too often they learn about the software in isolation, with no discussion or thought given to how it supports their curriculum or why they need to use it at all.

I’m not saying that we shouldn’t demonstrate and give teachers time to explore hardware and software tools during our PD time, but it’s foolish to think that technology integrators or professional development providers can teach teachers all the technical skills they need in this ever-changing world. Software, hardware and web tools change too frequently and there are too many of them. I think the best we can do is inspire teachers to think about their curriculum and their practice, decide which tools will work for them, and then find a way to learn on their own.

I often return to the TPCK (or TPACK) framework developed by Mishra and Koehler to explain these ideas. This framework illustrates the types of knowledge teachers need to successfully integrate technology into their practice. While teachers need Technological Knowledge (TK), it’s only at the center of the model, where all three knowledge types intersect, that effective teaching and learning take place. Rather than helping teachers gain only TK (and assuming they will find the intersections on their own), I prefer to spend as much time as possible helping them see the possibilities for those intersections.

My husband once described a software training workshop for teachers that he attended. He said that teachers sat passively, followed the steps that they were shown, and created exactly the same product as the one being demonstrated. He said he learned a few tips and tricks about the software, but left with no idea how he would use it in his music classes. He didn’t learn anything that he couldn’t have learned from the help menu or through a simple Google search.

If we don’t spend our PD time in software training, how will teachers gain the technology knowledge they need? I’ve begun encouraging teachers to take responsibility for their own training. I suggest that when they realize they don’t know how to do something, they try one of these remedies: