A Q&A on Speaking

Today I did a live stream on Twitch of working on one of my upcoming talks. I also fielded a few great questions on getting into speaking, so thought I'd write them down here. The video is embedded at the end of this post, too, if you'd like to see some Keynote tricks and hear my spontaneous answers.

On to the questions!

What do you think was your gateway to being able to speak at conferences?

For me, it was speaking at local meetups first. I was fortunate that I was living in Portland in the middle of the "Framework Wars" when I was first getting interested in speaking, so there were tons of meetups and they were all desperate for speakers. There are still plenty of meetups all over the world, though. Find one and offer to give a talk. You don't need to be an expert; just try to teach one concept in about 25 minutes.

One caveat here: not everyone gets started with local meetups. Some people just jump straight into conferences. This was the case for my friend/boss (fross?) Kim Maida. So, don't be afraid to go big right out of the gate.

While creating your talk do you focus on a specific part of your subject or try to cover all the nitty-gritty about it?

One thing I've learned with building talks is that less is more. Most of us try to cram way too much into a talk. Try to only have one to three main points you want the audience to remember. If you're doing a step-by-step walkthrough, scale down the scope of what you're trying to demonstrate so people can follow without losing interest or getting confused. Confusion and boredom turn to frustration and you've lost them.

So is it more about making your subject accessible and the form of the talk? Trying to break the entry barrier or something?

John Papa once told me, "Any talk under 30 minutes is not about the code. It's about making people feel like they can do what you're doing." People can always go rewatch the talk, review your slides, and look at your sample code. What you're trying to accomplish in a typical technical talk is something like, "Hey, I learned this cool thing, you can learn it too!" There are exceptions to this, of course, but I find the best talks have elements of storytelling and discovery. Don't just tell me the steps to do something, walk me through the learning process.

Do you create animations/gifs for a complex flow/diagram to add more impact?

Definitely. Visuals help people learn. This took me a long time to build to because I'm not artistic by any stretch of the imagination. I learned a ton from doing joint talks with both Kim and Mike Ryan about visuals and animations. Keynote's UI is very counterintuitive, but it is capable of building beautiful animations.

To see some examples, watch me and Mike's groupBy talk from RxJS Live and basically any talk from Kim. Her talk on authentication at AngularConnect 2019 is a great example.

Before doing your slide, do you write down topics and what you want to show and explain or do you start doing the slides right away (and kinda creating the talk at the same time)?

Yes, but first I work on the code behind the talk. Explaining something and coding something are often very different, so I want to make sure I am teaching the way that I have thought through building the sample app, not by how I might casually explain something.

Once the code is done, I start by making a bunch of notes in an app like Ulysses and then building an outline. (Don't get hung up on the tool; I used Google Docs until very recently.) As soon as I have the basic idea of the flow of the talk, I start adding very basic placeholder slides. I literally mean black and white slides with the piece of the outline on them. This lets me start to visualize how I want the talk to flow.

Pro tip: don't jump to styling your slides too soon. Choosing fonts, colors, images, funny gifs, and all that are great ways to bike shed and distract yourself from the content of the talk. They are also extremely hard to change once you've got 70 slides, so wait until the talk is almost completely hammered out.

So you're writing down the structure/ideas for the topics you want to talk about then build the slides?

Exactly. I flesh out an outline and then build very basic slides to start structuring the talk.

What things you do once you have the first version of your slides? Rehearsals?

As soon as I have some semblance of a complete talk (structure and flow, but not necessarily a full talk and certainly not styling), I start practicing it. I am very liberal with adding slides in the beginning, because I want my visual cues to sync up with my teaching points. I'll start rehearsing and get a natural "feel" for when a slide is needed. This "feel" is usually driven by thinking about what I would want or expect to see. I like concrete examples, sample code (but not too much!), and visual aids, so I try to sense when those would help. If you find yourself talking about an abstract concept without an accompanying concrete visual, that's a "slide smell."

Do you have all your talks written out [word-for-word] in case you forget something (or managing time or stressed)?

The only talk I've written out word-for-word was my 5 minute ng-conf 2019 talk. Five minutes leaves zero time for "um," "uh," or rambling of any kind, and 1500 people is too many to mess up in front of. I painstakingly chose every single word of that talk and exactly what would be up on the screen. It is as close to perfect as it could be.

I basically never do that normally, though. I practice talks a lot to nail down how I want to word things. I have a tendency to ramble or repeat myself or talk in circles, so I choose my wording and practice it.

In the case that I need to remember to say an exact phrase, number, or credit someone specific — a critical detail — I will add it to the presenter notes. This is somewhat risky, though, as not all venues have a setup that is conducive to you seeing your notes while presenting.

Do you have time to check the equipment before your talk in the venue?

A conference worth its salt will have a tech check either the day before or the morning of your talk. Often they will also communicate with you ahead of time to find out what your needs are and how they can ensure your success. If they don't, don't be afraid to reach out to the organizers and ask questions. One specific tip: a "comfort monitor" is the magic phrase meaning a second monitor on stage to show your notes.

What are the main mistakes new speakers always do and should avoid doing?

The biggest mistake new speakers make is not practicing on camera ahead of time. Sitting in your comfy chair behind your keyboard is not even close to the same experience as speaking on stage, so we find that getting on stage for the first time causes us to do all kinds of crazy things. We move awkwardly, we're really self-conscious, we forget how to project. I found that I always swayed back and forth like I was doing lazy Jazzercise and held my hands at my chest. Short of practicing in front of people, the most effective way to beat this is to set up your phone or a web cam and stand up and practice in front of it (while it's recording, of course). Watch how your body moves, listen to your volume. Movements and tone have to be exaggerated for your point to come across. It will feel awkward and weird to watch yourself at first, but that's good. It'll pass and you'll see how you can improve.

What tips have you to stop thinking of what people looking at you are actually thinking when doing your talk?

Public speaking repeatedly tops the charts as people's number one fear, even over death and zombies. Jerry Seinfeld has that joke about how people would rather be in the casket than giving the eulogy. This means that your audience is overwhelmingly empathetic to your plight on stage. They want to see you succeed. I've seen speakers crash and burn and in some cases it made the audience love them more. The only way to counter this is to come up on stage and act like an arrogant jerk; that puts people in a combative mindset. If you're humble, genuine, and kind, people will forgive you for all kinds of mistakes.