Don’t Fear the CFP
Tags: publicspeaking, career, learning, tips
Published: 2017-12-22 16:45:59

---
title: "Don’t Fear the CFP"
published: true
description: 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?
tags: public-speaking, career, learning, tips
canonical_url: https://medium.com/@mattstratton/dont-fear-the-cfp-e8272910972b
cover_image: https://thepracticaldev.s3.amazonaws.com/i/jf16mw214n6h8zpwnz12.png
---

_This post is based upon a talk I gave at_ [_DevOpsDays Detroit&nbsp;2015_](https://legacy.devopsdays.org/events/2015-detroit/proposals/how-to-train-yourself/)_._

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](https://en.wikipedia.org/wiki/Impostor_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&nbsp;it!

### Submitting a Talk Can Be Really Intimidating

![](https://cdn-images-1.medium.com/max/1024/1*9syNCFqYS4PTHKaLPo52Lw.png)

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&nbsp;it.**

### You Don’t Have to Write the Whole Talk to Submit&nbsp;It

![](https://cdn-images-1.medium.com/max/1024/1*xd9362JyrNVS3s_jSClaRw.jpeg)

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 DevOps](https://www.youtube.com/watch?v=SGCfwvjHKGI)talk, 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](https://github.com/mattstratton/speaking/blob/master/proposals/five_love_languages_of_devops.md)). If your original hypothesis doesn’t pan out exactly as you hoped, you can tweak it while writing the talk. It’s probably&nbsp;fine.

### You Can Use a Talk to Learn Something

![](https://cdn-images-1.medium.com/max/1024/1*pCU6g7anwbtwYl1gKL-yGQ.jpeg)

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?

![](https://cdn-images-1.medium.com/max/1024/1*XiaH4cZCtkHmyLCGzRO7Tg.jpeg)

#### Something you have&nbsp;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&nbsp;recently

Did you just learn a cool new way to test your Go code? Presenting a talk about it will have two great outcomes.

1. You’ll be really excited to talk about it, which will make you an engaging speaker.
2. 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&nbsp;learned.

#### Something that you want to learn&nbsp;about

As mentioned above, you can use a talk as a way to learn a new thing. [Julia Evans](https://jvns.ca/) 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&nbsp;too!

### Where to Submit&nbsp;Talks

![](https://cdn-images-1.medium.com/max/1024/1*vmpkkzqzfcpBt5fLcbeH0A.jpeg)

#### Forget about places like&nbsp;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&nbsp;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](https://docs.google.com/spreadsheets/d/17i6PGTMHd9JHG1CKw0mKckUQehTXFPvabVuC8vfTr5I/pubhtml).

#### DevOpsDays Ignites

These are great places to try out (short) talks, but have some challenges:

- The Ignite format can be tough (but really&nbsp;fun!)
- DevOpsDays can be picky about repeated&nbsp;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&nbsp;one.

### You Don’t Have to PREED&nbsp;It

![](https://cdn-images-1.medium.com/max/600/1*N-vXO0yG5pQlJ6kBqgx2gw.jpeg)<figcaption>Sad Paul is sad</figcaption>

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&nbsp;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&nbsp;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&nbsp;Road”

![](https://cdn-images-1.medium.com/max/720/1*nY7_F2cnVFtV3zZA_yXWRQ.jpeg)<figcaption>“What’s the deal with containers, anyway?”</figcaption>

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&nbsp;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&nbsp;System

![](https://cdn-images-1.medium.com/max/1024/1*9tICMZ-n-tdv0wvScQUUQw.jpeg)

Peer reviews are a great tool when working on your presentation. Some of the folks you can ask to help you&nbsp;include:

- Co-workers
- Friends in the community
- Event organizers where you are&nbsp;speaking
- Just ask the Twitters (if you’re feeling&nbsp;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&nbsp;help.

### Q&A is Your&nbsp;Friend

![](https://cdn-images-1.medium.com/max/1024/1*dDdaPTmC6JNCQizaWf8KKg.jpeg)<figcaption>The best tech talks are in 3-D</figcaption>

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&nbsp;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&nbsp;you.

### PROTIP #1

#### Store all of your speaking stuff in a GitHub&nbsp;repo

![](https://cdn-images-1.medium.com/max/1024/1*38kJDOMcKR485gaW3AhD1w.png)

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&nbsp;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&nbsp;repo.

### PROTIP #2

#### Create a “speaker page” on your blog/website

![](https://cdn-images-1.medium.com/max/800/1*sbH01bM6mymzCxgzuVyrKw.png)

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&nbsp;Goals?

![](https://cdn-images-1.medium.com/max/1024/1*XqaSiBNooqH5M5oakZ7seA.jpeg)

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](https://www.twitter.com/mattstratton)) with any questions or feedback!