The following are skills/techniques/style tips that I sent out to a friend recently. I cc'ed some of my training mentors (Scott Bain of Net Objectives, and David Bernstein of Techniques of Design), and David suggested I blog this and get feedback/additions from other trainers (Agile or otherwise, really).
Originally I tried to categorize them, and the categories became a hindrance. So here they are in no particular order:
Projection: I had to learn to "project" my voice. To bellow out words without sounding like I'm yelling. It's like singing loudly in your car, but you have to do it when people are looking.
Immersion: The best courses (for everyone) are those where the instructor says less, and the attendees do more. Build creative exercises that give the attendees the chance to really build the right skills (while avoiding out-of-course-scope skills, e.g., don't ask testers to write code).
Diplomacy: This one is Scott's suggestion to me: If you get someone who wants to argue, give yourself the chance to really listen, and try to see how that person came to those conclusions, then make them right: "Yes, you could implement the pattern using a switch statement. And it would still be The Pattern! So, what do we gain and lose by using classes?"
Mimicry: Borrow techniques, phrases, and jokes from your favorite instructors. I can't teach just like Scott (I tried many years ago), but I do borrow from his style. I'm also still borrowing heavily from Fred George after 10 years, and two of my favorite college professors from 20 years ago.
Authority: You may want to tap your inner extrovert. Sometimes it feels like I'm wearing a mask, or playing a role, except that it's still me. I have to talk with authority, but avoid rambling excitedly about some fascinating (to me) detail that will lose people. Strangely, the "Helpful Guide" gets a far better reaction than the "Curious Scientist" persona. It's a shame, because I'm really the latter at heart. But I do let my inner geek out to play from time to time.
Honesty/Humility: No one appreciates a know-it-all. Allow yourself to say "I don't know. I'll see if I can find out for you before the end of class." (If you are worried about losing credibility, try "That's fascinating! I haven't run into that before. I'll definitely want to look into that and get back to you.") Or utilize the giant pool of knowledge sitting in the room: The attendees. I've taught some very bright developers, and they often know much more about the latest software tools. I couldn't possibly keep up with them all!
Also, allow yourself to make mistakes. Try not to point them out if it looks like they're trivial (like having two slides out of order, or Java code in a C# slide...), but if you misspeak, correct yourself.
Focus: Keep the course on-topic. If there are questions about another topic, offer to do a lunch-and-learn, or stay late, or come in early, to hold a brief talk about the other topic that's worrying them. Don't try to throw everything into a single course. It may be entertaining, but the necessary skills will be lost. It's also poor marketing, as they'll assume they don't need you back.
Pragmatism: Teach what you know, and what you believe in (or have seen work in the past), and continue to get real experience in what you teach (that's a tough one).
Others? (With thanks!)
Subscribe to:
Post Comments (Atom)
Rob,
ReplyDeleteRight on!
I'm an especially big fan of: 'Utilize the giant pool of knowledge sitting in the room'
When I'm doing training, I try to facilitate information exchange between all of the folks in the room, as much as sharing my own insights. That's one of the great things about doing training with professionals: they bring a lot of knowledge and experience to the workshop.
Cheers,
Chris
I tend to think most training courses are too boring, so I like to add "Interesting/Humorous Stories"
ReplyDeleteMaybe this goes under Mimicry, but I would call it out separately. When we are learning things for our careers it is important to remember we do it because we love what we do. Don't we? ;-)
One caveat - make sure it really is funny, and not just funny to you! I try most stories several times in different ways prior to ever using them in a course.
All things considered this is a great list. I'm glad you were able to find it and post it as a blog entry. Hopefully trainers will read it and try to improve!
There's more goodness here than in most 200 page how-to books. And what you say applies to any kind of teaching, really. Not sure adding to it would enhance, as the succinctness and digestibility of what you have here is important.
ReplyDeleteI'd add to Bob's point about storytelling by casting it as "Tell vivid stories." I was at a one hour lecture earlier this week where the presenter had many great insights and novel perspectives on something I was very interested in. But he used very few examples and told few anecdotes to illustrate. After half an hour of dense, rapid-fire abstractions, my brain shut down. It was too much of a good thing, with too few "hooks" to catch the info. Our memories are naturally designed to store things in the form of stories and examples, the more vivid the more meorable. Not everyone can do funny, but anyone can do vivid with a little practice.
Not sure how this fits with what you have, though. It may be second-tier, while the points you have made (well illustrated through examples!) are all top-tier.
Thank you for the comments. I hereby correct a flagrant omission: "Tell vivid stories" is definitely first-tier.
ReplyDeleteI often tell positive stories from the agile projects I've worked on, and/or coached, such as the Denali project (with Jim Shore), or the University of Michigan OTIS2 project (with Menlo Innovations). Those two projects contained particularly pivotal events that led to significant success for the team and organization. These events serve as examples of agile techniques generating realistic, achievable ROI well beyond the mediocrity to which most people are inured.
Apparently my enthusiasm comes through; often attendees tell me that my stories were their favorite part of the course. (I hope that's a good thing! ;-)
Yeah, I’m so glad you shared this on your blog and I very much agree with your post and the comment. I added a few more points on my website blog, Techniques of Design at (http://techniquesofdesign.com/2009/04/16/on-techniques-for-agile-trainers/).
ReplyDelete