https://www.youtube.com/watch?v=9vS7TbgirgY

Speaking about Speaking, Part 4 — Giving the Talk

Randy Shoup

--

This is the fourth in my series of posts on giving technical conference talks. We have discussed preparing yourself, organizing your content, and preparing the stage. This is now about giving the talk itself. It’s Show Time!

Tip 1: Make Connections

One nice thing to do is to make a few connections to the audience, the locale, or the institution. It makes the talk seem more real, and definitely gets on the good side with the audience out of the gate.

In 2002, after a long hiatus, Robin Williams returned to his standup roots with a tour across North America. In one of my favorite DVD sets, he both shows the value of connecting with the audience and demonstrates his unique mastery of in-the-moment stream of consciousness. Most of the second DVD is a series of location-specific riffs on each of the cities he visited in the tour. He makes fun of Seattle’s coffee obsession, Portland’s famed hipsterism, Minneapolis’s “Habitrail” of interconnected tunnels between buildings, Chicago’s hearty cuisine, etc. He has each audience in stitches, not just because he is a hilarious standup comic (he is), but also because he connects with each audience.

Sometimes one of those connections ends up making an excellent extemporaneous intro to your talk. Recently I gave a talk at the UMN Alumni Center, one of the most architecturally interesting buildings I’ve ever been in. The AV engineer, who had worked at the university for decades, had been pointing out to me all morning a ton of details about the building. Since the talk itself was about microservices architecture, this provided fodder for a fun intro, and enabled me to make a respectful nod to legacy technology (in the physical form of the 50-foot-tall, 70-ton brick Memorial Arch from the original sports stadium on that site, mounted at a canted angle on one side of the massive space).

Image source

Tip 2: Pick Up the Pace

One of the best unintentional experiments I conducted in speaking was a talk a few years ago at CraftConf in Budapest. I was giving a 50-minute talk I’d given a few times before, but I had neglected until the last minute to notice that the CraftConf slot was 40 minutes. Uh oh — what to do? It maybe wasn’t the smartest thing, but rather than do surgery on the talk, I just decided to pick up the pace. I spoke at a more rapid clip, and didn’t pause as often for extra explication. Well, that talk went great — super high-energy both for me and for the audience. It raised my adrenaline level and forced me to focus on making the points quickly, clearly, and concisely. It worked. So now I do this intentionally.

I don’t try to cram the same number of words into a shorter time; instead I concentrate on using only the most important words — the ‘minimal viable talk’, if you will.

YMMV. If you are already a fast talker (like the wonderful Inés Sombra, famed for her blazing speaking speed), you might not want to go even faster. Particularly if you are a speaker who tends to speed up when nervous (this is not Inés, BTW; she’s just as fast in person :-), you might want to concentrate on slowing down.

Tip 3: Pause for Emphasis

I’ve just recommended going faster, and now I’m saying the opposite? Well, if you want to really emphasize a point or a phrase, a great “verbal underline” is to say your point clearly, then pause for a beat or two. For extra emphasis, you can repeat the point or the last few words.

This works particularly well in conjunction with a “tweet slide” — a slide with a single phrase or statement meant to illustrate a point standalone.

https://www.youtube.com/watch?v=Qa25xSpYGb4

Tip 4: Be Straightforward

I am most comfortable giving talks in a conversational, colloquial style. This makes me more relaxed, and I think, helps the audience enjoy and retain a bit more. It’s definitely not formal or academic.

Since I’m often talking about architectural ideas that can seem a little complicated and are definitely not yet in everyone’s experience (recently microservices, joins, and sagas, for example), I intentionally use colloquial language to make the ideas more accessible.

I’ll say, though, that this style absolutely does not work for talks for mostly-non-English-speaking audiences. California idioms don’t translate very well into Mandarin or Japanese, and if there is a simultaneous translator (as there sometimes is at major conferences in Asia), you are *not* helping the translator by being clever. Now is the time to slow down substantially, use straightforward words and phrases, and avoid jokes and clever turns of phrase.

