10 ways to ruin a lightning talk

I'm submitting a lighting talk today for an upcoming SRECon. I haven't done a lightning talk before, and the format is relatively unforgiving. It comprises 14 slides that are displayed for 15 seconds each and auto-advance, leading to a very stressful 4-minute presentation.

As I did some research and watched a lot of these talks, I started noting the things that just didn't work for me as I viewed them so I could avoid them in my own presentation. And so, without further delay, here are 10 things that just might tank your talk.

Talking too fast

This one is probably obvious, but if you imagine the listener is not a native speaker of your language or is hard of hearing, it reinforces the need to talk at a moderate pace. But even if not, give the narrative plenty of room to breathe by keeping the words per minute down. I learned that an average conversation is 150 words per minute, and a presentation should be slightly slower than that.

Too much material

Whether or not it leads to rushing through the slides or not, covering too much ground is overwhelming for the audience. Teach one simple lesson well.

Slides with more than 10 words

There's an old saying about presentations: People are either listening to you or reading your slides, so maybe don't give them a lot to read.

Inconsistent Delivery

In some presentations, the delivery is so uneven that it is disconcerting. Some slides are busy and rushed, and some slides are sparse and slow. In a few cases, the speaker awkwardly waits around for the slide change. Or the speaker starts to get behind and rushes through dense material until they hit a more sparse slide. This has the effect of weakening the overall message, because it appears that the speaker is not adequately prepared.

Timed moments

In some talks, it's clear the speaker is working up to a big concept—an "aha!" moment. But that moment requires the slide to appear in synchronization with the narrative. In almost every talk I saw where someone tried it, they missed the timing, and the moment lost all that extra impact. It might have even made it a harder for the speaker to make the point.

Abstraction Analogies

Numerous speakers have used analogies to create an abstraction for a complex topic so that it can be covered at a more basic level. Examples I saw included using food, animals, music, or other narrative devices to try to simplify the underlying concept. The problem is that the audience (engineers, in my case) immediately start deconstructing the abstraction to understand it more clearly, and in the process, get behind cognitively and lose awareness of what the speaker is actually trying to say. I think the point here is that these kinds of technical talks are for the benefit of very capable engineers. We shouldn't need another layer of abstraction—even a simple one—to process the information.

Offbeat humor

It's always a risk when presenters try to use some kind of offbeat comedic theme, like a love of superheroes or dogs, and incorporate that as a major part of the narrative. It's even trickier if that theme is contemporaneous, as it might not age well. But back to dogs. I have a mild case of cynophobia, an irrational fear of dogs. If I see a dog motif as a major theme for a talk, I am likely to feel alienated and excluded. I will also be trying to overcome my feelings about dogs instead of absorbing the brilliance of the underlying point.

Complex charts or architectures

There should be no complicated charts or diagrams. The audience has to read and understand each slide in under 15 seconds while someone is talking at the same time. A 2x2 grid or simple chart format is probably OK. On the other hand, building a complex concept additively by starting with a simple drawing and adding to it over several slides worked really effectively.

Tired tropes

Using tired tropes like engineers don't test, managers are dumb, or agile is risky. Just imagine that the target of the trope is your audience, and they are otherwise predisposed to love what you are saying. Unless shining a light on some part of this trope is central to the theme of the talk (and handled very sensitively), it's better to leave it out.

Conclusion

A wise old saying about presentations applies here:

The talk isn't really about what I want to say, it's about what the audience needs to hear. Those are often two different things.

Most of my learnings revolve around the same concept. As the speaker, I am responsible for bringing my audience through this journey. I need to be aware of what kind of cognitive load I am placing on them throughout the talk. I need to understand what dynamics will be most effective for them to consume the content. I need to make sure the content is as concise, literal, and simple as possible. The ten items listed here, more often than not, make it harder for the audience to succeed.