Citus 11.3 is out! Now with tenant statistics. Read all about it in Marco's 11.3 blog post. 💥
Written by Claire Giordano
January 16, 2020
As I get ready for the PgDay San Francisco event that is happening next Tue 21 January—a one-day, single-track Postgres community event at the awesome Swedish American Hall in SF—I’m reflecting a bit on how important the speakers are to developer events. Let’s face it, without speakers, there would be no conference.
And because I was on the PgDaySF talk selection committee, I’ve had some good conversations these last few months about CFPs, conference talks, how talk selection committees work, and how you can improve your chances at getting your proposals accepted. So I thought it would be useful to walk through the tips I’ve accumulated on how to get your conference talk accepted—at a Postgres conference, or at any developer conference.
These tips are premised on the notion that a good conference talk requires these 4 things:
So here we go, let’s walk through 16 tips on how to get your conference talk accepted.
The program committee needs it. To create an effective program for an event, the talk selection committee needs to understand more than just your specific talk proposal. It helps them to get a sense of the knowledge and skills of the speakers. Note I said “skills” and not “experience”. This is important, as many conferences welcome first-time speakers with open arms. So it’s often OK if you don’t have a lot of experience giving conference talks. But the program committee still needs to know more about the person who will go up on stage.
Not too long, not a treatise, but use this space to tell the talk selection committee a bit more about you and about why this talk will be good for the attendees and good for the conference.
Tell them about the talks you’ve given inside your company, since I’m guessing those are probably not publicly visible. Or tell them about small local meetups you’ve spoken at. Finally, while everybody follows their own process to prepare for a conference talk, it is true that many great presenters practice, practice, practice—so you might try giving the talk selection committee a sense of how committed you are to practice.
My teammate on the Azure Postgres team, Craig Kerstiens, says one common wisdom is that your title should be inflammatory. Some people say the title should be provocative. A program chair for QCon once told me he leans toward titles that have an opinion, where the presenter is willing to take a strong position on something.
I say just make it enticing. You don’t have to be inflammatory, but you do have to fill the room. After all, the title is what will get your abstract read by attendees, and therefore what will get people to attend your talk, especially in a multi-track event where they have choices. In the case of a 1-day single-track event, your title might be the hook that ultimately persuades someone to buy their ticket for the conference.
To get a good title, write down all your ideas, both the good and the bad. Keep riffing. Why? If you restrict yourself to only write down good ideas, that can stifle your creativity. My ratio—and your mileage may vary—is that for every good title I come up with, I need to generate at least 10 bad titles. Sometimes more.
So, give yourself permission to write down lots of ideas, good and bad, and to keep writing down ideas no matter how much they suck. And then somewhere along the way you’ll surprise yourself with a truly awesome title.
One of the engineers I work with, Dimitri Fontaine (and author of the book, The Art of PostgreSQL) says that writing a good talk title is a lot like writing code. It’s rare that the first lines of code you write are better than just a draft, but it’s important to write the initial code to understand what you’re trying to achieve. So that you can then write the code that you will use in production.
Once I have 20-30 titles for a talk written down, I’ll re-order them, move them around, highlight the ones that are best, compare them to each other, and then share the “finalists” with my reviewers to get their inputs.
I will often look at all the titles from the previous 1-2 years of the same conference, to see what “kinds” of titles (short vs. long? creative vs. factual? storytelling vs. academic?) have been accepted in the past, and to see if that gives me new ideas for new types of titles.
Similarly, I look for patterns in the abstracts from last year too, to see whether the accepted talks focus on existing features vs. more forward-looking possibilities. If it’s a technology conference (say, a Postgres event), look at whether more of the talks were user stories vs. by developers for developers who work on the database itself. How many of the talks are geared toward engineering topics—versus, say, marketing topics? While this year’s talk selection committee might have different people and there could be a different “theme” this year, I find looking at the patterns of past conference talks can help me see ways to “fit in” and ways to “differentiate”.
You can do this in a bunch of different ways. You can ask a question—or you can tell a “how to do X” story. “How to” talks often fare well, because it’s clear that the talk will teach the audience something. Or you can make a provocative statement that seems almost unbelievable and makes people curious to know where you’re going to go with the topic. Sometimes people imbue the provocative statement with emotions like love and hate. And of course, “why” talks are an old standby and rely on our human nature, our desire to find out the answer. Examples:
A lot of Postgres talks are about database features or tools, but some of the most interesting talks are about how people used the Postgres database for a real-world application. If you’re a heavy (or even a light) Postgres user and you’re willing to share what problems you ran into and how you overcame them, then you’re in just as good a spot to give a conference talk as seasoned Postgres developers. (Thank you to Marco Slot for adding this tip to my list.)
Know that the most popular and brilliant conference speakers get rejected way more than you realize. Getting rejected is not a statement about the quality of your proposal, nor of the quality of the speaker, so please don’t take it personally. Program committees sometimes take a 2-pass approach to making decisions about which talks are accepted. First they look at each proposal individually, to judge the “interestingness” of the talk and the “fit” for the event’s audience. Once they have a set of semi-finalists if you will, then it’s a matter of looking at the talks holistically, to figure out which talks complement each other (or which talks have a lot of overlap.) They also have to pay attention to diversity: at a single-track event, it really wouldn’t feel like a community event if all 8 talks were given by speakers from the same company, for example.
This advice mostly applies when you’re resubmitting a talk proposal that you’ve given before. Which, by the way, is legit. Lots of people will give the same talk a handful of times at different conferences. But when you resubmit, make sure your proposal is “fresh”. For example, don’t refer to Postgres 10 when Postgres 12 is already out (unless it’s a historical talk, of course.)
I refer to this as the “teach someone to fish” approach to content strategy. The thesis is that a talk should not really be about you, since, sadly, the audience doesn’t really care about you. ☹ They’re much more interested in what they can learn from you, and what they can take away. So your proposal will be stronger if it clearly communicates your intentions on what your audience will learn.
This is a riff off the always-true cliché of “know your audience.” If, for example, the conference you’re submitting to is a single-track event, you should propose talks that will be broadly appealing to most of the audience, since the entire audience will be in the room. If on the other hand you’re submitting to a multi-track event, then niche talks (talks that are only of interest to a subset of the attendees) will have a better chance of being accepted.
It’s not just about getting your talk accepted, but it’s about persuading people to attend your talk (or in the case of a 1-day event, to attend the event!) So your talk selection committee will review your proposal in that light: will attendees want to come to this talk?
Another way to say this is: Don’t Be Vague! When Louise Grandjonc (Azure Postgres engineer, speaker at Python and Postgres events, and also a Postgres program committee member) reviewed this post, she gave the “Don’t Be Vague” tip multiple exclamation marks.
It turns out this “don’t be vague” tip is quite hard for many people to follow. When we review our own writing, it’s easy for our brains to fill in the missing pieces, since we understood our intention in the first place. It’s much harder to review a proposal with an eye toward how someone else will perceive it. Which is why this next tip—which is probably obvious to you—is worth putting on the list.
Ideally people who both (1) work in the same general area, so the work language will be familiar, not foreign; and (2) who are good communicators, so they’re more likely to help make your words stronger. Sometimes, people on the program committees are willing to review proposals before you submit, too—and their inputs can be particularly useful.
Richard’s post has a few different angles to getting your conference talk accepted, and every time I read his post I find myself nodding in agreement. Enjoy!
Have I missed any important tips for getting conference talks accepted? Follow me on Twitter @clairegiordano and let me know.