The Ultimate Guide To Memorable Tech Talks — Part 3: Writing a Conference Proposal (or CFP)
A guide to writing and submitting conference talk proposals
This is Part 3 of a multi-part Guide to Memorable Tech Talks. Visit the outline for more information.
Key Takeaways
- Research the conference before submitting. Look for explicit guidelines or research past talks.
- Propose what you’re capable of delivering in a concise way.
- Don’t be afraid of rejection. Try again.
First things first, you need to find a conference to submit to. There are resources for this such as the Mozilla Tech CFP Twitter, the list of worldwide PyCons, and the PaperCall Event Directory. You can filter the PaperCall directory by events that have open Calls for Proposals (CFPs), or events that provide travel assistance. If you know other good resources for learning about CFPs, please share.
Something to keep in mind is that CFPs for large conferences end earlier than you might expect. This gives plenty of time for potential attendees to determine if they want to go and clear their schedule, and for speakers to book travel. For example, PyCon US is in May 2019 this year, but proposals were due on January 3rd. If you want to submit a successful proposal, you’ll need to start thinking about your submission in November or December to get a head start.
Make sure you research the conference before you submit your proposal. Many of those conferences will have guidelines on what topics they’d like to see for that year, like OsCon 2019. The call for speakers page outlined the topics they’re looking for this year, such as Open Source, Cloud-Native, and AI-Enhanced.
If you don’t see any suggestions, you have other options. Find out as much information as possible on what the conference is looking for by looking up talks and videos from previous years. If you want to submit a talk on a similar topic, make sure you highlight what will set yours apart. Review the instructions from the conference in great detail. Some conferences like PyCon US have explicit guidelines for how they want their talk to be structured. Space Pug is an example proposal, including a detailed abstract and estimated timings for each clearly defined section. Sometimes conferences break their own rules, like when PyCon features talks on git, but that’s rare. Don’t expect your talk to be the exception in regards to what conferences are looking for, especially for one of your first talks.
Think of a descriptive title that’ll set your proposal apart. Avoid inside jokes, and use puns carefully. Remember that the reviewers may not be from the same country as you, and they might miss context you were trying to provide. If you’re stumped, the Kickass Headline Generator is a great site to help you generate ideas.
When you’re writing the proposal, think about what technology and level of experience you’re aiming for, along with what your audience will want. A Python audience will have different wants and needs from an open source audience. An enterprise audience will have different expectations than a startup audience. You’ll need to take more time to explain fundamentals in a talk aimed at a beginner audience versus experts. You can help your proposal be more descriptive by identifying who the talk is meant for.
Make sure that you can deliver on what you’re proposing and you’re not overextending yourself. If you have live demos as part of your talk, they should be pre-recorded locally so you can play them if the internet goes out or your live demo blows. A fact of life, but sometimes demos decide to stop working because the demo gods have cursed you.
If you’re talking about a project or a bit of sample code, make sure that the project is in a good state and you can point to the code on GitHub. As you gain a reputation as someone who delivers and you become more experienced, you’ll gain more leeway with these requirements. If you’re planning on giving your first talk, then these requirements are a non-negotiable part of your proposal.
You want your proposal to be expressive, but not verbose. If you have a lot to say, make sure you format your proposal with bullet points and the important information highlighted. The folks who read the proposals are human, just like us. They won’t always have the attention span to read an unformatted wall of text.
Consider this guideline: Your proposal should be formatted like a resume. Expect the reviewers to skim your proposal at first, and read in more detail as the proposal process goes on. When writing, get the content out, and organize and perfect later.
If there’s a section that asks for previous speaking experience, don’t be afraid if you don’t have any. Many technical conferences welcome first-time speakers and even offer resources to help coach them. In fact, the Deconstruct conference in Seattle only allows proposals from first-time speakers. Write whatever relevant experience you have here (even speaking at a Meetup counts).
If you have plenty of applicable experience, don’t be shy. Here’s your opportunity to showcase your accomplishments.
Lastly, ask a friend to proofread your proposal. I’ve missed countless typos and mistakes while editing my own writing. If you’re writing a proposal in a language that isn’t your native language, ask a friend who natively speaks that language to proofread for you.
Don’t be afraid of rejection. Submit as many proposals as you can. Always ask for feedback on rejected talks, and use those suggestions to improve your proposals and try again at other events. Rejection stings, but don’t take it personally. Dust yourself off and try again. I probably get one in five proposals accepted or less. For a conference that I know I’d really like to speak at, I’ll submit at least three proposals to increase my chances of success. Sometimes, all three get denied, and that’s OK.
If you have contact information for the organizers, try to email them to see if there was feedback about your proposal that you could use to improve it for next time. Sometimes conferences will accept a proposal that was rejected at a similar conference. Other times, the same conference will reject a proposal one year, and accept it the next.
Once you’ve submitted your proposal, it’s generally out of your hands. Just sit back, relax (or don’t, your choice) and wait for that confirmation or rejection email. There are similar traits amongst quality accepted proposals, but there’s no guaranteed formula that’ll get your talk accepted to a conference.
As a helpful guide, consider reviewing accepted and rejected proposals from others in your field. I posted a few of my own examples here. Allison Kaptur, Emily Morehouse, and Brandon Rhodes have also posted several of their accepted and rejected Python talk proposals.
If the conference rejected your proposal to speak, try to attend to listen and learn instead. You’ll get a better idea of what the conference expects from speakers if you choose to reapply next year. If you’re a student or a member of an underrepresented group and can’t afford to attend, many conferences, including Python conferences, StrangeLoop in St. Louis, and others provide generous financial aid.
Continue to Part 4: Tools of the Trade
Skip to:
- Introduction — About me and my journey through technical public speaking.
- Choosing a Topic — Selecting a topic you’d like to speak about.
- Writing a Conference Proposal (or CFP) — A guide to writing and submitting conference talk proposals.
- Tools of the Trade — Tools for brainstorming, creating slides, time-management, and more.
- Planning and Time Estimation — How to plan your preparation time before the conference.
- Writing a Talk — Writing an engaging talk and captivating slides.
- Practice and Delivery — Preparing for and delivering on the big day.
