POSETTE: An Event for Postgres 2025 will happen virtually Jun 10-12, 2025. Call for Speakers is open! 💥
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:
- interestingness: a topic people will care about—and learn from
- knowledgeable speaker who knows their subject & can communicate effectively with an audience—so people can follow, understand, and learn
- a hook: a compelling title & abstract that will hook people and entice them to attend
- fits holistically into the rest of the lineup: a talk that complements the rest of the talks at the event, that adds something unique, and doesn’t overlap the other talks in a significant way
So here we go, let’s walk through 16 tips on how to get your conference talk accepted.
1/ Be sure to fill in your bio
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.
2/ If there is a “submission notes” field, use it
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.
3/ If you’re a first-time conference speaker, give the talk selection committee insight into the prep you’ve done to go on stage
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.
4/Have an enticing hook of a title
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.
5/ Come up with lots of title options—and give yourself permission to write down “bad title ideas”, too
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.
6/ Do some research on last year’s accepted talks
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”.
7/ Try to make people curious with your proposal
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:
- Is the RDBMS the future of distributed databases? (question)
- How to get your Postgres conference talk SELECTED? (how to)
- I love managing database backups. Here’s why. (provocative)
- I hate Kubernetes (don’t worry, I don’t!)
8/ Your Postgres use case is way more interesting than you think
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.)
9/ Be willing to be rejected
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.
10/ Make sure your proposal is current
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.)
11/ Be clear about what you will teach people
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.
12/ Know what type of event you’re submitting to
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.
13/ Remember you have two audiences for the Title & Abstract
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?
14/ Use specific language
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.
15/ Review your proposal with 1-2 friends before you submit
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.
16/ Read Richard Schneem’s post on getting your conference talk accepted
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 of your most important tips?
Have I missed any important tips for getting conference talks accepted? Follow me on Twitter @clairegiordano and let me know.
