Reading Time: 12 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 third 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 discussed crafting and outlining a talk. Now let’s discuss iterating on an existing talk.¹

Talks Change

You don’t have to give your talk the exact same way every time you give it. In fact, if you do that, you sacrifice the opportunity to improve the talk over time. I view each individual run of a talk as an experiment—a chance to learn—rather than an end product to be judged. This has the convenient side effect of reducing the finality, and therefore the pressure, of each speaking engagement itself.

 1. Yourself as a source of information

Your perception of how your talk went provides useful information upon which to base your planning for the next talk.

We’ve already done some self-reflection about talks while identifying a speaking niche:

If you find yourself giving a talk and sighing with relief when it’s over, that might be a useful signal to consider: why are you so glad it’s over? Would you dread doing it again? What is that telling you: is it the topic, the venue, the audience, or something else?

For folks who spend most of their work time as engineers, speaking usually doesn’t pay a whole lot. So, as far as I’m concerned, we better at least be enjoying it. What are you enjoying about the talk you’re giving? How can you change the parts you don’t enjoy while keeping the pieces you do enjoy?

Via a recording

For most of my talks, I try pretty hard to get a video and audio recording. I do this because the video always shows me things about my stage presence and delivery style that I don’t otherwise notice. Sometimes they’re good things—I noticed this way that I move around the stage. Sometimes they’re things I don’t love, like speaking while facing my slides instead of projecting my voice toward the audience.

There’s another reason to get a video of your talk, if you can. We’ll come back to that in a minute.

 2. Other people as a source of information

Someone is going to hate what I am about to say, and I’m okay with that.

General talk feedback

My position on talk feedback comes from a few places. First, it comes from cases where conferences have collected anonymous guest feedback on speakers’ talks and given it to speakers “as a favor.” Second, it comes from cases where I have taught—teaching a course is, in effect, a thirty hour interactive speaking gig—and the academic administration has collected anonymous student feedback to gauge my performance and, theoretically, help me improve.

I don’t find most of this feedback useful for a few reasons.

1. It’s often vague. From an individual guest, “I loved it!” is a nice thing to hear, but it doesn’t help me improve the talk. It’s the same story with “I didn’t like this talk.” It’s also useless when a venue tells me that “two out of forty people listed your talk in their three favorite talks.” These pieces of feedback are not actionable (and the final one suffers badly from primacy and recency bias, but I won’t beat a dead horse).
2. It skews toward extremes. Guests spend time writing feedback for talks they loved and talks they hated. Those strong emotional responses frequently obfuscate any specific critical analysis.
3. Just because the feedback form is supposed to help me improve, doesn’t mean that the people filling it out share that goal. This is especially apparent to speakers from underrepresented groups who get feedback related to listeners hating the fact that they have a platform at all. Sometimes, the feedback giver’s goal isn’t to help the speaker: it’s to tell the conference organizers or academic administrators to remove this person from future stages because, to this person, that speaker “doesn’t belong” up there. Their screeds about this can’t help me improve. They aren’t intended to. I get this in student evaluations sometimes.

Part of this has to do with the way feedback forms are written. It’s usually some stripe of:

1. What did you like about this talk?
2. What did you dislike about this talk?
3. (Optional obstacle course of rating bubbles for questions like ‘was the speaker prepared’ and ‘did you feel engaged’)
4. Do you have anything else to say?

Now, I have high expectations for the quality of feedback requests. I should: I wrote about giving and receiving feedback six times, and then I spoke about in front of audiences. The above questions? Not a quality feedback request, because they do not convey any information about the feedback recipient’s goals. That segues nicely into the next source of information for speaker feedback:

Specific talk feedback

On occasion, I have made my own feedback forms for my talks and lectures. In this post about teaching a programming course, I shared some of the questions that I asked of my students in my own feedback forms. Here are just a few examples:

 

The questions are specific. They state my goal of improving the experience, and they point to the exact areas where I am looking to do that. A form like this gets useful, actionable answers from the exact same audience that didn’t have much to say in a general feedback form.

Here’s another recent example: It’s a letter that I wrote to several trusted colleagues asking for their feedback on my programming live streams. I’ll include the entire text of the letter here, with a few notes:

Thank you for reading 😊. I’m Chelsea Troy; I live stream development work on an open source React Native app for The Zooniverse. I share my screen and write code, narrating my process the whole way. I stream to YouTube, and I leave the recordings up to watch later, too. # Explaining who I am and what I do

I want to diagram code, write code, and speak about code, in real time, in a way that people find engaging and accessible. I know it’s ambitious. I’m fine with that :). # Stating exactly what my goal is

