Reading Time: 11 minutes

Occasionally, I give talks. I have collated full transcripts and video of those talks, where available, on this page for those of you who would like to revisit them.

This is the second post in a 3 part series about giving talks as a technologist (or maybe anyone, but I’ll stick to what I know).

In the last post, we talked about finding a niche as a speaker. Now we’ll discuss how I craft a compelling talk. This is the way I like to do it, but this is by no means the only way.

In fact, in the conclusion, we’ll talk about why this way works for me, and who it might not work for. In the meantime, here’s what I do:

Crafting the Talk

I don’t craft most of my talks from scratch. Instead, I adapt most of my talks from something I have written in a blog post or a series of blog posts. That said, my process for crafting a talk is functionally identical to one of my processes for crafting a blog post. I start with a blank page, and I do some work.

 1. I list some old topics.

My talks are most useful and most well-received when they take an old topic and break it down in a new way.

Why is that? Well, topics become “old” because they are important, but not fully understood. If we fully understood them, we wouldn’t need to keep talking about them. And if they weren’t important, we wouldn’t put all this effort into talking about them. “Old” topics are too challenging to move on from and also too important to ignore. The programming community is already looking for answers on these topics, so the talks sell themselves relatively easily.

Old Topics:

• leveling up
• refactoring
• giving and receiving feedback

2. What conventional assumption about each topic do I want to challenge?

So I have some old topics: leveling up, or refactoring, or feedback. Now, I try to find the places where people are getting stuck. What are people saying and thinking about these topics that makes them so hard to master?

In old topics like this, we can search for old scripts: common assumptions and conventional wisdom.

Assumptions to Challenge:

• leveling up
  • a different skill from the ones I’m already using at work
• refactoring
  • an “art” (no generalizable metrics for me to use)
• giving and receiving feedback
  • the onus is on the giver to give feedback, and to give it in the “right way”

Do any of these scripts increase people’s risk of getting stuck?

For example, folks may believe that leveling up is a completely different skill from programming itself, and that they can be capable of programming without being capable of leveling themselves up. They think about this when they get stuck while leveling up.

Folks might believe that refactoring is based on feel, without quantifying useful metrics about when and how it might make sense to refactor a large system. So they feel confused and nervous when faced with the option of a complex refactor.

Folks might believe that the onus for giving feedback is chiefly on the giver rather than the recipient. So they worry about framing their feedback correctly to prevent other people from getting mad at them, and that stresses them out. Or they’re trying so hard to get better and they don’t understand why people aren’t giving them more feedback to help them do that.

If a script seems to increase people’s risk of getting stuck, then maybe something about that script is inaccurate. So I look for opportunities to challenge these scripts. Why do people think this? Do people know why this assumption is ubiquitous? Where did it come from? What purpose did it serve? Is it accurate?

And if it’s not accurate, what would a convincing counter-narrative look like?

Assumptions to Challenge:

• leveling up
  • a different skill from the ones I’m already using at work
  • A skill I already use at work, and can tune up
• refactoring
  • an “art” (no generalizable metrics for me to use)
  • We can use some heuristics to decide when is an opportune time to refactor
• giving and receiving feedback
  • the onus is on the giver to give feedback, and to give it in the “right way”
  • The onus is on the receiver to signal that they truly welcome feedback and would respond positively to the surprising news that they need to get better at something

3. What “try it yourself” moments do I want to create?

When I was little, my mom got me a subscription to Highlights magazine. The magazine had stories, comics, and advice for children.

I would rip the cellophane off each new issue and immediately scour the table of contents for the crafts section. That was my favorite part: in there, I could get new ideas to try out for myself.

I want people to come away with from my talks with experiments that they can try for themselves, too. If I’m going to challenge an assumption that people have leaned on for a long time, I need to be convincing. People often aren’t convinced by all the data in the world. People often aren’t even convinced by stories. How are folks most effectively convinced of things? Through their own personal experience, of course. That’s why I provide the audience with tools that they can use to test the assumption I’m challenging.

For example, in my talk about leveling up, I give audiences four new things to try:

“Try it yourself” moments:

• leveling up
  • a different skill from the ones I’m already using at work 
  • A skill I already regularly use at work, and can tune up
    1. Develop a specific vision
    2. Rely on discipline
    3. Start with questions
    4. Take care of others

I don’t have a specific number in mind of “try it yourself” moments to create. That said, somehow it ends up working out in the 3-6 range for most of my talks.

4. How do I make those “try it yourself” moments memorable and accessible?

