Speaking at developer conferences can be a great resume boost. It can help establish you as an expert in topics that interest you, help connect you with other developers who share your interest and expertise and – last but not least – help subsidize the cost of attending an event (through free tickets and/or travel stipends). But the CFP (call for papers) can be a difficult rite of passage for many folks. In this post I want to share some strategies for writing a CFP submission that will hopefully increase your chances of success.

First, let me clear the air for a moment. I am not putting myself out there as having all the answers. However, I have been on both ends of the CFP as a potential speaker and as a conference organizer for about 15 years. What I hope to share are things that I've found can help a CFP stand out during the review processes I've been a part of, but also things that have worked for me in getting my own CFPs accepted. It certainly doesn't mean that I don't get rejected (I've gotten rejected by countless conferences over the course of my career), but these strategies have been effective in helping get me accepted.

Second, it's worth sharing that as a conference organizer, I am not a fan of CFPs. I think they tend to heavily favor those who have a lot of experience writing CFPs and with the process of submission. This means they tend to favor folks who are often part of the "conference curcuit" (DevRel folks like me for example). This can make it tough for new speakers to break in and, sad to say, even lead to a less diverse set of speakers. I get why organizers use them – for a large conference, finding and inviting all the speakers you'd need would be a monumental task. So the CFP is often a necessary evil, but hopefully some of the tips I lay out here will help even the playing field.

Choosing a Topic

There are two strategies I recommend for picking what topic or topic(s) to choose. When in doubt, always choose the first strategy because it usually makes the best talks.

1. Talk about what you are most passionate about! Whenever a speaker asks me what they should speak about, I always respond, "What topics are you most passionate about right now?" This seems like common sense, but if there is a tool/framework/strategy/topic you are excited about or that you know particularly well, pick that first. Enthusiasm for a topic can often come through in a CFP, but also these are always among the best talks and are the easiest presentations for you to create.
2. Pick a topic that seems more likely to get accepted. This can often be hard to determine but I tend to look at the topic list from a conference (this is usually somewhere on the CFP page) and take an educated guess about ones that are less likely to have as much competition. In some cases, you can even reach out to the organizers and see what topics they are in most need of. Writing about the latest hot topic/tool/etc. will likely mean there are a lot of similar talk submissions to yours, but picking a more "obscure" topic might give you a better chance of standing out. I've even gone as far as to pick a topic I don't really know (yet) and used the session as a forcing function to learn it. I don't necessarily recommend this as it can be incredibly time consuming and difficult, but it was a strategy that has worked to get me into some very competetive conferences in the past.

It's worth noting that if you have a topic that manages to hit both strategies, go for that!

Picking a Title

When writing the title, keep in mind the three Cs:

1. Clear – Don't leave the organizer/attendee guessing what your session is really about (this is often the result of being too clever with the title). Often organizers are looking for specific topics or to make sure they have enough variety of topics. The title is the first thing they see and, especially if there are a lot of submissions, the title is often the only thing they use to determine which sessions to prioritize reviewing. So, the primary topic of your session should be immediately obvious from the title.
2. Creative – The best titles tend to have a little fun or convey some sense of urgency (or perhaps both). For a "fun" example, instead of "Building Websites with Astro" or "Getting Started with Astro", I went with "Lifting Off with Astro" which has a little play on words. For an urgency example, instead of "What is the Serverless Edge?" or "How to Use the Serverless Edge", I went with "What You Need to Know About the Serverless Edge."
3. Concise – While this isn't necessarily the case for blog posts, when it comes to session abstracts, longer titles are generally not better. I suggest trying to keep it to 5 to 10 words maximum (and yes the 10 includes words like "the", "with", "on", etc.).

How Long should CFP Abstract Be?

In my opinion, the ideal CFP is 1-2 short paragraphs. A short paragraph is no more than 3 sentences. You don't need to cover every detail – focus on the main point and key takeaways of your presentation. If you find that you can't cover that in 2 short paragraphs, perhaps you need to refine the topic a bit. In some cases, particularly for hands-on sessions, this might be accompanied by an outline but in most cases that isn't necessary.

Structuring Your Abstract

While it's not one-size-fits all by any means, I have found that the simple structure I lay out below tends to be very effective:

1. State the "problem." In a sentence or two, what is the issue that the thing you are going to teach solves. For example, if you were giving a career-oriented talk, you might say, "Navigating your career as a developer during a tech downturn can require a lot of careful planning." Or if you were giving a talk on Svelte, you might say, "As page weights have continued to grow, developers need to be more conscientious about the impact their framework has on JavaScript bundle size."
2. State the solution. In one or two sentences, how does what you are going to teach address the problem you stated. Continuing the above examples, you might say, "However, there are a number of tried and true strategies that can help ensure that your career growth isn't stunted by a down economy." Or, "Svelte provides developers the reactivity modern web applications require on the frontend while also reducing the amount of JavaScript the client needs to download."
3. Clarify the takeaways. This is the critical piece many CFP submissions tend to forget. In a sentence or two, give some detail on what you will show and what the audience will take away from the session. Again, continuing the above examples, you might say, "In this session, I'll explore career advice from a variety of experts and show how you can practically apply these to advance your developer career." Or, "We'll dig into the code of an example Svelte application that demonstrates the core concepts you'll need to get started using the framework." Feel free to add more specifics here. For example, you might follow up that last sentence with, "By the end attendees will learn how to install and configure Svelte, how to create components and how reactivity works in Svelte."

I am not saying every CFP abstract needs to follow this structure. You can feel free to be creative. In some cases it may not entirely suitable for your specific topic or the required format for a particular conference, but it is a good default. I would stress that if you do stray from this format, you should always include the takeaways regardless.

How Many Sessions Should I Submit?

Some CFPs have a limit to the number of submissions you can make, but my advice here is to submit more than one if you really want to speak at a particular event. It's important to remember that most organizers are sifting through a lot of submissions, and often can't give every submission the attention it deserves. The techniques above will hopefully help yours stand out, but submitting more than one simply increases the chances that one of your submissions is seen and the chances that you have something that fills a gap in the schedule someone else didn't already fill. In most cases, I'll submit 2-3 sessions for a given CFP (more than 3 seems to be getting excessive in my view).

Keep Track of Your Submissions

I don't mean keep track of submissions just so that you can follow up or plan, I mean save the title/abstract and other details somewhere. This is a mistake I have frequently made in the past, which is to submit a CFP without keeping a copy for myself. There are two reasons for saving these.

The first is that even the most experienced speakers tend to get rejected all the time. A CFP submission takes a decent amount of work and just because it got rejected from one conference doesn't mean it will get rejected from another. Keep a copy so that you can keep refining it and submitting it. For example, create an Obsidian vault with all your submissions.

The second is that talks themselves are often an enormous amount of work. If you hit on a good talk, don't be afraid to reuse it. A handful of conferences won't accept talks that have been given elsewhere, but most have no issue with it. Take any feedback you may have gotten from the previous event(s), update your abstract and reuse it. Honestly, the more I give a talk, the better it tends to get.

Good Luck!

I hope that these tips are helpful to you. And if you are looking for someone to give your CFP submission a quick review before you submit it, feel free to reach out (you can use brian at cfe dot dev). Lastly, if you are looking for a good place to give your talk, I'd love to consider your talk for cfe.dev where we welcome speakers of all experience levels.

Header photo by Matheus Bertelli: https://www.pexels.com/photo/photo-of-people-sitting-on-chairs-3321789/