To that end, I’m looking for feedback. I think that your experience with coding instruction makes you exactly the kind of person whose feedback would be valuable. I’d appreciate your thoughts on what works well, and what could work better, on the streams. # I usually ask for more specific feedback than this. I use a more general request here because I knew this audience to have extensive experience with teaching and mentoring. It’s not a random audience of guests or students.

I created show notes for each stream, with summaries, links to code, and time stamps. Here are the show notes for the most recent stream. If you’d like to see more, this page gets you to the show notes for all of my streams. You can watch whole streams (I use 2x speed for this) or click on the timestamps that speak to you and just watch a few short pieces. # I make it clear that the time commitment doesn’t have to be that big.

I’ll take any feedback. Specific examples where I’d like your thoughts:

1. Is it clear what I am working on? Can you easily tell where onscreen I am working, and what I am doing? One note; I cannot improve the resolution right now, unfortunately. In some cases I could increase the font size, though.
2. Does the stream hold your attention? Does there seem to be a pattern to what is particularly interesting—and what is especially boring?
3. Which parts are especially confusing? Should I stop and explain things more somewhere, or introduce more pauses to talk about the big picture?
4. What do you think of the diagramming in the most recent stream?
5. Are there other techniques I might use to teach as I code more effectively?
6. Does your debugging strategy differ from mine? I think debugging is a super valuable under-taught skill, and I’d like to demonstrate lots of debugging techniques in these streams.

# These questions point to the specific pieces of the streams that I would like to work on right now, and they share my own critique of the work—which signals to others that it is safe for them to critique it, too.

The most helpful feedback format is something like: “At [timestamp] you do X. Have you considered trying Y instead?” The specific example leaves less room for me to misinterpret what you’re referring to. # I ask for specific examples. Feedback like “Have you tried being more [x]?” tends to be too vague to act on. 

Please feel free to email me feedback at [my email address], or DM me on Twitter. 

Thank you so much in advance for taking the time to look at this. I really appreciate it! # I thank people, because they are spending the time they could be watching TV and eating cake to help me get better instead. 

I shared this letter to demonstrate how I elicit specific feedback, but again it segues nicely into the next source of information for feedback:

Trusted peers

I can ask for specific feedback from any old audience and get better answers than I do for general feedback. But even better, in my experience, is to find people who have extensive knowledge of my subject and who have experience with teaching and coaching.

These folks want to help me when I ask for their help; they don’t try to convince me to get offstage. It’s even better if I have a preexisting relationship with these people. Our trust helps them feel comfortable asking me questions and telling me about things I don’t realize I need to improve.

I’m asking for pretty specific people here. I want experience, mentoring skill, kindness, a preexisting relationship…that’s a lot. There are not going to be many people like this in the same place as me, at the same time as me, watching me speak. There are going to be almost zero people like this in a formal education classroom^🖱️.

So I want that recording of my talk. I want the option to share my work after the fact with people who weren’t there who are uniquely equipped to help me get better. This is one of the reasons I live stream to YouTube rather than Twitch: the recordings are up indefinitely on YouTube, rather than the two week limit on Twitch.

When I ask these people, I’m following the guidelines from parts 5, 6, and 7 of this post on who to ask and how to ask questions. I know it seems like I’m shamelessly plugging my posts all over the place in this post, but if you’re into the topic of capitalizing on feedback I’m hoping you’ll appreciate them 😂.

Conclusion

The skill of iterating on a talk leans heavily on another topic we already talk about a lot: feedback. I have two sources of information from which to draw while iterating on talks.

1. Myself: from my own experience while speaking, and from a recording.
2. Others: the audience, usually. I don’t find general audience feedback that helpful, but I do get value from their specific feedback. To get specific feedback, I usually have to ask them in my own forms. What I find even more useful are the thoughts of a trusted and experienced mentor, but I don’t always have those people in the room when I speak, so I try to get a recording to share with them later.

¹I originally planned to discuss preparation and delivery in this post, but I couldn’t motivate myself to write it because others have already covered it.

• Nina Zakharenko covered it (though I disagree with the idea that one source can be ‘The Ultimate Guide’ to anything)
• Dan Lew covered it
• Michael Ernst covered it
• Matthew Gerstman covered it
• Dan Abramov covered it
• Jesse Storimer also made a list of resources for writing and preparing for talks

I invite you to find a piece from this list that speaks to you, and read that in lieu of a piece from me on the subject.

If you liked this piece, you might also like:

This piece on getting folks to help you and answer your questions (not as manipulative as it sounds)

This piece on framing feedback (and the series around it, but especially this piece)

This piece about organizing a conference (not really related, but if you’re into speaking, maybe organizing is also of interest to you?)