My learnings on delivering technical presentations

Lessons from a first-time speaker on preparing, practicing, delivering, and learning from technical presentations.

Delivering technical presentations

The experience of the inexperienced

I’m no expert

I’ve led and taken part in many group discussions and conducted many interviews with candidates ranging from self-taught hackers to people with PhDs. Other than the first interview I ever gave, I have never found these overly challenging. The thing I always steered away from was public speaking. Even the thought of it creeped me out.

I wanted to get more involved with the open-source community and share what I had learned over my career. Giving talks seemed like the best way to do that, so I finally bit the bullet and faced my fear.

If you’re venturing into the chilling realm of technical presentations, I hope you find that your fears are far from abnormal, along with a few tips and guidelines that help you prepare for the fulfilling role of sharing knowledge with an encouraging audience.

Preparation

Target your audience

Choose a community that interests you. Most communities catalog earlier talks, so learn what has already been presented, identify potentially interesting new topics, and ask people who have attended their events for feedback. Personal experience usually beats something read online.

Choose a topic that you’re passionate about

If you’re presenting on your own time, choose a topic you care about. Unless you’re a tremendously good actor, a lack of enthusiasm shows. A passionate speaker can make even an unfamiliar topic compelling.

Baby steps

Start small. Try a lightning talk if your target event offers one. Ten minutes in front of an audience helps establish a preparation framework for longer talks and makes public speaking more familiar.

Submit the proposal, but do not wait for acceptance to begin. If it is not accepted, turn the work into a blog post, improve the proposal, and submit it elsewhere. Helping even one person is gratifying.

Research

Research belongs in technical presentations. Unless you wrote the thing you’re presenting, you probably are not intimately familiar with it. Even as its author, you may only understand your assumed use cases. Studying the internals can improve the talk and your own understanding.

The slide deck

I was told to plan on two minutes per slide and scoffed. My first ten-minute lightning talk began with roughly twenty slides. Timing it took more than an hour. Two minutes per slide was not so insane after all.

Don’t read the slides. Keep their text minimal so the audience listens to you instead of reading. Use speaker notes for the material you need to cover, include only the code necessary to make a point, and use spell and grammar checking.

Finally, use version control for your deck. Slides take time and thought and should be treated as importantly as any code.

The dry run

Before polishing the deck, ask a peer for a review, ideally someone interested in the topic and comfortable giving honest feedback. Deliver a rough version and use their feedback to tailor the content for the audience.

Practice, practice, practice… and then practice more

Practice will not make a first talk perfect, but enough repetition lets it roll off your tongue when you are nervous. Stand up and deliver the talk to a mirror, a partner, your kids, your pet, or anyone else who will listen. I spent around five hours practicing in different environments and was happy for the investment once I started speaking.

Time yourself

Going over time either leaves the audience wondering what you meant to say or affects everyone after you. For a lightning talk, do not plan for Q&A; for a longer talk, reserve ten to fifteen minutes.

Delivery

Take a deep breath

You’re there. The spotlight, and likely cameras, are on you. You’re staring at people who may or may not be more brilliant than you.

It’s go time.

Start with the obvious

Introduce yourself. Talk about the relevant parts of your history and what you will present. This gets the ball rolling and helps you realize the talk is not so bad after all.

Don’t fidget

Keep your hands out of your pockets. Do not chew gum or sway side to side. Anything that takes away from your concentration or the audience’s ability to concentrate is a bad thing. Talk with your hands, though: it can express passion and, according to research, save cognitive load.

Avoid bad speech habits

  1. Do not say “um.” Meaningless filler can disrupt a listener’s train of thought. Practice helps.
  2. Do not turn every sentence into a question. It makes you sound unsure of the material.

Don’t force funny

Some people naturally make audiences laugh. Unless you are one of them, focused content is generally more effective than forced humor. A silent room after an expected laugh does not help your nerves.

Be conscious of your platform

If there is a microphone, be mindful of where it is. Looking back at the screen while continuing to talk can prevent the audience from hearing you.

Be okay with saying “I don’t know”

When fielding questions, do not be afraid to admit that you do not know an answer. Have a way to follow up with the person who asked. Looking into it helps them and teaches you something new.

The after party

Whether you think the talk went well or not, it is over. Conversations afterwards are immediate, useful feedback. If someone starts a discussion about the topic, engage with them and ask whether the content made sense and what questions remain. That feedback helps shape your next talk and preparation routine.

Comments