Need someone to lead product management at your software company? I create software for people that create software and I'm looking for my next opportunity. Check out my resume and get in touch.

This is the blog of Adam Kalsey. Unusual depth and complexity. Rich, full body with a hint of nutty earthiness.

Speaking for Geeks: What Should I Talk About?

Freshness Warning
This blog post is over 8 years old. It's possible that the information you read below isn't current and the links no longer work.

You’ve decided to give a talk. You’ve found an interesting place to speak, perhaps a local tech meetup group. What you need now is a topic. The call for papers closes tomorrow, and you have no idea what to speak on.

Panic.

Coming up with a talk idea can be nerve wracking. You want to propose something good, which means something creative and well thought-out, but doing that on a deadline is tough. Here’s some ideas based on what I do.

Dust off an old talk. The best talks I’ve given are ones I’ve given before. I’ve had the chance to see, in front of a real audience, what works and what doesn’t. I’ve polished my examples, I’ve found better ways of making it flow, and I’ve probably improved my slides and my talk abstract.

This only works for conferences that have a different audience than the ones you’ve give the talk to before. If you gave the talk to last year’s industry conference, you probably don’t want to give it again at this year’s. Or if you gave the talk last month at a Javascript conference in one city, this month’s web developer event might have a lot of audience overlap.

Don’t just recycle the same talk, though. It’s hard to have any energy as a speaker if you’re repeating the same thing all the time. I like to add new information, remove stale things, and generally tweak the talk each time I give it.

Maintain a list of ideas. Every time I think of something interesting, I add it to a list of ideas. I have a notebook in Evernote called Talk Ideas. The title of each note is the subject of my idea. In the body, I throw a few notes. What made me think of this idea, possible angles for the talk, the types of conferences I might want to give it at. Not all of these ideas will turn into talks. Some might become a blog post. Some might become both. Some might die when I realize my 2am insight is really half-baked.

This takes a lot of the pressure off. Now when I have a conference coming up that I want to speak at, I can look at my past talks and see if something fits. Or I can look at my talk ideas and see if there’s a great fit.

Some of the talks I have in my ideas notebook right now are:

  • Everything I need to know about startups I learned from watching baseball
  • What language X can teach us about better language Y development
  • Big data for non-nerds
  • How the early days of blogging parallel the emerging API economy

Coffee Roasting at BarcampBreak the mold. Don’t be afraid to give a talk that doesn’t exactly match the conference. At a tech conference, generally geeky things can be interesting, and organizers are often looking out for things that aren’t yet another survey about how to use continuous integration/test driven development/containers/whatever.

At three different barcamps, I’ve given demos on home coffee roasting. I brought in some equipment, took everyone outside, and cooked some beans. Talked through the process along the way, explained how to get started yourself, and ended with a coffee cupping. One of those was 9 years ago, and Cal Evans still brings it up from time to time (photo here by Cal).

I once gave a talk at a Ruby conference about how to avoid lock-in when using cloud services. Although I didn’t mention Ruby once, the talk went over well because the Ruby community tends to use a lot of cloud services and APIs.

I spoke at OSCON a few years ago about how to make sure the user interface of your application is ready for IPv6. This wasn’t specific to open source, but was useful to the audience because they are creating interfaces.

The key is to make sure your talk fits the audience. Put yourself in their shoes and ask if you would find the subject interesting.

Don’t wait for that conference to come calling before you start planning for it.

This is part of a series on becoming a better public speaker. Read the rest of the series.

Recently Written

Video calls using a networked camera (Sep 25)
A writeup of my network-powered conference call camera setup.
Roadmap Outcomes, not Features (Sep 4)
Drive success by roadmapping the outcomes you'll create instead of the features you'll deliver.
Different roadmaps for different folks (Sep 2)
The key to effective roadmapping? Different views for different needs.
Micromanaging and competence (Jul 2)
Providing feedback or instruction can be seen as micromanagement unless you provide context.
My productivity operating system (Jun 24)
A framework for super-charging productivity on the things that matter.
Great product managers own the outcomes (May 14)
Being a product manager means never having to say, "that's not my job."
Too Big To Fail (Apr 9)
When a company piles resources on a new product idea, it doesn't have room to fail. But failing is an important part of innovation. If you can't let it fail, it can't succeed.
Go small (Apr 4)
The strengths of a large organization are the opposite of what makes innovation work. Starting something new requires that you start with a small team.

Older...

What I'm Reading