cmatskas

Getting started with public speaking, a guide for technical people

Christos Matskas -

Hello new and seasoned speakers! Let's start with a definition on public speaking:
Public speaking
Speaking at conferences, user groups or anytime you have to stand in front of people and talk about something in a structured way.

And the [Merriam Webster](https://www.merriam-webster.com/dictionary/public speaking" target="_blank)dictionary definition of Public Speaking:

  1. The act or process of making speeches in public
  2. The art of effective oral communication with an audience

It's funny how context makes such a big difference. If you're at the pub/bar/coffee shop with friends/colleagues and the conversation happens to turn technical you could spend hours talking about a "technology, language, methodology, pattern" or a project without a second thought. Now, take the same people and put them into a room and yourself behind a podium with a projector and the dynamics change so much that you could find yourself with the well known "stage fright" struggling to talk about the exact same subjects. Being on a stage, standing in front of people is the part that most people dread about public speaking, the formality, and responsibility that comes with it. For technical talks there is the added pressure that attendees have some expectations and they anticipate to learn something new from you.

Public speaking is undoubtedly a daunting and intimidating experience. There are very few natural born speakers that have the charisma to captivate audiences no matter the subject or the context. For most of us, it requires a lot of practice and experience to get to a level that we can comfortably stand in front of anyone to talk about a subject. Eventually, public speaking could be turned into something exciting and fulfilling both for the speaker and the audience. Everyone has to start somewhere but it helps knowing where and how to get started. As I was gathering the material for this post I suddenly realized that there are far too many things that you need to consider and many moving parts that can become an obstacle in delivering a successful talk or demo. The key to overcome most of these is preparation and awareness. Experience also plays part because the more you do it the more chances are that you'll come across odd situations and the only way to come out successful is to just do it and go with the flow. Because things will go WRONG!

If you're new to speaking or you're interested in getting involved with public speaking, then you may find the following resources useful:

I decided to break it down this blog post into a small series as otherwise it would have been a long essay:

  • Part 1: hardware and software
  • Part 2: Soft skills and getting your talk submissions accepted
  • Part 3: General feedback and (personal) horror stories

This is not a comprehensive guide and most of the stuff I talk about are not new. On the contrary, this blog post is built on the accumulated wisdom and experience of other speakers sprinkled with my observations and experiences both good and bad.

Disclosure: I'm still a "young" speaker and early in my public speaking journey. Although I've delivered over 50 talks in various conferences around the world in the past 3 years. Like everyone else, I had to start somewhere so I hope my personal development and experience can help you too on your public speaking journey.

Hardware


There's nothing worse than having your equipment fail you. It may also not be your equipment but the venue's equipment, like their projector. Or the Internet! Imagine walking into a room full of people and rather than focusing on your delivery you have to spend 10-15mins trying to get the hardware to just work. Seasoned speakers will shake their heads in agreement as they read this. Equipment will always fail so the best way to address this is to come prepared.

What can fail, you may ask? Everything and anything, some of the hardware failures are under your direct control and some totally random and outside your control: power at the venue, air con in the room, Internet access (slow or unavailable), projectors, laptops, microphones, clothes, updates to your operating system (forced updates on Windows), updates to SDKs and tooling etc. I had many of these failures happen to me but in most cases my preparation and positive attitude have helped me overcome any obstacles.

Cables


If you are going to deliver a technical talk, chances are you'll be using a projector. Since there's no one universal connector to rule them all you need to be prepared for all eventualities. This means that you need to carry your own cables. At minimum a 4/5-in-1 connector that allows you to connect any cable (HDMI/VGA/DisplayPort) etc to your laptop's connector. I prefer to carry duplicates of these, which I've tested to ensure that they all work. You need to make sure that your cables work so make sure you test them as soon as you get them and not at the conference you're supposed to be speaking. This will eliminate potential issues with your equipment being faulty. I also carry spare HDMI cables and a wireless connector. I recently had to use my own cables at 2 different talks and it saved my skin. Not because the organisers didn't have spare cables but by the time the "room monitor" (i.e the person designated by the organiser to assist with your talk) returned with that spare cable (about 10mins) I had already connected mine and was ready through a few slides. In one instance, they didn't even have a spare cable (all used by other speakers) which meant that without my backup it would have been impossible to connect to the projector. Your cables may also help other speakers that may not be as prepared as you and everyone loves a hero. You can be that hero. Conference organisers do their best to provide spare cables but it's better to control the situation. Everyone will be grateful that you managed to resolve the problem and you'll look professional.

Laptops

Do laptops fail? Oh yes, they do! From hardware malfunction to OS corruption to connectors breaking down. Your laptop may die at any point. So how does one prepare for any eventuality? The easiest thing to do is to carry a spare laptop. I have a Surface Book and an older Mac Book Pro or a Surface Pro. I carry 2 out of 3 with me at all times. They have all served me really well with the odd connector and OS failures. Having a spare laptop is the easiest way to resolve these kinds of failures almost instantly. It takes only a couple of minutes to boot up your laptop and resume your demos/presentation. However, it requires that both laptops are in sync and that they can both run the same demos. There's a bit of overhead but I find that the trade-off is worth the extra effort.

Alternatively, you could use a VM deployed on Azure but this would require a solid Internet connection and a working computer so that you can RDP or SSH into the remote VM. I've never used this approach and I wouldn't recommend it because you should never rely on network connectivity for any of your talks (more on this later).

Finally, some speakers prefer to use local VMs for the purpose of demos etc. This is a great solution if you don't want to install all sorts of software, tools, and SDKs on your main machine and want to have a one-button reset strategy (see Scott's post). I've tried VMs in the past and I found them an OK experience. In the end, I decided it wasn't for me. But I'm also someone that repaves his machine every 3 months. You also need to remember that VMs won't protect you from OS or hardware failures.

