Conference Proposals

So you want to propose a talk for a technical conference? Great! Here are my opinionated answers to some common questions about doing just that.

Q. Can I submit more than one proposal?

Yes. Unless the conference states otherwise, submitting more than one proposal is fine. Most of the folks you see on stage (especially at smaller events) submitted several proposals. Limit yourself to no more than three proposals and make sure they are all worthy of consideration. Reviewing each proposal takes time and it is polite to be respectful of the reviewers’ time.

If you do submit multiple proposals try to make them very different. I recommend targeting either different skill levels, different tracks (for a multi-track event), or both. Conferences usually have a target mix of topics and skill levels (20% beginner, at least one DevOps talk, etc). The more places your proposals could fit in the schedule the higher your chances of acceptance. During the last year I’ve typically proposed one DevOps talk, one technical talk, and one culture talk if I really want to speak at an event.

Q: Can I submit the same proposal to multiple conferences?

In general, yes. Many event organizers ask if you’ve given the talk before and if so where. Be honest and tell them. Link to the video, if possible, so they can watch a bit of the talk. Some events ask for original content. If you are proposing to an event like this you should honor their request. Once their CFP or conference is done, though, you can still use that content for another event.

Sometimes I’ll propose the same talk to multiple events, with a plan in place to change the content for the different audiences. If that’s the case for you just let the reviewers know how you plan to expand or change the talk. I like to use the phrase “significantly different” to describe the new version.

Q: Can I submit a talk on a project I haven’t finished yet?

Yes, but be careful. Many people propose talks as a way to make themselves complete a project or learn a new technology. I know from experience that this technique can work, but it usually doesn’t result in the best talks.

Learning, reading code, debugging, preparing slides, and practicing a talk all take more time than you think. If you’ll have three months from CFP acceptance to giving the talk you may be okay working on something new to you. If you have only three weeks it is best to stick to things you’ve already done.

If you are new speaker limit yourself to topics you know well. Preparing slides and practicing your talk will take longer than you expect. Also you will be much more confident if you know your material really well, and that can be a big help when you are new to the stage.

Q: Can I submit a talk based on a blog post or article I wrote?

Yep! This is a very common way for new speakers to start out. They write a blog post (or an article or a library) and then do a talk on that topic.

Q: How long should a proposal be?

This varies widely from conference to conference. My general guideline is that the abstract should be no more than four paragraphs and fewer than 300 words. Ruby Conf and Rails Conf cap abstracts at 600 characters, which is really short. I’ve whined a bit every time I’ve proposed to those events but I’m starting to see their rationale and agree with their character limit.

Your abstract should provide just enough information so that an attendee can decide to attend the talk or not. Too many words and they’ll either skim or simply not read the abstract at all.

One common misstep I see is cluttering the abstract with extra information, like the talk’s intended audience, your qualifications, information about why your talk belongs at the event, a detailed outline, or links to GitHub. Those details don’t belong in the abstract. They are a better fit for one of the other sections in the proposal. I usually put that content in the “Notes for Reviewers” section or equivalent.

Q: What can I do to improve my abstract?

There are three steps you can take that will nearly always improve an abstract: Make it shorter. Focus on what the audience will learn (or the problems they have), not what you will talk about. Don’t use first person pronouns like “I” or “we”, and avoid the phrase “in this talk”.

The last bit about “in this talk” is a pet peeve of mine. After reading hundreds of proposals that all include “in this talk” I want to banish that phrase from existence. I still use “in this talk” occasionally in my proposals but it is a “proposal smell” (like a code smell) that I’m talking more about me than my audience. I can usually reword to remove it with a bit of creativity.

Q: Any tips for talk titles?

Titles should be catchy or memorable and short. If you have to choose between catchy and short, choose short. Short titles look better in the program and are easier to remember for attendees.

Coming up with titles is one of my favorite parts of speaking. My favorite title to date was “What do I do with this giant pile of data?”. While I love that tile, it wasn’t a very good one. It was too long and got shortened in the program to “Giant Pile of Data”, which didn’t convey the subject of the talk very well.

As a better example one of my early talks was titled “A Taste of Prolog”. That worked because it was short and summarized the talk well. Another talk I gave was titled “We’re Sorry but Something Went Wrong”. Although long, the title was memorable since that text is very familiar to all Rails developers.