Learning from Feedback as a Public Speaker

October 1, 2009

no comments

Over the last three years, I’ve had lots of experiences as a speaker at conferences, courses, private presentations and other opportunities. Among them, I had the chance to present at the Microsoft Developers Academy, TechEd and IDCC; I taught 54 courses for Sela, including Windows Internals, .NET Debugging, .NET Performance, C++/CLI and many others; and I lectured at short half-day MSDN events on Windows 7, Windows Server 2008, performance, debugging and concurrency.

Almost every training session, every course, every conference concluded with audience feedback. (If you ever filled an evaluation form for my presentation or course, thank you for your time and feedback!) I’ve been meticulously collecting this feedback for the past three years, and figured that now would be a good time to look back and share with you how you think I’ve been doing, and what I’ve been doing with this information.

They say that positive feedback is all very similar; negative feedback is varied and interesting. Here are some of the things I’ve noticed during the past three years.

“Less Code, More Theory”

This is something I’ve been hearing for a long time during the first couple of years, and always wanted to work on. I guess from a certain perspective it’s just that much easier for me to focus on what I’m really good at—showing deep technical demos, writing lots of code on the stage, typing commands into the debugger, and so on. It was much harder for me to talk when I didn’t have any code or live demo to back me up.

During the last year, I focused more and more on subjects such as design for concurrency, performance testing methodology and case studies, architecture of distributed system and other topics that often can’t be accompanied by a simple code demo and must be explained using hand-waving. This is certainly not my comfort zone but I’m pretty happy with the results so far, and will keep trying to get better at it.

“Way Over My Head”

Almost every one of my conference presentations, courses, half-day sessions has been tagged level-400. Often enough it was even more hardcore than many other level-400 sessions at the same conference. So it shouldn’t be a big surprise to my audience that my lectures often require deep technical knowledge, lots of practical experience and the ability to focus on small details as well as the big pictures for a couple of hours straight (which I know is not easy—I always find it exceptionally difficult to keep myself focused on the speaker when sitting in the audience at a conference).

Nonetheless, often enough I get feedback indicating that I was talking too fast, or going over too many details, or diving deep into a piece of technology and assuming it’s just familiar to everyone. This is something I do way too often. Over time I managed to create a certain distance from the subject matter of my lectures, and through this distance I understand how the audience is absorbing my presentation. Still, predicting how easy or hard it’s going to be for other people to take in a particular piece of information is something I need to work on. And after all, everyone would be much better off if I simply cut the material in half but presented it thoroughly and slowly rather than lose half of the audience half-way through the session.

“Introduction Too Long”, or “There Wasn’t Enough Time to Talk about X”

This is a piece of feedback I’ve been getting recently, and I suspect it has something to do with the way I’m handling “Less Code, More Theory”. As I gain familiarity with a subject and observe it from different angles, there’s obviously more for me to rant about in the introductory part of my sessions. For example, when speaking about concurrency and parallelism I can often find myself thirty minutes in without even mentioning a specific technology yet—I can just go on and on talking about how parallelism is vital to modern applications.

On the other hand, if I make the introductions too short I’m pretty sure we’ll be getting back to “Way Over My Head” and “Less Code, More Theory”. I’ll have to see how I can incorporate this piece of feedback into my shorter presentations, where there’s little time to spend on a stretched introduction.

“More Code / Demos, Less Slides”

I never believed I’d see this feedback on a session of mine, but apparently my efforts to get out of the live coding comfort zone might have gone a little over the edge for some folks. I know for certain that seeing 30 slides in the row is the most boring thing known to mankind, and I profoundly apologize if my storytelling skills are not up to par with the boredom-inflicting nature of a demo-less presentation. However, I also feel that sometimes not focusing on a particular technology and not driving the point home with a demo is more beneficial if there’s a general-purpose message to deliver.

I can’t promise you that my future presentations are going to have more slides or more pictures, less code or less live demos—but I can tell you this: I greatly appreciate your feedback over these years, and I’m striving to improve with every bit of it.

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

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>