I’m lucky to live in a city with a lively tech scene and more weekly meetups than you can shake a flash drive at. I’ve been a little out of the loop lately so I decided to give myself a challenge: to attend one (1) meetup, eat pizza, talk to people, and fill my brain with new things to Google. I impressed myself by going to not one but two meetups, exceeding my expectations by 100%.
Now that I’ve been to two meetups, I am clearly an expert in public speaking and want to share my thoughts on what makes a really damn good talk. But first: why should you believe me?
OK, now that I have your trust, let’s talk talks.
Both of the presentations I saw moved at an ambitious pace: within minutes, we were talking about nitty-gritty of how to configure a particular stack or the laws governing [advanced design pattern here] without really painting a picture of — what is this and how can I expect to use it?
Assume your audience is smart and capable but knows next to nothing about your topic. Also, they’re not 100% sure if they should care. They ❤ you, but it’s getting late and the free carbs are kicking in. 😴
Start by giving plenty of context. Take your time; this is the fun stuff. Introduce yourself, your organization, your team, and — most importantly — what was the problem that led you to adopt this thing. In super condensed form, this might sound like:
“Hi, I’m Liz from Widget.io. We’re a startup out of Detroit that is changing the game by offering widgets-as-a-service. I’m on the data engineering team, which means I drink a lot of coffee and make sure people’s widgets get into the database safely. When I started, we were using OldDB and it was really slow. No one could figure out why until we read on Stack Overflow that OldDB doesn’t scale past a million rows. So we switched to NuDB and now we’re back in business! So, in a nutshell, NuDB is great for when you have large amounts of data and performance matters. Now let’s talk specifics…”
You’ve been using this hammer for a while and you know what its nails are. Your audience doesn’t. The best thing you can do to get people excited is lay out a clear, compelling situation where it came in handy. In my experience, success stories work a lot better than raw benchmarks or sudden tech dives. It may seem boring to you because you’ve lived your story every day for the past five years, but it will make the rest of your talk that much more interesting and memorable for your listeners.
Unless you’re giving an all-day workshop and that’s what everyone signed up for, keep the theory to a minimum. Definitions are helpful, but if you’re basically reading a Wikipedia page out loud you’re going to see some eyes glaze over in 3, 2, 1…
Plan your talk as though it’s a lightning talk and you just happen to have 30 or 60 or however-many minutes. That’s not enough time to make everyone an expert , so be selective in what you cover and use lots of examples.
One of the best presentations I’ve seen was Vladimir Agafonkin, creator of Leaflet.js, talking about a next-gen mapping library he was working on. Agafonkin isn’t a native speaker of English, and he didn’t attend the Oprah School of dynamic public speaking. In fact, he’s a pretty deadpan dude. What made him an standout speaker was that he was:
Each of his slides had no more than a few key words that he expanded on in an almost story-like fashion, making you wonder what was coming next. To paraphrase, where words in bold might have been on screen:
“With the arrival of faster computers and better browsers, web maps are starting to use a technology called WebGL. WebGL is a fast, in-browser graphics engine that is really good at drawing triangles. This poses an interesting problem: how do you draw a map using only triangles?”
Journalism students learn a concept called the Inverted Pyramid that says: start with a specific event you expect your readers to care about (“Last Friday, NATO members signed an agreement to…”) and work your way back to a more wide-angle view of the subject (“This is the first time NATO has agreed on something since 1989, when…”).
This works because most of us know enough about NATO to get something out of the rest of the article. But with technology, there are usually too many core concepts you have to understand before you can move on to a specific topic. So in your talk, do the opposite: go from general to specific. For example, if you’re talking about NoSQL databases, hold off on talking about sharding until you’ve told me, in a few words at least, what distributed processing is and what it’s good for. Define things gradually and keep chiseling away at your topic until you get to that really cool technical feat that it’s capable of.
Pretty soon you’ll be saying: “Now that you all know a little about cluster computing and why it plays well with big data, did I mention that this bad boy shards like a m*****f****r?”
In other words— don’t go though your config file line by line.
One of the pitfalls of tech talks is the temptation to walk through the exact steps you took to get your well-oiled machine up and running. That certainly has its place and can be helpful to others, but consider time limitations and the nature of the event. For most after-work meetups, people don’t have the bandwidth to remember the 25 shell commands you ran to do something. Think about publishing your workflow as a blog post and sharing it out to the group for reference.
Your talk should give us a taste of what’s involved in setting up Tool X (am I writing JSON? YAML? Italian?) and what kind of results we should expect. This would be a good time to pull up your slide on how many milliseconds you’re saving per request and show off some numbers.
An effective, enjoyable talk is all about context and curation.
People who go to tech events tend to be intelligent, curious, and self-motivated — but we don’t all have the same backgrounds or levels of experience. When you’re planning your talk, try to remember that a little bit of context at each step of the way helps keep the whole room focused and confident in their ability to learn. The old hands in the room might check their phones as you explain what a reactive framework or graph database is, but it’s worth it to retain the other 60% of the room who were afraid to ask. Be selective in what you show to keep your scope manageable and so you don’t scare off the newbies.
And most importantly, don’t forget to pick up your free stickers on the way out.