This post is based upon a talk I gave at DevOpsDays Detroit 2015.
Deciding to submit a talk for consideration at an event can be a troubling thing — what if my idea isn’t good enough? Do I think big enough thoughts to share a stage with “Thought Leaders”? Why would anyone care what I have to?
In this post, I will share with you my secrets for identifying a talk idea, deciding where to submit, and help give advice on overcoming the dreaded Imposter Syndrome, to help you get past the worries of being “not good enough” and break through to share your individual expertise and insight with audiences who would love to hear it!
Submitting a Talk Can Be Really Intimidating
Since we spend a lot of time listening to podcasts, watching talks, and following Big Thinkers on Twitter, we think that the only message anyone wants to hear are super insightful ideas.
The truth is, no matter what your level of experience, you have a unique story to tell. And your story has value. You don’t have to share some completely novel approach to container management for someone to want to listen to you — they probably will be thrilled just to hear the history of what you did to run Kubernetes in production. Even if you think that “everyone knows this”, your particular spin on the story is special, and therefore valuable. Nobody knows exactly what you know in the way that you know it.
You Don’t Have to Write the Whole Talk to Submit It
An idea is good enough to create an abstract. One or two paragraphs that spell out your theory is all that you need. Don’t invest the time in writing out the whole talk until you get accepted.
You don’t even need to know if the idea will work! For example, when I came up with the Five Love Languages of DevOpstalk, I simply had the theory that the metaphor of Love Languages would apply. That’s about as far as I got before submitting it (you can see the abstract for this talk here). If your original hypothesis doesn’t pan out exactly as you hoped, you can tweak it while writing the talk. It’s probably fine.
You Can Use a Talk to Learn Something
Want to learn something new? Propose a talk about it! That will be a fine motivator to actually learn it (deadlines can be very inspiring).
For example:
- I have a theory about how to build a pipeline to use InSpec Compliance tests to make sure that all my cookbooks work nicely together
- I don’t have to know exactly how to do this to write an abstract
- I can just come up with the idea, and I’ll learn how to do it as I write the talk!
Remember — your abstract doesn’t have to be “proven out” to be submitted.
How Do I Come Up With an Idea For a Talk Anyway?
Something you have done
Even if a lot of other people have spoken about a topic, your experience is different than anyone else’s. Your story is special. Real-world stories are much more valuable than theory.
Something that you have learned recently
Did you just learn a cool new way to test your Go code? Presenting a talk about it will have two great outcomes.
- You’ll be really excited to talk about it, which will make you an engaging speaker.
- It will cement that knowledge in your brain.
I’m a big believer in the learn > do > teach model. Teaching someone how to do something uses different parts of your brain than learning it, and you will retain the knowledge even better.
Something that you find super interesting
This overall is key. You have to be excited about your topic. It will come across in your presentation. Maybe you are fascinated by how AWS performs public post-mortems. Even if you don’t work at AWS, or even know anyone there, you can do research and present what you learned.
Something that you want to learn about
As mentioned above, you can use a talk as a way to learn a new thing. Julia Evans should be your model here. She is the poster child of using teaching as a way of learning. And the learn > do > teach model applies here too!
Where to Submit Talks
Forget about places like Velocity
The usual echo chamber can be pretty intimidating. You’re competing against the Big Names here, and if this is your first time around, you’re setting yourself up for a big challenge.
That being said, maybe you shouldn’t avoid submitting to these conferences. But don’t pin all your hopes on the Big Ones.
Places that aren’t familiar with your particular area
For me, since my subject area is DevOps, I like to consider conferences and groups that aren’t super familiar with it but would find it interesting. Some examples of places I like to consider to submit DevOps-type talks:
- Local developer meetups
- Agile conferences
- Software testing organizations
You can get ideas at The Complete List of 280+ Tech, IT, and DevOps Conferences.
DevOpsDays Ignites
These are great places to try out (short) talks, but have some challenges:
- The Ignite format can be tough (but really fun!)
- DevOpsDays can be picky about repeated content
The good part is that most DevOpsDays are usually short on submissions for Ignites, so you might stand a better chance of getting accepted for one.
You Don’t Have to PREED It
This is a reference to J. Paul Reed, who tends to want to have a new talk for every conference he speaks at. This is exhausting. Paul can do it, but you’re not Paul.
Secret? Even though all of his talks are different, they tend to be variations on a theme. But if you’re just getting started, don’t make things any harder on yourself than you need to.
Don’t Overkill
Come up with one or two abstracts and submit them everywhere. They should be different from each other in a meaningful way. As you get accepted and give these talks, each time you will get better at them, and through the year you will just keep polishing your presentation.
This is how the pros (i.e., Jez Humble) do it. Having to create new content for every conference is exhausting, and doesn’t actually provide as much value as the effort requires.
Try Out New Material “On the Road”
Volunteer to give your talk at a local meetup first to polish it and make it shine before giving it at a larger event. This also gives you the ability to get direct feedback. Most meetups are happy to get folks volunteering to present content, and will be delighted to work with you.
It can be really helpful (and less intimidating) to present at an out-of-town meetup where you are not part of that specific group or community — you don’t have to worry as much about your reputation (or perceived lack thereof) preceding you.
Use the Buddy System
Peer reviews are a great tool when working on your presentation. Some of the folks you can ask to help you include:
- Co-workers
- Friends in the community
- Event organizers where you are speaking
- Just ask the Twitters (if you’re feeling bold)
This isn’t necessarily about getting a review of your final deck (although that’s not a bad idea), but rather getting input into your abstract, themes, and talk structure. If you put these ideas into a Google Doc, you can share this with comments allowed to the folks you ask for help.
Q&A is Your Friend
If you are concerned that you don’t have enough “content” for a full talk, remember that Q&A can really help. It makes your talk more interactive and can help stretch out the time.
However, I don’t recommend just asking “are there any questions?” An open-ended statement like that might result in the sound of crickets from the audience. You certainly can start with that. If there aren’t any, be prepared with “call to action” questions to the audience themselves — if your talk was about post-mortems, you can ask the audience if anyone has a good process for them in their organization, and to share something about that with you.
PROTIP #1
Store all of your speaking stuff in a GitHub repo
This should include all of your abstracts/proposals, the presentations themselves, and any supporting items you use for speaking.
You can make each presentation a submodule (if you aren’t scared of submodules, which is a pretty reasonable fear). This way you can commit/work on them individually, and perhaps collaborate with someone on the talk without giving access to your entire speaking repo.
You should also create a Markdown file in your repo with your bio; this gives you an easy place to copy/paste from, or point people towards. Your headshot should also be stored in this repo.
PROTIP #2
Create a “speaker page” on your blog/website
This should include links to your past presentations, as well as a bio page with an area to download your speaker headshot.
Keeping this page up to date can be a challenge, but it’s well worth it. Not only does it help you keep track of where you have spoken, but when you are submitting to a CFP, you can put a link to this in the notes to help the organizers see your experience.
What are YOUR Goals?
What are your goals for the next 12 months with regard to submitting talk proposals? What do you want to do better? Let me know in the comments, and as always, feel free to reach out to me on Twitter (@mattstratton) with any questions or feedback!
Top comments (8)
Wow, great advice. I've had a talk brewing in my head for a while but dragging my feat on submitting anything -- this is a nice reminder :)
Thanks for sharing this. When speaking, sometimes I fear the the projects I've done won't be interesting to someone else because they've already been tried (and blogged about), or people already know a better way to do what I'm talking about. But usually I get one or two people that come up and say they learned something afterwards, and that makes it worthwhile :)
Excelent post , I defenitely share this with my friends
Thanks, Matt. Really nice post. I will be speaking at my first conference in december. And I will give a talk and a one hour workshop as well. Your tips will be very helpful.
Thanks again.
Thanks for sharing these tips, Matt!
They are perfect for a few talks I'm planning to do for beginners at my college when the next quarter starts.
Great read, as someone that's been wanting to submit my first CFP this is very encouraging!
Good luck! Let me know if I can help in any way!
GREAT pro tips! Many thanks!!!