This is a transcript of an audio program located in the membership area of EffectivelySpeaking.Com. To get access to this audio program, as well as many other materials, you can sign up for a free membership at
http://www.EffectivelySpeakingMembers.Com

Hi this is David Mudie and I would like talk to you about technical presentations.

I want to take a personal experience of mine as an illustration for technical presentations. As many of you know one of my first public speaking engagements was before a large audience at a software conference. Now I did not want to speak at this software conference – but I did want to make business contacts there. I could not afford the admission price – it was $3000 US, and my company was going out of business. Speakers however, got in for free – so as much as I did not like speaking, I did not like being unemployed more.

The topic of the presentation was a security methodology I had developed, and a piece of software I had written that would support this methodology.

I was accepted for the presentation and I had about five months between receiving acceptance and having to deliver the presentation.

I slowly started working away at the presentation, procrastinating a little bit, because I really didn’t want to do it - but for the most part getting on with it because I realized that I really wanted to get there.

I made a very technical presentation. At the same time I was learning as much as I could about public speaking. It was during this time that I came across a little tidbit of wisdom that I found to be incredibly valuable.

The individual said, “Don’t try to impress your audience with how smart you are… impress your audience with how smart they are.”

I took this piece of advice to heart and realized that the presentation I had been composing was for somebody with my background, my understanding.

It wasn’t going to be useful to the majority of the audience – and so I threw it out. I took my presentation and I boiled it down to two clear, concise points. Points that anybody could understand – even somebody who had never used the software that I was supporting.

The points were:

One: That you need to establish a level of security that is comparable to the importance of the data that you are securing. In other words, if you’re not guarding nuclear weapons, it might not be a good idea to establish a security policy that is comparable to guarding nuclear weapons.

Why would that be? Isn’t all data important and should be secured?

Well absolutely - however, if the security level is so onerous on the users that they can’t do their job effectively, they’re going to find ways to sabotage it. They’re going to find ways to get around it. They’re not going to see the security as enabling them to do their job effectively and protecting the environment within which they work – they’re going to see it as an adversarial relationship.

So that was my first point.

My second point was that the business community and the information technology community that was supporting them from a security point of view, have to work together as a team. In other words, as a security officer, I was not the expert on their business processes. Yet the security model that I developed had to support their business model. So rather than just going and securing a system and telling them, “well that’s the way it is” as so many security officers do, I found it much more effective to sit down and talk to the business community and say…

What areas do you need access to?
What areas are you responsible for?
How are you willing to give access out to other members of the business community to areas that you are responsible for?

Now that was essentially my presentation. I then demonstrated my software that supported the methodology and everybody pretty much understood what I was talking about.

In fact they understood it and felt good about themselves because they were comprehending something that was relatively technical in nature, but presented to them in a way that they could understand.

So, if you’re putting together a technical presentation, I would urge you to consider who’s in your audience. What is their background? What is their knowledge?

Rather than approaching it from the point of view of what your knowledge is, keep in mind who they are.

Try to craft your presentation so that as many people in your audience (again) can think “how smart they are”, and in doing so, they will admire you, appreciate your presentation, and think how smart you are.

This article is available to be heard in the private members areas. Visit http://www.EffectivelySpeakingMembers.Com to learn about all the great information that is available to you right now. Start overcoming your fear with less effort than you thought possible.