The Ultimate Guide To Memorable Tech Talks — Part 6: Writing a Talk

Photo by Clark Tibbs on Unsplash

This is Part 6 of a multi-part Guide to Memorable Tech Talks. Visit the outline for more information.

Key Takeaways

  1. Find your style. If you don’t have a style, work on developing one over time.
  2. Don’t stray too far from your proposal submission.
  3. Consider your audience, especially if speaking internationally.

Before you start writing your talk, try to find your style. I’ve like to think I have a skill in taking complex topics and distilling them into small understandable pieces that developers of any level can understand. I know that if someone comes up to me after my talk and told me that they understand a topic that they thought was out of their reach, I’ve succeeded. I try to leverage this in all of my talks. Try to imagine something that you’re innately good at, whether it be a topic or an ability like humor, and think about ways to incorporate that into your talk. It’s ok if you can’t think of anything specific because you can work to develop your style over time.

I’m also someone who likes to keep my talks very technical, or focused on technical topics. There are plenty of speakers who focus on other topics adjacent to tech. I enjoy attending those talks, but I know that it’s not the type of talk I like giving. There’s nothing wrong with knowing your style.

As you write your talk, you may notice that it’s drifting away from the initial proposal you wrote. In most cases, that’s OK. You can change around the order of things, add and remove minor bits of content. Move topics around.

But don’t stray too far. It’s not OK to deliver a totally different talk than what you proposed because your attendees will have certain expectations of what they’re going to hear.

Consider your audience, especially if speaking internationally.

Once, I tried to make a joke about the IRS (US Tax Entity) at a tech talk in Paris and fell flat.

Another time, I was all set to deliver a talk in Prague that I had written for what I thought was a broad developer audience. I had assumed most developers in Prague, like myself, worked at full-time tech jobs at startups or bigger companies.

I was sorely mistaken. When I was explaining my talk over drinks to a local the night before, he quickly explained that no one in Prague worked that way. Everyone worked at an agency, which had different expectations of their time and the type of work they produced. I spent the rest of the evening rewriting my talk to ensure that they were included, and the talk landed well. I got lucky and dodged a bullet, but that may not happen to you.

Make sure that the content on your slides is scaled appropriately. For any text that ends up in your presentation, make sure that there’s good contrast and that your font size is big enough. How will you know when it’s big enough? First, make the text really big. Good. Now, make it even bigger. You’re done. Any screenshots you’re including should also be blown up, with the important parts highlighted. Use arrows, bold colors, etc to make the relevant part stand out and guide people towards what they should be looking at.

When doing a slide layout, put everything important in the top two-thirds of the screen. You never know what the room layout will look like and how the projector will be arranged. In many configurations, most people won’t be able to see the bottom third of the slides.

I like to put my contact information and Twitter handle on the bottom of most slides if it fits. That useful for later reference, or in case a picture of your slides is a hit on the internet.

I’ve heard the common advice that as a presenter, you should speak with as few slides as possible. The trick is not to read off of them. That’s a guaranteed way to be boring. Slides have a life of their own and live on as a useful resource outside of the conference talk. Some of my slides, like the ones on Technical Debt have become much more popular than the original talk with almost 80k views.

Write enough content for the time. Sometimes taking content out is just as difficult as adding in new content. When I proposed a talk on Memory Management to PyCon, I had hoped for a 45-minute slot. Since the conference has fewer 45-minute slots than 30-minute slots, I got a shorter slot instead. It was a challenge to cut this talk down to 25 minutes while still explaining the core concepts of memory management.

It’s common for larger conferences to record talks and host them on YouTube. If that’s the case, your talk will live on without you and continue to be a resource for developers everywhere in addition to the butts in the seat at the actual conference. Speak to the people who are watching this talk later in addition to the people in your audience now. Over the past few years, my talks have amassed over 100k views on YouTube and continue to be a resource to others. One of my favorite aspects of recorded tech talks is they become an asset to people who don’t have the means to travel internationally to attend conference talks.

Continue to Part 7: Practice and Delivery

Skip to:

  1. Introduction — About me and my journey through technical public speaking.
  2. Choosing a Topic — Selecting a topic you’d like to speak about.
  3. Writing a Conference Proposal (or CFP) — A guide to writing and submitting conference talk proposals.
  4. Tools of the Trade — Tools for brainstorming, creating slides, time-management, and more.
  5. Planning and Time Estimation — How to plan your preparation time before the conference.
  6. Writing a Talk — Writing an engaging talk and captivating slides.
  7. Practice and Delivery — Preparing for and delivering on the big day.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Nina Zakharenko

Nina Zakharenko

Cloud Developer Advocate @microsoft, software engineer, pythonista, & speaker. Team #emacs. Previously @reddit @meetup @recursecenter. she/her