If you look closely at the list we made above for leveling up, you’ll see a rudimentary outline around which we can craft a blog post or a talk.

Now, it’s time to string all of the pieces together into something engaging and memorable.

This is frequently the hardest part. I usually start with a talk that follows a series of steps:

• Beginning
  1. Describe the assumption people are making about the topic
  2. Invite the audience to question the assumption
  3. Point out the problems with the assumption
  4. Explain the impact of those problems (for example, folks frequently getting stuck)
  5. Point out a need for solutions to those problems
• Middle
  1. Reframe the topic to challenge the original assumption
  2. Explain how others can apply this reframing in their work with the “try it yourself” moments
• End
  1. Restate the assumption and the problems with it
  2. Restate the reframing
  3. Restate the “try it yourself” options
  4. Thank the audience for their time

This is a starting point. I find myself amending each talk to depart from this a few times. I always want to make sure that I still have a beginning, a middle, and an end, and that I always provide some kind of review of the lessons from the talk within the conclusion.

I include examples to support each “try it yourself” moment. This is so important that, if I have to choose between an example or a description for brevity, I choose an example. Sometimes this is a code example, a figure, or a graph. My examples often end up including personal stories. I especially like to include stories about times when I messed up. I remember that the purpose of the talk isn’t for people to know about me, or anything I’ve done, or how badass I am. The purpose of the stories are to make the experiments memorable, and people like stories where the main character overcomes adversity. The best “try it yourself” stories are the ones where the experiment I’m recommending helped me fix my screwup (or would have helped me fix my screwup, if I had known about it at the time).

5. Where can I exclude extraneous information?

Once I have finished working through the outline, my talks usually run long. The first fix: tighten up my introduction. The introduction of the first draft meanders while I figure out how to get to my point. With the hindsight of having written the talk, I can go back and remove unnecessary connective tissue from the introduction.

If the talk is still too long, I revisit each “try it yourself” moment where I include both a description and an example. I ask myself: in the absence of this description, would the example alone suffice? In about 60% of cases, it does. So I pull out the description. People prefer plots to expositions anyway.

Finally, if it’s still too long, I mark each piece of the talk as ‘essential’ or ‘supportive.’ Essential: the conclusion of the talk contains surprises for the audience without this part. Supportive: I still think we need this piece, but if I omit it the audience won’t hear the conclusion and think “Wait, what?”

Although I still think the ‘supportive’ pieces have to be in the talk at the time of writing, when I’m on the clock onstage, I often realize in that moment that I don’t quite need them. So I have them marked as things that I can strip out if I get behind on time. So far, I have not run over on a talk timer.

Conclusion

I don’t craft most of my talks from scratch. Instead, I adapt most of my talks from something I have written in a blog post or a series of blog posts. That said, my process for crafting a talk is functionally identical to one of my processes for crafting a blog post. I start with a blank page, and I follow some steps. You could try similar steps like this:

1. List some topics that your audience has been talking about for a long time
2. What are some old assumptions people have about these topics? Find the ones that seem to pop up when folks are getting stuck. Do you think these assumptions are accurate? If not, what might you replace them with?
3. How might you test that assumption with some experiments? Come up with some ideas to try, and think about a pithy phrase that you can use to share each one with your audience. I don’t aim for a number here, but I consistently end up with more than 2, less than 10.
4. How might you string together those experiments in a narrative that appeals to your audience? I have a starter outline that I use for this, but I don’t hesitate to depart from it if I want to. I also look for a supporting example for each experiment.
5. Is there any extraneous information in this talk that you can remove? Folks stay more engaged in a tight talk.

And now, the disclaimer that I promised you in the intro: my talk outlining style won’t work for everyone. You’ll notice that it’s very demand-driven: I choose topics that people have been talking about for a long time, I find the pain points in the ways people are talking about them, and I create a talk that endeavors to alleviate those pain points. I do this because the thing that motivates me to speak and write is the opportunity to make things easier for others. What I’m making easier for others is secondary. Getting people to know me, like me, or admire me aren’t super important to me (though they used to be).

If you have a particular story that you want to tell the world, or a particular topic that you’re dying to talk about, don’t outline your talk my way. Talk about the thing you want to talk about, in the way you want to talk about it. Only you can be the best you. So be the best you.

I can’t wait to see your talk :).

If you liked this post, you might also like:

The rest of the behind the scenes series (Live coding! Podcasts! Parrot photos!)

The leveling up series (Techniques to build your programming skills!)

Contributing to open source (an oldie, but maybe worth a glance?)