A nerdRider’s guide to training

dsc_0010.jpgRecently, I had the opportunity to train developers in Hong Kong. My “day job” is as an application framework developer. The way I explain my job to my mum is: “Imagine I build the chassis of a car, then hand that on to different customizers who put their own bodywork on the completed chassis and sell it as a car.” That is an overly simplistic analogy of the job that doesn’t stand up to close scrutiny, but like most analogies it is correct enough – up to a point.

The company I work for is US based, with development and sales offices worldwide. It has grown through various acquisitions of smaller companies with products that complement the current line-up of products. There had been some shuffling of projects recently, with the end result that developers working in our Hong Kong office had inherited a project based on our framework.

Normally, our architect gives technical training to the developers when required, but this time, the training coincided with his annual leave and as such, I got to present the “course”. After jazzing up the power point presentations with a few newer screenshots and running through the slides I was pretty much ready to go. Many moons ago, the architect and I had given the “first version” of this training course to a group of developers who had convened in Chicago for the event. I don’t think I had conducted a training session since then! What this meant (I discovered) was that my presentation skills were a little rusty.

I tend to be quite critical of my own ability and work, and in a reflective way, I try to learn from “my mistakes”. Whether or not other people notice these mistakes (or would even consider them “mistakes”) is irrelevant. I consider communication skills are both (a) very important to have in any job and (b) something I like to think I have got a relatively good grasp of. So, here are some things I learnt/re-learnt/should never have forgotten:

1. Speak slowly. In my case, this was doubly important given the fact that English was their second (or third) language.

2. Improvise. Having sat through my fair share of dull Powerpoint presentations, I was keen to avoid the trap of just reading the bullet-points on the slides I presented. Speaking slowly is just as much about “sentences per minute” as it is “words per minute”. Give yourself time to think of something sensible to say, rather than just suffer verbal diarrhoea. – Leave that for your blog 😉

As a side note to rules one and two: Remember that this is new material to your audience, they need time to absorb the information. This gives you some leniency in how long you can afford to think of what you are going to say next. Visual cues from your audience can also help you determine if it’s worth repeating a point or giving a more “in-depth” analysis of it.

3. Avoid skipping ahead. This is difficult when you improvise. With the material I was presenting, it quite often had the format of introducing points that built on what had gone before them. Try not to be too forward looking.

4. Don’t pad a presentation with extra material. If you forget Rule #1, you may be tempted to add extra material when you finish early. Problem is, you can tend not to stick to material that can be described as “Introductory”. As stated above, this stuff is “new” to your audience. Giving them in-depth material just confuses them. Avoid this trap, by remembering Rule #1.

5. Writing code in presentations is best avoided. This is not a hard and fast rule. Sometimes it is a good way to demonstrate how easy something is to do. If you do write code, make sure your editor is using a big-goofy font so that people can read it on the projector.

This recent training session was given to a small group. There were only two developers with me and two more “tele-conferencing” in. In such a small group, I feel questions should be encouraged at any stage. Answering with “we will cover that in a minute” is a perfectly valid response. Also, you should not fear getting a question you don’t know the answer to. Every presentation I have ever given was not designed to be a test of my skills in a hostile environment. As a result, people won’t ask questions that they know the answer to. If you don’t know the answer, have some way of recording the question and simply state “I will get back to you on that one”.

In larger groups, it is best to encourage questions at the end of a session. With larger groups, the next rule becomes important:

6. Always repeat / paraphrase the question asked, before giving an answer. Not everyone is blessed with good vocal projection and even those who are tend to have their back to some or all of the audience. No matter how clearly you hear their question, you can almost guarantee that some people won’t have. As such, your answer will be out of context. I must admit, I do feel kind of silly starting with “OK, so the question was…”, but as an audience member, I have always appreciated that effort made by the speakers who use this technique.

7. Take breaks. You should also plan to have breaks in the schedule. Whilst you can plan to have them, it is best not to actually schedule them in terms of how far through the material you will be, when the breaks are taken. Rather, use your audience to provide you with clues as to when they should be taken. People fidget and get less responsive when their concentration levels drop. Use these signs as indicators of when breaks should be taken.

I am sure there are other far more useful web-sites on public speaking that can give you better advice than what I have listed here. But if only one of my rules stick, make it “Speak slowly!

One thought on “A nerdRider’s guide to training”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>