A Technical Presenter’s Journey: Part 1 – Know Your Audience

Writing

I want to start a series of posts on tips for giving technical presentations. What I would really like to do is get tips and tricks from you, the reader, and then post them as a community driven series of tips on giving technical presentations. So here is what I need from you

  1. Either put up a blog post or just write a tip on giving technical presentations. Follow this post as a guide and just give a bit of info, tell a story, give a nice anecdote, etc… Have fun with it!
  2. Once you have done this, send me a message via my contact form and either send me the tip directly or give me a link to your post. If you send me a link to a post, I am going to copy the entire contents of the post, but with all of them I will give you a prominent link back to whatever site you want me to. There will be no pretending that it was my content!
  3. Sit back and smile knowing that you helped your fellow technical presenters! Then watch my blog over the next few weeks as I put up these posts. Or just come back at the end for a buffet of technical presenting tips.

And as a side note, I reserve the right to only use the tips that I deem worthy! 🙂 Ha ha, I just want to make sure there are no duplicates or poorly written content. (Except for my own!) So please tweet or blog about this so that this little experiment can be a success!

On With The Show

I’m starting this series off with a tip that isn’t about necessarily about technical presentations, and it has been said before a hundred times, but I need to bring it up again for a few reasons. First of all, if you follow my blog then you are probably aware that I gave a presentation last Wednesday at the Hampton Roads .NET User group here in Virginia, and I came away from it with the feeling that, for the first time, my presentation was a failure. The presentation needed some work, I won’t discount that. And I also need to work on my skills in how I pull the audience into the presentation, but I think that one of the biggest mistakes was that I did not consider the audience to whom I was giving my presentation.

One of my co-workers, Chris Allport, put up a post on this blog where he laments having not objectively approached the material. You see, he and I are quite into a lot of the more aloof, high-level ponderings about software and the philosophies and approaches of modern software development. So when we were looking at this material we were all high fives and "rock on". Well, probably not actual high fives, but more proverbial ones. We liked the material, thought that more people needed to be indoctrinated, and so we tuned the material accordingly.

So, suffice to say that I place the entire burden of my failed presentation solely on Chris’ shoulders. He should have stopped me. 🙂 Ha, just kidding. But in all seriousness, he points out in his post that he agreed with the material, and because of that he saw the material in a positive light. In this case, he wasn’t an accurate representation of my audience. Not at all his fault! The challenge is to step outside of yourself and objectively review something, and in order to do it, you have to know who you are stepping into. (Okay, that sounded a little dirty)

It is already hard enough to get inside someone else’s head, and it is impossible when you don’t know who that person is. If I had thought hard about the audience I was presenting to (a .NET User Group), then I might have considered gearing my presentation toward less abstract examples and more concrete code examples. A .NET user group is usually a pretty wide mix of expertise and experience levels, so whenever I present at one I need to be cognizant that in order to reach the entire audience I need to gear my presentations more toward the beginner. If I had approached my presentation by looking at it through the eyes of a less experienced developer then I would have probably changed my presentation in a few significant ways.

So, to sum it up, think about and focus on your audience when you are creating a presentation. Think about who is going to be there and at what level they are going to appreciate the information. It is quite possible that you need to aim your presentation at a wider audience, or to give more background on concepts that you would normally skim over.

Loved the article? Hated it? Didn’t even read it?

We’d love to hear from you.

Reach Out

Comments (8)

  1. I usually put my celluar phone on vibrate. The judge told me he’d hold me in contempt if he heard my phone ring one more time. Seems to me like we were both just trying to make a living, but some people don’t like you trying to get yours while they’re busy getting theres… Just saying, you know?

  2. I was at the presentation you’re referring to and it’s my opinion that the problems with the presentation were more organizational than with the material itself.

    Had the presentation been "tighter" and better rehearsed, I think it would have gone better. I don’t think you were comfortable and fully committed to the material as you mentioned it was a new presentation and a different type of presentation for you. That combination throws even seasoned presenters off their game.

    I think it’s great to occasionally raise the level of discourse and get developer’s noses "out of the weeds" of concentrating on specific technologies and techniques and get them considering more "strategic" topics such as those you were presenting. Generally, people will raise to the level of the expectations you set.

    Just my two cents worth!

  3. @Perry Excellent feedback, thank you! And I agree, I think that the material could have been delivered better. I actually practiced it quite a few times, but when it came to delivering it I felt like I was losing the audience. At that point I think I threw myself off even more.

    On that same note though, is it just us, the people who want to raise the discourse, that think we need to get other developers noses "out of the weeds"? I struggle with that quite a bit because I know tons of developers that just want to learn a tool and get the job done. In many cases I’m not sure there is anything wrong with that.

    When I was delivering the presetation at the HRDNUG I felt that I was losing a lot of the audience very early on (like 20 minutes in). But like you said, maybe it was just my delivery of the material, or maybe it was the material itself. Probably a combination of both. Thanks for the feedback!

  4. @Justin – I think there is a hierarchy or perhaps an evolutionary process for developers. The majority of developers are quite content to learn a tool or technique and, as you say, get the job done. They have no desire to learn about more abstract concepts and, there’s absolutely [b]nothing[/b] wrong with that.

    From that group some percentage, through exposure to a presentation such as yours or through natural curiosity will want to take things to the next level. Perhaps design patterns or other object-oriented concepts. Again, absolutely no value judgment is implied. These people are no better (or worse) than their fellow developers that do not wish to learn these concepts. They just have a natural drive that impels them to learn more and more.

    And, a certain percentage of [b]these[/b] developers will want to go on and learn even higher-level and more abstract concepts. Maybe the SOLID principles, recursion, etc.

    While not everyone in the room is ready for the concepts, someone will be. And for those that aren’t. Maybe they’re just not ready [b]now[/b]. But the seed that’s been planted may eventually sprout down the road.

    So, I agree with you that most user group members are probably primarily interested in what makes their day-to-day jobs easier. But, throw some OOP seeds out there, water them with some SOLID goodness, and who knows what will sprout?

    Okay, I’m done with the planting metaphors!

Leave a comment

Leave a Reply

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

More Insights

View All