CFPs: Writing Recommendations

One of the main responsibilities of the developer relations team at Meilisearch is to help our open-source search engine reach as many developers as possible. This involves, among other missions, participating in conferences and events.

Conference organizers usually publish a Call for Papers / Proposals (CFP), which is an open invitation for speakers to apply to their event, usually with a title and an abstract at minimum. Over the last year, I’ve had to submit—or help colleagues submit—numerous talk suggestions to conferences. Being a novice in the field, I set out to discover some of the secrets to successfully responding to a CFP.

I read a lot of articles and even listened to an hour-long presentation about CFPs so you don’t have to 🙌 In this article, I’ll present what I’ve learned based on the most recurrent recommendations.

The abstract

The abstract is your pitch, it’s what is going to be published. You should focus on this first as it is what helps people decide if they want to attend your talk.

✅ Do's

Be direct and concise

Put yourself in the evaluator’s shoes. If you have 100 submissions to go through, you’ll appreciate the ones which get straight to the point. You should make your abstract easy to skim-read.

Target your audience

You need to know your audience,  their needs, and interests. Are you going to talk to developers, designers, executives, or some other audience?

Ok, but if it’s your first time attending a particular conference, how do you get this information?

Well, sometimes conference organizers provide an audience profile. But if it’s not the case, here are some good tips by the great VM Brasseur:

• you can contact them and ask for it

If it’s too late for that:

• check the sponsorship prospectus: there’s usually information about the audience
• check the schedule and social media of past editions of the event

Establish a challenge or a problem

Your talk should be about something that interests you. It could be a problem you’ve had, or that you’ve helped someone with. It doesn’t matter so much if you have managed to solve the problem or not. You can share your experience and what you’ve learned from it.

It can also be a widespread opinion you disagree with, a tool that has helped you, or something you wish you had known when you started.

Don’t forget, people like hearing stories, so if you think it’s something worth sharing, go for it. If you're not sure, assume that your story may be interesting to others. So go for it, what's the worst that can happen? Either way, try to present it in a way that gets your audience's interest, that’s why it’s important to know who you are going to be talking to.

Specify the format of the talk you are giving

The potential audience wants to know what to expect: is it going to be a workshop, a case study, a live demo? We all have different learning styles. Knowing the format beforehand will help the conference participants select the right talk for them.

Specify the background knowledge the audience should have

Should the audience know a particular programming language? Is it suitable for beginners? Giving this type of information will avoid wasting the time of the attendees.

List key takeaways for your audience

There is a statement from Sarah Mei that stuck with me:

People don’t go to talks for the content. People go to talks because they think they’ll become more badass. So help them out with that!

People want to know what they will learn from your talk, the specific benefits they’ll get from it, what they will be able to do after your talk that they could not do before.

❌ Don'ts

Don’t pitch your company / organization / product

Nobody wants to hear a sales pitch. Your proposal will be rejected if it looks like a commercial in the slightest.

If you want to talk about something cool your company does, focus on the problem solved.

A little trick is to do what the dotConferences organizers have named the Steve test. Imagine an attendee named Steve, seated at the front row. Steve is so stubborn you know he would never use your product. The challenge is to make your talk as engaging and insightful to Steve as to anyone else. It will only work if you focus on the technical insights rather than your product. You can include your product along with alternative solutions and present the benefits and downsides.

Don’t be aggressive or condescending

Please have your abstract reviewed by a colleague or friend, preferably a native speaker. Someone who might identify this kind of language or tone you may not have intended to have.

Don’t present your solution as the perfect one

Be humble. You may have a great solution, but it cannot fit every need and context. You don’t want to sound arrogant so talk about when your solution is appropriate and when it’s not.

Don’t include identifying information (name, title, company)

This information belongs in the bio, not in the abstract. A lot of conferences practice blind reviewing to ensure submissions are reviewed fairly, so if you don’t want your proposal sent back for modifications or rejected, it’s better to avoid sharing these details.

Don’t deceive the participants

Don’t make promises you are not going to fulfill. Maybe you will get more people to attend your talk, but at what cost? Leaving the audience with a feeling of disappointment?

Standard formula

If you are new to CFPs you may want to stick to the following structure when writing abstracts:

• Start with a strong introductory sentence that grabs attention (why is your topic important or relevant)
• Detail paragraph: specific points you are going to address, give people an idea of what to expect
• List audience takeaways
• Closing paragraph (if needed)

The title

• Write it at the end, once you have finished writing the abstract
• Avoid jokes: you never know how they will be perceived
• Be polite
• You can go for clickbait, it works
• Keep it short, less than 50 characters

In his 2016 “Three tips for getting a talk accepted at Fluent”, Ben Vinegar, gives really good examples of how to modify titles to engage the audience and show your unique perspective:

'How to use Angular' can be transformed into 'How we use Angular at my organization'.

'How to get involved in open source' can be tweaked to become 'How I got involved in open source and you can too'.

Points worth remembering

• You are trying to persuade people to spend X minutes of their time listening to your presentation
• Bullet points and short paragraphs are your friends
• Focus on the audience, use “you” sentences
• People like real experiences about real people: tell a story, create a narrative
• You don’t have to be an expert on the subject, but don’t suggest subjects you are not qualified to talk about
• You are the expert on your own experience

Conclusion

I hope you’ll find this article useful. Of course, there is no magic formula for your application to be accepted. There are a thousand reasons why your talk can be rejected, even if you have the best title and abstract in the world. But it’s always better to stack all the odds in your favor!

---

Picture by Etienne Girardet on Unsplash