Former President Carter once opened a speech in Japan with a joke. He got immediate and uproarious laughter, and was clearly pleasantly surprised that his joke had landed. It turns out that the translator had said “President Carter told a funny story; everyone must laugh.”

Tip 5: Be Honest Without Being Insulting

There’s almost always more than one way to do it. You and your team have chosen a technology that works for you, and so you’ve implicitly chosen not to pursue other competing technologies. You’ve chosen X database instead of Y, or W container orchestrator instead of Z. When I am watching a talk, I prefer it when the speaker is clear about what they chose (and, ideally, why). That integrity makes them more credible, even if I would have made a different choice.

But when you say what you chose, please be respectful to the other choice and the people who made that choice. This can be a fine line to walk, especially if you (as I do) have strong, passionate feelings about technology choices, and especially if you (as I do) think that some choices are simply wrong.

I’ve found that if I stick to a “just the facts, ma’am” approach — we chose this for these reasons — that’s by definition unassailable. After all, we did choose that thing, and we did choose it for those reasons :-).

Tip 6: “Does This Make Sense?”

Enabling fast feedback is a critical part of the Lean approach to software development; after all, continuous learning is the Third Way of DevOps. Feedback in the moment allows us to notice a problem, and quickly adjust and improve. One way I solicit instantaneous feedback from the audience is with questions like “Does this make sense?”. After a particularly involved point or at the end of a section, I try to take the audience’s temperature. Audiences at different conferences, in different countries, on different days, can be very, well, different. So a way of explaining that nails it for one audience might fall flat for another.

If I see the audience mostly smiling and nodding, all good. When I see the audience looking quizzical with polite interest, I know I need to go back and make that point in another way.

Tip 7: Audience Participation

I used to think getting members of an audience to raise their hands or say things was a gimmick, and then I observed how well it can work when used in a targeted way. Protestant preachers are famous for their infectious call-and-response, and rock groups regularly get audiences to clap or chant on cue.

Often now, when I’m suggesting a technique to address a particular widespread (I think) problem, I often ask people to raise their hands if they can directly relate: “Raise your hand if you have more people and resources than you have things to do”:

https://www.youtube.com/watch?v=Qa25xSpYGb4

(For the record, no one has ever raised their hand in answer to that question. But it does get a response.)

This technique builds empathy with the audience, and also tells you a lot about what things the audience is going to be most and least interested in in your talk.

Sometimes this doesn’t work the first time, though. Recently I asked an audience “Are there any lessons here?”, and heard crickets. So I smiled and repeated “Help me out — Are there any lessons here?”.

(The amount of audience response you can expect varies a *lot* in different parts of the world. Right before going on stage at Build Stuff 2014, for example, in my first trip to Lithuania, organizer Greg Young told me to expect that Scandinavian audiences will give basically no reaction during a talk, and often won’t ask questions afterward. Knowing that helped a lot, since it ended up being entirely true, and I otherwise would have been thrown off my game by a sea of seemingly dour, uninterested faces.)

Tip 8: Hands Free

I’ve learned to try not to hold anything in my hand which is not either a clicker or a mike. It’s OK to take a drink, of course, but put it back down when you are done. I once held a coffee cup in my hand for basically an entire talk, and I got a lot of comments that this was distracting.

Tip 9: Refer Back

Most meetups and conferences have more than one speaker, and there is also often much thought given by organizers to the ordering of the talks around a particular theme or track. So unless you are the first speaker, there are often previous talks that say complementary, or even identical, things to yours. This is not a bug; it’s a feature.

First, having two talks that emphasize the same point makes that point stronger and more memorable. But also, you can now refer back to the earlier talk with “As Caitie pointed out in her talk …”, or “As Inés eloquently put it …”. This is a nice acknowledgement of the previous speaker, and also helps connect the talks together for the audience. If you find yourself disagreeing with a previous speaker, you can also point that out — respectfully and goodnaturedly.

Concluding Thoughts

Thanks for reading this far. In the next installment, we will talk about taking and answering questions after your talk, and then we will conclude the series with some suggestions for learning and improving for next time.

--

--

Randy Shoup

Dad | Cook | Speaker | Engineering leader (eBay, Stitch Fix, Google). He/him.