During my very first talk at DDD Dundee in 2014 I suffered from a projector malfunction. My MacBook Pro's resolution was too high for the poor old projector which meant that I couldn't use it. Within 5 mins I decided to switched to my Surface Pro and was able to deliver my talk successfully and without a hitch. It may not have had the same impact, considering it was a cross platform, .NET Core talk, but no one complained because I was unable to run the same demos on MacOS.

The conclusion here is that you need to find the solution that works best for you. Once you've decided on your strategy, you should practice your Disaster Recovery routine. How long would it take you to switch machines in case of a failure? Are all your notes, demos and slides in sync across both machines? If not, how can you make this as smooth as possible?

Software

Similar to hardware, software can also fail and could severely affect your ability to deliver your talk. Software in this case could be your tools you use for your demos such as an IDE, PowerPoint or your notes application. We're always working with the worst case scenario. So, what can we do to protect against these failures?

Up-to-date software

Make sure that your software is up to date but be reasonable. Don't grab the latest updates to your IDE, SDKs or any other tool unless you've tested is somewhere and it's not close to your talk. As a rule of thumb, I don't update anything 2 days before my talks. There are a few exceptions to this rule, especially if you're working with alpha/beta bits or you're on an Insider preview and the features that you need to install are part of your talk. I doubt that this will be the case for most speakers so the advice stands. Stay clear of any updates if it's too close to your talk.

I've recently failed my rule when I decided to update my IDE on the day of the conference. I was working on a talk which involved Azure Functions and I wanted to showcase the latest tooling inside Visual Studio 2017. Visual Studio updates should not be taken lightly and can sometimes take hours to complete (rare but it happens). I wrongly thought that this specific update would be small enough and wouldn't impact VS significantly but it turned out that that update couldn't complete in time so I switched to my other device in order to deliver my talk. I had a backup and a recovery strategy and it was a gamble that didn't pay off.

Code freeze

This is most likely the most important bit. You need to have a code freeze rule, similar to the software update rule. No changes should be implemented unless you're fixing a bug. However, if you've already done your preparation and you spent time going over your demos, there should be no bugs. And if you avoid updating SDKs (see previous bit) then your working demos should still continue to work in the same environment. You may be tempted to add one shiny new feature or demo. Don't. Stick to your original plan, talk and scripts you originally prepared and practiced. If you're adamant and believe that this bit of code should be added to make your demos better, leave it as optional.

Summary

This was Part 1 of my little series on public speaking. If there are omissions or you feel I didn't cover something in depth, let me know and I'll be happy to add it here. This is obviously work in progress, like the rest of my personal development so all feedback is good. Next, in Part 2 I'll be talking about the "soft skills" required to be a successful speaker and resources to help you with achieve this.