The Tireless Pupil's Talk Prep Primer.

Introduction

A few weeks ago, I posted about my first talk: a session about understanding open-source collaboration patterns at Open Source Summit North America 2024. I also posted a separate journal entry about my day-of experience, which includes some more reflections on being a first-time attendee and speaker.

If you’d prefer to watch my talk rather than read the previous post for context, here it is!

In this post, I wanted to list a few quick points about writing a talk that I’d wish I’d known before embarking on this rather harrowed adventure (to see why it was so stressful, see the previous post.) It’s by no means an exhaustive list, but I hope it’ll be helpful to anyone in a similar boat of being incredibly busy while also prepping for a talk.

Giving a Talk

The research I presented in my talk was part of a project I’d worked on for a Directed Studies course at university a few terms ago. As part of that course, I was required to give a final presentation summarizing my work (and in fact, I presented twice to two different labs!), so I’d already gotten a set of slides done and a preliminary set of notes. However, that talk was primarily targetted towards my contributions to the project, the quantitative statistics and the tooling. It had a heavy focus on rather convoluted statistics and my own report as opposed to the more qualitative findings presented in the final paper. For OSSNA2024, I needed to reframe the talk for more of a general audience and highlight more of the big picture takeaways from our project.

In some ways, starting with an already fleshed out set of slides and a script was both a blessing and a curse. It was great to not have to start from scratch, which would have taken up valuable time, but it also lulled me into a false sense of security and made it much easier to procrastinate on making these more fundamental changes to talk pacing or structure. I applied for OSSNA2024 near the start of January, and heard back with an acceptance in February, so I had two full months to slowly chip away at these updates. Because I felt like I was so ahead of the preparation, however, I ended up only really focusing on my talk in mid-March, which didn’t leave me with enough time to comfortably revamp the talk. I was balancing studying for finals season as well as a steady courseload, and with more urgent assignments and due dates always popping up, I kept deprioritizing talk prep and pushing it to later and later. I ended up having to pull some long, full-throttle days between when classes ended (the 11th) and my talk (the 15th), which was not ideal. I think of myself as a rather organized person who can estimate workloads and plan my time fairly well, but even I really dropped the ball on this process. If you take one thing away from this post with regards to starting public speaking for the first time, make it this: start earlier than you think, preferably right after you hear back that your talk has been accepted.

I worked on my script and slides in tandem: I think I speak better when I have a set of rehearsed sentences. I don’t do well with just bullet points: I end up either reciting them, stammering while trying to find the right verb, or repeating the same adjectives and verbs over and over. The talk writing process was a cycle of adding a few sentences or a paragraph to my script, adding them to my slides, coming up with a visual, setting up animations, and repeating. I memorized my script (not as well as I’d like) by repeating it over and over to myself until I knew the cadence and connections between slides. I’d set aside half an hour each day to practice with just the script. Some days, I’d take my after-dinner break or lunch break to rehearse as well: my friends once saw me pacing in circles in the hallway outside our club room muttering points to myself for an hour and were genuinely concerned if I was alright. In hindsight, I should have started practicing the script earlier with the slides, since it took some time to get the cues for animations and points right. The first few times I tried speaking with the slides, it felt very unnatural trying to juggle recalling my lines while trying to predict slide transitions.

Something I severely underestimated was how important the structure and the pacing of a talk was. I knew the gist of the raw information I wanted to impart, but it was only after several rounds of feedback from my professors that the talk started feeling more natural instead of like it was jumping all over the place. For example, I’d previously put methodology at the end, since I thought people were more interested in what we were presenting than how we got that information. Later, I realized that sharing the “how” created valuable context for understanding the “what” and as per one of my professors’ suggestions, I moved it near the start of the talk. I also spent a lot of slides at the beginning reiterating various features of GitHub, which sluggishly dragged out the start, especially since the attendees were all open-source enthusiasts and would most probably already use GitHub. As well, my talk was covering collaboration patterns on GitHub, so we’d created a list of these prototypical workflow types. Since I wanted to share as much information about our project as possible, I initially included summaries of all nine. After reading my talk out loud a few times and after feedback from my supervisors, I realized that it’d be painful, but I’d have to cut some of them out. Repetitive, overly detailed deep-dives into a topic aren’t amenable to a shorter talk: listeners start tuning out after the first few points that appear similar at first glance but differ in super minute ways. Don’t linger on any one section too long — try to divide your talk into roughly equally sized chunks for each subtopic. I think it’s easier to keep people engaged when you cover a wider variety of material at a medium level of detail, particularly if some of that information is implications or real-world examples of the initial theory.

I did all my slide design in Figma. I wrote a little post about my experiences using Figma for presentations here if you’re interested in the general workflow. On top of that post, I’d like to add that while Figma makes it very easy to design and share visually-appealing slides, the presentation workflow for serious talks is very much lacking. If you want speaker notes that are synced to the slides, you’ll have to use comments, read from the tiny sidebar, open up two tabs, and use the follow cursor option: not a great experience. I ended up just memorizing my speaker notes and running from memory and the slides, but it would have been a nice safety net for my first ever talk.

On the topic of slide design, remember to visually highlight the key points you’re making orally. For example, I tended to click through a series of bullet points talking about a graph without pointing out what part of the figure the point was referring to (e.g. ’the isolated nodes’ → should change the colour of or otherwise point out the bar chart for the ‘size 1’ nodes) I would also sometimes make summarizing statements or talk about implications without writing them down on the slide, as I felt they were natural conclusions to draw from the rest of the points on the screen. It’s helpful to make these TL;DR lines explicit, though, and I got a lot of head-nodding and sneaky-phone-camera-picture-taking when I clicked into one of these points.

One of the most helpful steps during this talk writing process was running through my talk and getting feedback on those runthroughs. If you have supervisors, mentors, or even just willing friends, it’s very helpful to sit them down and rehearse to get a sense of how the talk feels, in terms of pacing, content, and depth. I recorded an early draft runthrough and shared it with my professors, who gave me plenty of valuable advice for where things felt too slow or where things needed more highlighting. This is why starting early is also so critical: more time means more runthroughs and more actionable improvements between runthroughs. I really wanted to present this talk to my friends to see what they’d think of it and if they could follow it, since they come from an earlier stage in their career and have less exposure to open source, but I ran out of time.

Conclusion

I think there’s still a lot I need to learn with regards to architecting a talk, defining its purpose and takeaways, finding my voice, and learning to speak with more confidence. I don’t have a lot of experience with public speaking — I quit my school’s debate club after one meeting — but it’s something that I want to work on. When I envision my future career, it involves a lot of mentorship and knowledge sharing, and clear communication, particularly verbal, is a skill that’ll aid me do that more successfully.

If you want more concrete advice on writing a talk, I’d highly recommend Mercedes Bernard’s series on conference speaking. I also found Ines Montani’s page on making beautiful slides good inspiration, though their style might be a bit over the top in some fields.

This will be my last OSSNA 2024 summary post, but I wanted to extend one last thank you to the organizing team and the Linux Foundation for letting me break out of my shell and give my first talk. I couldn’t have asked for more inclusive and comfortable conference to start my public speaking career.