Why I suck at writing talks with good transitions (and how I’m improving)

Smooth transitions help hold the audience’s attention

Saron Yitbarek has a great post about how improving your transitions can really spruce up a tech talk. Specifically, about how the transition to a new slide should begin before you actually switch to that slide.

The goal is to make slides support your points, rather than having them introduce your points. It’s an important skill to learn for giving talks. Go read her article.

But it’s difficult to remember what the next slide will be

I try to practice this technique in my talks, but I’ve never found it easy. I often have trouble remembering exactly which slide comes next, and it’s hard to transition when you can’t remember what you’re transitioning to.

This problem was exacerbated by some technology choices I made early on. Like many other programmers, in composing my early talks I looked down my nose at dedicated presentation apps such as PowerPoint or Keynote.

Instead I tried to “keep it simple”. I used presentation tools such as Beamer, S5, or RevealJS, that would enable me to use a text editor I was already comfortable in to write my talks, and generate either PDF or HTML slides.

The problem here is that in most cases, these tools didn’t give me the ability to see what slide was “up next” on my laptop screen.

A full-featured presentation app can help

By contrast, dedicated apps like PowerPoint and Keynote have a Presenter View which shows the current slide, the next slide, and any speaker notes you’ve added. You can set your laptop screen to show Presenter View, and the main projector screen to showing just your current slide.

Now, there’s an argument that used to keep me from using these kinds of tools. It goes like this:

“Someday, you might have a problem with your laptop and have to present your slides on someone else’s machine using just the PDF backup. And anyway, shouldn’t you know your talk well enough to dispense with crutches such as Presenter View? Maybe you’re just not practicing enough.”

This argument used to have a lot of weight for me. But my views have evolved over time.

In particular, the idea that you should memorize your talk perfectly is an implicit argument for doing few, painstakingly prepared, carefully rehearsed talks.

But that’s not the kind of speaker I want to be. In fact, that perfectionist paradigm of speaking has held me back. I’d rather be the kind of tech speaker who can quickly throw a new talk together and not get hung up on imperfection. If I’ve fully memorized a talk, that means I’m “resting on my laurels” instead of learning and iterating and flowing with ideas.

And if that means leaning on tools to help me get through relatively less-rehearsed material, I’m OK with it.

Abrupt transitions are a byproduct of bullet-driven writing

The other reason I’ve had trouble with transitions comes from how I typically compose my talks. Usually I collect a bunch of bullet points around the topic I’m tackling. Then I gradually massage the points into an outline, and then create slides for the outline points.

The problem here is that when you do bullet-driven talks, they naturally turn into a set of semi-connected points, each one introduced by a new slide.

Recently I had a particularly bad experience with a talk. I was on a three-city conference tour, giving a presentation I’d delivered several times in the past. I was pretty confident in it, since it was a “polished” talk.

But once I was on stage in the first city, I found myself with low energy, and constantly losing my place in the talk. I walked off that stage feeling deeply disappointed in my own performance, and questioning whether I could in good conscience give that presentation again.

So build your talk around a narrative

After agonizing over it for a few days and talking it over with some friends, I finally discovered an underlying thread that I’d never identified before. I quickly rewrote the talk to periodically re-emphasize that thread. And I re-ordered sections of it to have a natural flow, guided by the thread.

As soon as I started giving the new version of the talk, I knew I was “back”. The energy was there again, and the post-talk audience reviews showed a clear and marked improvement in how it was received.

The key to the change was in identifying a clear narrative through the material. Since then, I’ve been focusing more than ever on putting the narrative first, and getting away from the “bullet-driven” approach.

Outline your story, not your points

One thing that has particularly helped with this is a technique I learned while studying copywriting. Somewhere, I ran across the advice to write your content subheadings so that even if someone just skims the headings, they will still come away with a summary of the whole piece. Instead of subheads full of pithy wordplay, have them clearly and plainly summarize the paragraphs that follow.

Recently I needed to restructure another of my talks into a ten-minute version. Instead of pulling out slides which represented the “important points” from the main talk, I first opened up a blank, full-screen Markdown editor. In the editor, I wrote out ten sentences (one for each minute!) that together told the story of the point I wanted to get across.

It looked like this:

- Refactoring and redesigning software is hard.
- I’ve started seeing an underlying pattern to the hard.
- OOP was supposed to be about messaging, 
- But messaging semantics are impossible in the C++/Java/Ruby/etc.
- As a result our systems are full of processes modeled as transactions.
- This exhibits as BOTH splitting processes across multiple objects, and as objects containing parallel “stories”
- Implicit to message oriented is process oriented
- What if we structured our systems, not by actions, not by data globs, but by process?
- What if we used this as the heuristic for refactoring?
- …what if we applied this to our lives as well?

Once I had my rough storyline, I transferred these points as named slide sections into PowerPoint. Then I copied/added slides that would support each step in the story under the sections. In the process, I also edited and simplified the story headings.

The final presentation, with slides collapsed to just show the section names, looked like this:

(By the way, you might have noticed I’m using the same technique for the subheadings in this article ????)

Lean on tools, tell a story, and let slides be illustrations

In conclusion: great transitions can make a big difference in how your tech talk comes across. But for some of us, they don’t come easy. The two main strategies that have helped me improve my transitions are:

  • Don’t be too proud to lean on “business-y” presentation tools like Presentation View and speaker notes.
  • Write your outline as the steps in a story, not as a list of points you want to get across.

I hope this helps someone out there.

Leave a Reply

Your email address will not be published. Required fields are marked *