How to write an outstanding software conference talk proposal

Three years ago, I submitted my first talk proposal to PyCon. I threw it together the week before the deadline, and it was rejected. The next year, I spent more time putting together a proposal. I asked my friends for feedback and submitted a proposal that I was proud of two weeks before the deadline. It was rejected too.

This time, I was surprised. I thought I had put together a good talk proposal, but apparently something was missing. To find what was missing, I had to do some research. I (a) volunteered for some program committees, so that I could learn about what the members are looking for, (b) asked for feedback every friend (and acquaintance) who had ever given a good talk at a software conference, and (c) submitted my talk to every conference that I saw had a CFP (call for proposals).

I found that there are two main things that almost every conference is looking for:

1. Is this talk going to be good (and suited to our conference format)?
2. Is this talk going to attract a crowd?

Write a good talk proposal

Pick a relatively simple concept to discuss

Most talks are <= 30 mins, which actually is not very long to introduce, delve into, and conclude a discussion of a concept. If you put too much information into your proposal, you risk it looking like a disjoint laundry list. By focusing your proposal on a few points, you can give yourself time to cover those points in a more thorough and entertaining way.

Write a narrative around that concept

Program Committees love fun and interesting talks, so think about how you can tell a story using the concepts that you want to discuss. A few particularly clever examples of this are Where in your RAM is ‘python san_diego.py’? and Memory Chronicles: A Tale of Two Pythons.

Include a detailed outline of your talk (including approximate timing)

If the format of the proposal allows, always do this. It both (a) is great for your own planning, and (b) gives the reviewers a more defined picture of how you expect your talk to flow. Notably, this is most effective if you use relatively small time increments (i.e. 5-7 mins). This detail also enables the reviewers to give you more specific feedback about how to improve your talk.

Demos and examples are great, but be careful with live demos.

Demos can be an exciting addition to a talk, but if you are going to propose a talk that uses a demo, you should also include some information to allay the reviewer’s concern that your demo will crash and burn. Have you left adequate time for your demo? Have you done this demo before (with constrained wifi)? Is there any way that you can automate the demo (e.g. putting commands in a script, example code in a Jupyter notebook)? This type of information can make all the difference in maintaining your reviewers’ faith in your demo.

Proofread & ask for feedback

Once you think you have a halfway decent proposal, find someone else to give you feedback. If there is someone on the Internet whose work you admire, you can try asking for their feedback on your proposal. I got a lot of great feedback just from people who I reached out to on Twitter.

Relatedly, try to submit your proposal early. Sometimes reviewers (for some conferences) may offer feedback on promising proposals that are submitted before the inevitable onslaught of last minute proposal submissions.

Pay attention to proposal guidelines

I feel like 80% of the feedback I end up giving on talk proposals is just a reminder to follow the guidelines. Many conferences link to detailed guidelines and/or example talk proposals in the call for proposals.

Convince reviewers that you will draw an audience

Make sure that you clearly explain why your talk topic is relevant to the conference topic.

Talks about the software/tool that the conference is about have a greater likelihood of acceptance (e.g. at PyCon, your talk about Python will have a much higher likelihood of acceptance). So if your topic is not obviously about the conference topic, make sure you explain to the reviewers why it is.

Notably, this piece of advice varies somewhat depending on the conference that you submit to. Some Python conferences love community-based talks and some are willing to accept talk topics go fairly far afield of the main conference topic, provided you explain why your topic will still be of interest to the Python community.

Keynote talks tend to be about either (a) how great the community is, or (b) concrete ways to improve the community. However, contributed talks are shorter, and particularly for a conference like PyCon, if you do not clearly make a case for how your topic is about the Python community, your talk will probably not be accepted.

Don’t leave the “additional information” section blank.

This is your last chance to convince the reviewers that your talk is going to be an amazing well-organized talk that 200+ people will undoubtedly be excited to see. There are several ways you can express this.

• Do you have any special experience with the topic? Do you use it in your job?

  If not, that is totally fine, and you should still submit a proposal. But if you know this stuff really well, definitely mention that to the committee!

• Do you have any public speaking experience?

  Everyone gets a little nervous before a big talk, but the committee wants some evidence that you (a) will not throw up on stage, and (b) you will probably put together a talk that people are excited to see. Evidence of this could come in the form of giving other conference talks, poster presentations, or any kind of teaching experience.

  If you want to bolster your credibility as a speaker, it is super-helpful to find other places that you can speak. If you have a local python meetup, there is a good chance they would love to hear your proposed talk (If you do not have local python meetup, you can make one). You can also submit to regional python conferences, such as PyTennessee, PyOhio, PyCaribbean, or PyBay, or more focused conferences, such as DjangoCon, SciPyConf, JupyterCon, or PyData.

• Have you given this talk (or a related talk) before?

  If so, include your slides or a recording! This is a fantastic way to demonstrate that you are good speaker, proposing a good talk.

Notably, this process can be a bit random, and it can be helpful to plan accordingly. Many large conferences, such as PyCon, want a balanced schedule of talks over a variety of topics. If the committee receives many talks on a certain topic, which happened to be popular that year, having your talk on that topic accepted will be far more difficult than if you had submitted on another topic with fewer submissions. So if there is a particular topic you are excited about, definitely submit a talk on that topic, but if your goal is to get any talk accepted, you could try submitting a few talks on different topics.

With some of these ideas in mind, go submit a proposal. If it is not accepted at your top choice conference, get feedback, and submit it someplace else. Giving a talk about something you enjoy is a fantastic way to get feedback, meet other people who share your interests, and establish your expertise. Once you’ve written a proposal, it is worth getting feedback, revising, and submitting again.

Written on May 19th, 2017 by Deborah Hanus