Normconf created a lightning talk track of pre-recorded videos, and proposals are open until Oct 1. Since I completely missed the original talk submission phase, I went ahead and submitted a proposal. Then I had another amusing idea later while making tea and submitted another one. And I think readers out there should do similarly!
There’s a specific line in the form encouraging people who have never spoken before, and I’m sure that for the vast majority of people who have never given a talk before, it looks like the most ridiculous dare. This week is dedicated to hopefully giving folk a bit of help to give it a shot.
Yes, giving a talk is scary stuff
Every time a call for speakers goes out, I know with absolute certainty that there’s someone who is doubting that they have anything to contribute. Who am I to talk about any topic in this entire space? I’ve only been working on this a couple of years, I haven’t done something new or interesting. Also it’s hundreds, maybe even thousands of people! Ahhhhh!
I know that there’s at least someone out there having those exact thoughts because the person in the world having them is ME. And I’m not talking about talk proposals from many years ago, I’m talking about Normconf, the very talk proposals I submitted just a couple of days ago.
There are always a million excuses to not participate in community events. I’d like for more people to take the opportunity to ignore that inner voice and give things a shot.
But, but, but, I don’t have anything to say!
The hardest thing about making a talk proposal is figuring out the topic. A proposal is a blank canvas and nothing is scarier than a blank canvas. It’s very easy to freeze up from decision paralysis.
Problems then compound because when most people, myself included, think of prototypical “talks at a conference” we have a couple of memorable genres in mind:
I’ll be announcing this never-before-seen thing to the world!
I’ll be presenting this paper that shows that (P = NP or something important)
I’m going to explain/teach this thing you don’t know to you
I’m some “big name” and I have Opinions about a thing that you’ll want to hear
These are the big keynotes, the flashy product announcements, the “genius research team releasing their work” stories. We remember them because they’re essentially designed from the start to be headlines that grab your attention (and convince you to purchase a ticket). There’s very much a “one expert stands up and unveils pure knowledge to the audience” energy going on.
These expert-led talks all can be very interesting and useful, but trying to emulate them sets a unnaturally high mental bar because, by definition, practically none of us are experts in an area to the extent that we’re even remotely capable to be doing any of those things. Trying to emulate those sorts of talks is an exercise in shoving yourself headfirst into a fit of imposter syndrome.
But if you really sit down and look at a list of talks at a conference, that’s not a majority of the content. Instead, many of the speakers are much more human and closer to everyone else — because they actually are human and like everyone else. The speakers might be experts, or at least “more knowledgeable than average”, but the framing of the talks take on a slightly different tone:
Here’s how me/my team solved this problem that’s been bothering us (and probably bothering you)
Here’s a method we found that’s effective for what we’re doing (that you’re likely also doing)
We learned something because something went terribly wrong and we survived (you might want to be careful too)
I want to share this story/experience with you (because it’s going to be relevant in some way)
Many of these themes are things that someone who’s been working in the field would be able to speak to after only a couple of months or maybe a year or two.
It is very likely that you’ve had personal experiences that fall under one of the broad categories above. Those experiences can become the starting points for potential talk ideas because they’re likely things that other people would want to hear.
But even so, I don’t have anything interesting or new to say
For years and years, I got caught up at this point too. There’s actually no need to say anything “new” to the entire world at all. Instead, you only have to say things that are new to some of the audience — and that bar is mind-blowingly accessible. Within any audience, there’s a big variation in knowledge and experience. The odds that there are people who have never come across what you’re about to say is surprisingly high. Depending on who you’re expecting to show up in the audience, this group might actually make up a majority.
My favorite example of this comes from a QA engineer friend who presented at an ed-tech conference years ago. My friend was presenting “How the QA team I work in [at an ~80 person startup] works with the Engineering team”. The gist of it was that the QA team works closely with Engineering teams throughout the product development cycle to get tests specified, brainstorm edge cases. and discuss how to fix various bugs that come up as work progresses. The core of the presentation boiled down to “it’s better to communicate with each other early and often.”
You would think that a talk about “go talk to your coworkers” would be too simple build a whole 30 minute talk on since it’s obviously common sense. My friend was confident that not one thing mentioned at the talk was some new method or process. Most would’ve have been considered best practice at the time. It’s stuff you can find in hundreds of books and blog posts on the internet. Despite the complete lack of novelty, my friend reported that not only were a bunch of people in the audience taking extensive notes, but there were tons of questions at the Q&A, as well as people coming up at the end saying how brilliant the talk went.
The people in the audience, who might have come from IT departments in local school districts, random startups, whatever, were often struggling within organizations where Engineering maybe sat in another building and would toss code over a wall into QA to test. Most communication was in tickets or emails. The thought of having the teams meeting regularly to work on issues together simply didn’t even occur to many folk. These folk were neither stupid, naive, nor fresh out of school — they were just blinded or constrained by their local organizational history and hadn’t heard of certain practices. Now, those people have examples to use to attempt to push for changes.
The only thing you have to think about when proposing a talk is, what do you want your audience to take away from your talk, no matter how simple or seemingly obvious it is. Will that thing be useful for them in the future?
In my friend’s case, they wanted the audience to walk away with the idea that Eng/QA need to partner closely and have a few example processes to use. They knew that people out there had trouble with it and used their personal experience to give an example. People found it useful and responded accordingly.
OK. I don’t have to be original, but I still don’t know what to talk about
My recommendation is to look in your recent past and try to find a central narrative moment that might be relevant to the conference at hand. Then, see if you can build a story around it.
Essentially, there’s an important point in the story you want to tell — an ah-ha! moment when hours of debugging finally clicks, a release that finally goes out the door, a realization that your whole approach had been wrong and you find another way, the time you were almost about to give up but gave it one last try and things worked out. It can even be a joke punchline you want to land on, a gif you just really really want to share.
That kernel is the climax of your story, your talk-to-be. It’s the thing you want your audience to remember. It doesn’t have to be overly dramatic, or involve big explosions. It just needs to be a meaningful moment that separates a distinct “before” and “after”.
As an example, one quick talk I gave at a the original Data Mishaps Night was centered on “one day I accidentally found a Normal distribution and freaked out because that never happens”. Another time it was “I used a bunch of your products and wrote this big list of bad experiences”.
This time around for Normconf, my idea kernels are “I’ve got 50+ ‘a data pipeline is broken’ work emails just this morning” and “I sometimes write SQL in a spreadsheet”. If either get picked, I’ve got ideas for how to flesh them out into something entertaining.
With that climax point to work around, think about the story leading up to that point. Set the context and scene for the audience, introduce concepts they need. Are there any notable plot twists and turns that happened during the build-up? If you can see a way to take your audience on a journey to your point in the time allowed, you probably have a talk worth proposing.
If all of this sounds vaguely like a “how to write a story” guide… that’s because many talks are simplified stories set to slides. If you set off to tell a good story with a point, you can’t really go wrong.
Afterwards, it’s just a matter of waiting for acceptance/rejection decisions to be made, and then fleshing out the slides and details. The one nice thing about talk proposals is that you don’t have to actually write the talk until you know you’re supposed to give it.
Anyways, this is generally how I approach coming up with a talk idea. Think about what the audience will want to hear, search my experiences for a relevant story point, if it can flesh out into a story arc, propose it.
Other people have their own unique approaches. For example, I’ve known some people who will propose interesting ideas that they’re not quite experts in, with the intention of doing the research and prep work once they get an acceptance. For example proposing “benchmarking various databases in some relevant situation”.
There’s many ways to write and share stories. Find a way that works for you.
Standing offer: If you created something and would like me to review or share it w/ the data community — my mailbox and Twitter DMs are open.
New thing: I’m also considering occasionally hosting guests posts written by other people. If you’re interested in writing something a data-related post to either show off work, share an experience, or need help coming up with a topic, please contact me.
About this newsletter
I’m Randy Au, Quantitative UX researcher, former data analyst, and general-purpose data and tech nerd. Counting Stuff is a weekly newsletter about the less-than-sexy aspects of data science, UX research and tech. With some excursions into other fun topics.
All photos/drawings used are taken/created by Randy unless otherwise credited.
randyau.com — Curated archive of evergreen posts.
Approaching Significance Discord —where data folk hang out and can talk a bit about data, and a bit about everything else. Randy moderates the discord.
Support the newsletter:
This newsletter is free and will continue to stay that way, share it with your friends without guilt! But if you like the content and want to send some love, here’s some options:
Share posts with other people
Consider a paid Substack subscription or a small one-time Ko-fi donation
Tweet me with comments and questions
Get merch! If shirts and stickers are more your style — There’s a survivorship bias shirt!