How to Write a Great Conference Talk Proposal from Conference Organizers

Brian Rinaldi - Aug 1 '19 - - Dev Community

Writing a CFP proposal to speak at a tech conference can be intimidating. I want everyone who wants to speak at a conference to have that opportunity. Sometimes, though, a little help and advice can help open the door.

I already offer free CFP advice via Twitter dm as well as by participating in Help Me Abstract. In this post, however, I reached out to some conference organizers and asked them for advice or resources that they'd offer to potential speakers when creating a talk proposal. Keep in mind that what each specific conference is looking for is subjective, so it is always best (as Dawn points out below) to read the details of each specific CFP, but understanding what conference organizers are looking for can be incredibly useful.

Pratik Patel, Organizer of Connect.Tech, VueConf US and more

Pratik offered the following advice:

Fundamentals are a great conference topic!

Everyone wants to talk about the latest shiny feature in ${NEW_THING}. Perhaps only one of these will get picked, so your chances for getting accepted are low. Think about a topic that you would consider fundamental: function scoping in JavaScript, Objects in Python, or lambdas in Java, etc. Find out the latest on this topic, and craft an interesting proposal around it! There will likely be others who would enjoy a refresher on the topic and also new developers who can benefit from your presentation.

Shawn Pucknell, Organizer of FITC, Web Unleashed and more

Shawn recommended you highlight the following:

Experience

Be sure to list any relevant speaking experience, including teaching, lecturing, meetup groups, in addition to of course event speaking.

Travel

If your work does cover flight/hotel for you speaking, be sure to mention it as it opens up more speaking opportunities.

Topics

Depending on the CFP, include a list of other topics you would be up for speaking on.

Dawn Parzych, organizer of Write/Speak/Code

Dawn said:

Here's what we sent in the rejection letter on common reasons talks were rejected:

  • The talk was focused on a specific technology or programming language. Write/Speak/Code is language agnostic.
  • A short (one or two sentence) abstract. The selection committee uses the abstract to understand what you will be saying to the audience. This is also what gets published in the program guide to entice participants to attend your talk. While there is no hard and fast rule on how long an abstract should be most talks that were accepted were in the 8-10 sentence range.
  • Abstracts were missing clear audience takeaways. The attendees are coming to the event to learn. If the selection committee can’t see what the audience will learn, your submission is less likely to be successful. Including a sentence as simple as “Key takeaways from this talk... “ or “Come learn…” can help. You don’t need to give all the details away but a high-level summary is helpful. Also remember that you can provide more detail in the reviewer notes.
  • The abstract read like the speaker’s bio. While it’s great for the speakers’ experience to inform their talk, we want to center the audience & how the talk can help them. Aja Hammerly offers some good examples on how to write an abstract with the attendee at the center.

Floyd Marinescu, Organizer of QCon around the world

Floyd offered some advice along with an example:

I think the most important thing is to give detail as to what will be in the talk rather than talk ‘about’ the talk. So more of an outline than an ad. For example below is what Javascript inventor Brendan Eich provided for at talk at a past QCon which we accepted.

The Present and Future of the Web Platform

In this talk I will survey interesting developments in the Web platform, analyze emergent trends, and make some predictions. I'll cover:

  • The evolution of web technologies and APIs in the github era.
  • JavaScript in the Harmony era:
    • as the ubiquitous, high-level web programming language;
    • as safe assembly language for compilers such as Emscripten.
  • HTML, CSS, and DOM beyond "HTML5" into the version-free future.
  • Device, System, and Web APIs for portable, power web apps.
  • WebRTC for real-time n-way video, audio, and data communications.
  • Better network protocols, fewer round trips, more piggybacking.
  • Privacy, security, and user agency in the mobile+cloud era.

I will demonstrate some of these points with live code demos.

Phil Hawksworth, organizer of JAMStackConf

Phil focused on the value of mentoring by a conference that can help you create your proposal:

At a very high level, we're doing things a little differently this year at the conference in SF. All with a view to ensuring that we improve diversity and inclusivity, and keep on finding great speakers beyond the folks I've been able to beg borrow and steal so far!

We're officially running a CFP this time for some of the main slots and also some lightning slots at the conference. While I'm leading the curation of content, there is a small panel of us who will review the submissions to the CFP together.

I'm very keen to help people be successful with their proposals, so I've been running regular office hours for real-time feedback, or async feedback all via a #cfp-assistance slack channel. Some of it occurs in private in DMs but there is also an open channel. You can find it in a new slack that we created for the JAMstack conferences and meetups.

https://jamstackconf.com/slack

Matty Stratton organizer of DevOps Days

Matty had some simple suggestions:

  • Don’t worry about “spoilers”
  • “Bullets vs. Prose” is the “Tabs vs. Spaces” of the abstract world
  • Read the requirements
  • Don’t skip parts of the form

He also suggested Conference Proposals that Don’t Suck by Russ Unger and Give Actionable Takeaways by Bridget Kromhout as useful resources.

Additional Resources

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .