CFP Advice

swyx 2020-01-18

I’ll assume you know what a CFP is and want to get one accepted (so I dont have to justify the value of learning in public) and are just here for my advice.

Table of Contents

Who Am I to Advise You?

I’m not a veteran, world class speaker. I don’t maintain any widely used library or framework. I don’t work at a FAANG. I started my first dev job in Jan 2018. My first meetup talk was in Dec 2017. My first conference talk was in Aug 2018. In the year-and-a-half since then I have spoken at 20+ events from ~250 person local community conferences to ~4k person bigger ones, internationally from the UK to Sweden to India and two JSConfs in Singapore and Hawaii.

I don’t say this to flex, merely to establish what I’ve done and also what I’ve not yet done (e.g. been a keynote speaker or emcee or be invited to some more “prestigious” conferences like React Conf, Abstract, StrangeLoop, Deconstruct, Smashing, or An Event Apart). I know I’m solidly B or C list. I’m starting to get conf invites, which give me more freedom from the CFP process, but I mostly still have to go through it. If you’re a beginner, maybe that makes my advice more relatable to you. Maybe not. Your call, I can’t change who I am.

Watch a lot of talks

Speaking and CFPs and the world of conferences have their own special language. And like any language, you learn best by immersion.

My YouTube Watch List is 400+ videos long. When I have lunch or am bored, I pull up a video and watch a talk. Most conferences directly copy + paste titles and talk abstracts into the videos, so start paying attention to those, since you’re about to start writing them.

(It also trains the YouTube algorithm to start recommending talks rather than entertainment)

You can find great talks at Sara Viera’s Awesome Talks site.

Speak at a Meetup

If you haven’t spoken at a meetup yet, I strongly recommend you do so a couple times before you speak at a conference. This is your first best trial run to get your speaking nerves out of the way, iron out the presentation technologies you want to use and also to trial your content on people who aren’t your dog. On the flip side, meetup organizers are generally always looking for speakers, because meetup attendees are a shy, lazy bunch :) so you will be doing them a favor. Some meetup organizers like GitNation actively use meetups to seed future conference speakers.

Pick a Conference

Once you know the conference, you roughly know the audience. First time speakers often have a goal to speak, but forget that as a speaker, you’re there to serve the audience and the goals of the conference organizers. So the better you understand the conference and the audience, the higher your odds.

You can find conferences via community listings:

If you’re new to conferences, “the game” can be rather opaque, so here are some basic, general facts (each conf will have exceptions!):

  • Conference organizers want to sell tickets, have a great content mix, and sell next year’s tickets, in roughly that order. Speaker selection is a major part of how these goals are achieved.
  • Fortunately, you don’t have to put butts in seats. Organizers will invite more famous speakers to do that. This is important: don’t do what they do. Not yet. They’re playing a different game, and the exact specifics of the talk/abstract matters less. You haven’t earned that yet.
  • Your job is therefore to be a part of their content mix. This mix will be determined by the target audience of the conference. The more established the conference is, the more important good mix is a priority since ticket sales are assured.
  • Community conferences are often framework or language focused. For example, JSConf takes a VERY wide variety of topics - you don’t even have to use JS or program for the web. It will always have room for the embedded JS talk or the creative coding talk or the other creative coding talk or the other other creative coding talk.
  • Company sponsored conferences are often around a certain architecture, even if you don’t use the particular company. For example, Netlify (where I work) sponsors JAMstackConf and invites speakers who don’t necessarily use or talk about Netlify. Scope is a little narrower and more “vertical” than “horizontal” if that makes sense to you.
  • A conference’s speaker slots are limited. A rule of thumb is 8-12 speakers per day, per track (you can get more lightning talk speakers at the cost of some full talk speakers). So a 3 day single track conference has a max of 36 talks. The applicant pool for a conference ranges from an average 200 to something like 800-1200 for a JSConf. (some conferences are invite-only). So your odds go down or up depending on these variables. A rejection doesn’t sting as much once you see how incredibly selective it is. It’s basically as nondeterministic as applying for colleges.
  • However since we already established the importance of mix, there are subgames to be played here. Even if 70% of CFP applicants use React, JSConf doesn’t want to suddenly have 70% of talks be about React. So CFPs get put in buckets, whether explicitly or subconsciously. React CFPs will be compared on their merits with other React CFPs. And there will be some less competitive categories. Again, this may not be an explicit policy, but it happens regardless. Because “good mix” - in the subjective view of reviewers - is so important.
  • Most conferences (again, with clear exceptions) will take big names over unknowns per domain. For example, if both Sarah Drasner and I were to submit a CFP on Vue or Design or SVG animations, they would be stupid not to take her over me. However if this happened in every single talk, there would never be any new faces on stage, no pipeline for the next generation of speakers. Given equal levels of unknown, employers also get taken into account. This is why “blind” CFP review is important for some level of equity, serendipity, and renewal. In my experience, most CFP’s are NOT blind. Mainly because putting butts in seats is more important for most conferences.

So as a first time speaker, your best opportunities are to apply to multi-track, multi-day conferences that have committed to a “blind” CFP review process, around a framework or language or architecture you know well, trading off topics you know vs their relative competitiveness.

You should also especially seek out conferences that put out high quality videos of every talk. This has two purposes. Part of your first talk’s job is to be a calling card for your next talk. Secondly, you can tell the exact nature and tone of previous talks that have been accepted for that specific conference.

Pick a Topic

Given you now know your target audience, there are two things to sort out before you really even start writing your title or abstract.

First, you have to find a topic. This is, at its simplest, finding the intersection between the things you’re very interested in and the things that everyone else is interested in. The simple reason for this disparity in interest is that you’re gonna be spending a bunch more time on this topic than the audience is, but you still need an audience to show up (and, more to the point, for CFP reviewers to rate you highly).

This intersection might either seem daunting or too broad to be useful.

  • If you find it daunting: you don’t need to have a ton of production experience in the topic to give a talk on it. You don’t need to be the creator of the framework or library. You don’t need to understand its internals. As long as you’ve probably spent more time on your particular topic than your audience, they’ll have something to learn from you. To some extent, you can even “mortgage your future” a bit - propose a talk on something you want to learn, before you’ve learned it, and use the talk acceptance as an artificial deadline. I don’t recommend always doing this, but I’ve seen it work well :)
  • If you find it too broad to be useful: understand that in aggregate, the interests of large groups of people are very predictable. They always want to know what the future holds. They always want a comprehensive introduction to something popular. They always want real life “war stories” of things they’ll probably have to do in future, from people who’ve successfully been through it. Developers always want easy ways to add design touches without being a designer. Vice versa designers. If you need ideas, play buzzword bingo. Accessibility, Automation, AI, Design Systems, No Code, GraphQL, Serverless, Service Discovery, Infrastructure as Code. Everyone has the same insecurities and in a way you are there to tap into, and satisfy, their insecurities. The base insecurity is Fear of Missing Out. Everything else is a derivative of that. More to the point, conferences with a similar target audience will likely have the same mix (and, more often than is probably healthy, the same speakers!). Conference organizers look to other conferences for inspiration, and so should you. (To be EXTRA CLEAR here: this is only if you need it - it is perfectly fine to do a talk about nonhyped technologies that aren’t buzzwords too. But humans do like buzzwords. 🤷🏽‍♂️)

A reliable way of gauging the interest of others is to look at community watering holes. What topics keep coming up on Hacker News, Twitter, or Reddit? You can niche down from megacommunities to industry ones - for web development this would be sites like Dev.to, CSS Tricks, and Smashing Magazine. What are the most active github repos? What are megatrends on package downloads? What are framework and library core team members putting out? What are company leaders (whether it is ones you work at or just notable ones in the news) doing that is interesting? But be aware that sometimes people don’t know what they want until they see it.

You can also gauge relative interest and your own interest by creating more. As I noted recently - ”Blog more. See which blogposts get abnormal traction.” Twitter, HN and Reddit are wonderful feedback mechanisms to gauge interest. The MVP of a talk is a blogpost. If you aren’t a great writer, that’s fine, you can also create demos. Diana Smith has made a career of CSS art and I’ve never read a blogpost of hers. You bet your ass she’ll be accepted to speak anywhere (I’m actually pretty sure she has spoken, I just can’t find it right now). Your YouTube watch history and GitHub timeline are also great indicators of revealed interests.

A special note on nontechnical talks: I love them. Advice on Career Management, Impostor Syndrome, Salary Negotiation, Working Remote, Learning in Public? They are great, and last longer than any technology you choose. Conferences should have more of them. They don’t. I haven’t had much luck with the few that I’ve submitted. The reality is that the ultimate customers of conferences are the bosses of the people attending conferences. They want to see some “I can use this at work” return on investment on sending their employees. Most bosses find sending people to technically-heavy conferences easier to justify, hence there is more demand for technical talks. Less cynically, the timeframes for measuring and getting return on investment (1-2yrs) dictate what you invest in.

If you work at a mission-driven company, for example a non profit or a government entity or school system or museum, definitely see how you can incorporate your social impact into your talk. Developers are always looking for more inspiration on how their tech reaches out to the “real world”, because most of us spend all day working on SaaS apps and marketing pages :)

Pick a Genre

Once you know your topic, there are several different “genre”s of talk, that will dictate your CFP title and abstract. Of course, you can choose not to stick to a genre, or to subvert a well known genre, but within the confines of a CFP it can often be easier to just stay inside a genre. I don’t have a full list of genres, since I haven’t been collecting them, so here is a nonexhaustive list:

  • The War Story: This is a great first talk genre for someone with some work experience. You simply tell a story of something you went through at work, including setbacks, lessons learned, and ESPECIALLY any quantitative benefits gained. You don’t have to be the world expert in anything except your specific situation. It usually helps if you work somewhere notable like AirBnb but a lesser known name is fine if you advertise the interesting elements of the story like Millie Macdonald did.
  • Library/Framework/Product Launch: Conference organizers like to be at the start of something big. To do this genre of talk well, you have to tackle an important problem, and sell the idea that you have developed a good solution for it. You don’t have to have made it yet, tho of course it helps. Examples: Dan Abramov, Ryan Dahl
  • How to X: How to do Error Handling in GraphQL. How to do Input Masking in Vue. How to make Static Sites Dynamic. How to Be a Web A/V Artist. 14 Ways to Bounce a Ball. You get the gist!
  • Introduction to X: This is easy Meetup fodder, but is more difficult to get traction at conferences, usually because conference organizers don’t want to be perceived as having talks which could just as easily have been on the docs or on README instead. So a good Introduction to X talk will also have to be creatively framed and titled. One of these I’ve seen recently is Louisa Barret’s Intro to Color Theory, except it wasn’t named that. It was titled The Teenage Mutant Ninja Turtle Guide to Color Theory. You can even add a single word like A Whirlwind Introduction To TypeScript. See how this works?
  • What’s New in X: Straight survey of what’s new. This is also often framed as “State of X”. You often have to be rather established to do this kind of talk, like Mark Erikson or Ben Ilegbodu, or Sarah Drasner or Evan You. But even if you’re not super established, you can also bring data like Sacha Greif or just straight up explain things entertainingly like Tara Manicsic.
  • Fundamentals: This is a GREAT genre for beginners (not that it is exclusive to beginners). CS Fundamentals like Algorithms, Data Structures, State Machines, and Coroutines are always loved because they reinterpret boring, dry things that everyone “should” know, in a more familiar, up to date context. But I name this genre more broadly because you can also think of other fundamentals to teach, like the JS Event Loop, Visual Design or Game Programming Techniques.
  • Live Coding: This is an intimidating genre to many, because a mistake can derail a talk without a satisfying conclusion. However, the “live wire act” fascinates audiences (same reason we enjoy watching circus performers doing death defying stunts we are totally aware have been extremely well rehearsed, but there is still a risk of catastrophy). Being able to watch working code in formation over time gives extreme confidence in the tool or language or concept being demonstrated. Two less appreciated benefits are the familiarity of IDE as presentation tool and the natural guard against rushing (first time speakers, like me, make the mistake of talking too fast to hide nervousness and risk losing audiences). My best talk is a livecode talk and I think interest in this genre is on the rise. SmashingConf is now organizing 100% livecode conferences, and React Live is also 100% live code.
  • Heresy Talks: Definitely not for the faint of heart. To do a Heresy talk, you have to go to a conference where >80% of people love Technology X and tell them why Technology X isn’t good enough (yet) or question the tropes fans tell to oversell it. See Corey Quinn’s Heresy in the Church of Docker or Robert Zhu’s The Case Against GraphQL (bit left field, but “Everything you’ve learned (about X) is wrong”). The pro is, attention is guaranteed with all your slandering. The con is, you better be confident in your claims or be prepared to be torn apart.
  • Intersection Talks: This is definitely downstream of picking your topic, but usually people with interests in X and interests in Y are underserved with talks about X + Y. There are an infinite number of topic intersections, too many to name, but just talk about the obvious tips and tricks and notes that come to mind when you consider intersections.
  • The Perf Talk: This is a great genre for speed demons. Pick a common usecase, start of with a very inefficient, very high number, and whittle it down with trick after trick. Here are examples from Jake and Surma and Sasha Aickin.

Pick a Title

Your title is twice as important as your abstract. CFP reviewers will look at both your title and your abstract. Conference attendees mostly only look at your title. Especially in multi-track conferences, most conferences only have room to print out your talk title, and that will often be the deciding factor between whether your talk has crickets or is standing-room-only (I know this from experience).

But no pressure: you can still tweak titles after getting accepted.

To the extent that your genre dictates your title, just go with that. (I’ll put all genre title examples above in the Genre section)

If you can come up with a memorable name that encapsulates your core pitch, like Never Write Another HoC, do that. If your talk is good, its title will be quoted back to you with surprising frequency, so make it something you can live with.

Examples:

Getting creative and eyecatching is helpful. Remember that CFP reviewers will mostly be scanning through hundreds of CFPs, usually in a Google sheet or table. Short titles stand out. Special buzzword keywords stand out. Again, scan through old published conference schedules to get an idea of what works.

If none of the above fit, don’t push it. Just take the most boring, practical title you can do that touches on the main technologies you’ll be demonstrating. Sometimes plain and simple is best!

Examples:

  • to be completed

Write an Abstract

With your genre and title chosen, your abstract will practically write itself. You sketch an outline of the talk you want to do. If it helps, you can try to bullet point out all the things you want to do in your talk, then group and sort your points, and then use that as brainstorm fodder for your abstract. Don’t give away the whole talk, but show just enough to pique interest.

Most conferences only ask for abstracts, but some will leave room for more context from you on why you are the best person to present this topic (it’s usually optional, but USE IT!!!).

The first paragraph of your abstract is most important, since it is what will be printed and on the YouTube description. Most abstracts are just one paragraph. Of that paragraph, the first sentence draws the attention. The last sentence seals the deal. As with all writing, Gary Provost’s timeless advice on writing applies:

This sentence has five words. Here are five more words. Five-word sentences are fine. But several together become monotonous. Listen to what is happening. The writing is getting boring. The sound of it drones. It’s like a stuck record. The ear demands some variety. Now listen. I vary the sentence length, and I create music. Music. The writing sings. It has a pleasant rhythm, a lilt, a harmony. I use short sentences. And I use sentences of medium length. And sometimes, when I am certain the reader is rested, I will engage him with a sentence of considerable length, a sentence that burns with energy and builds with all the impetus of a crescendo, the roll of the drums, the crash of the cymbals–sounds that say listen to this, it is important.

Do that, for your talk. Use less words if you can. Most of my abstracts are under 100 words.

Abstracts are great places to stick eyecatching datapoints. Did you know TypeScript is at 65% adoption of JavaScript users? or that 51% of developers use VSCode? Or that “we recently refactored 100K lines of JavaScript to TypeScript”? Or that I slashed my webpack build times by 20% with this one weird trick? We are suckers for numbers.

Most abstract submissions allow markdown for emphasis and simple styling. Use it. Sparingly.

Just like your talk title, you’ll rarely be held exactly to it. Nobody is watching your talk holding you to your abstract at knifepoint. You reserve the right to change things, hopefully not too drastically or too last minute. You won’t use this right often, but its there if you need it.

Run your abstract by a few developer friends, with no context. If they don’t get it, that’s a problem. You likely have a better idea of what your talk is than you’ve actually written down. Rip it up, try again. Be more obvious, less abstract. Appeal to what people will get out of your talk rather than the specifics of how to get there (which is the reason why people should come to your talk!).

Building a CFP Process

Ok, so you’ve written one CFP. Congrats! You’re not done.

You can see this 12 Minute Video of How I Write CFPs explaining my process below

As you’ve probably heard, due to the selectivity and randomness, CFP submission is a numbers game. So it’s more important that you build a sustainable CFP process than have any particular CFP get accepted. You’ll be submitting between 2-5 CFP’s per conference, and there are probably dozens of conferences each year that you are a good fit for.

So to avoid accidentally becoming a full time CFP writer, you’ll just want to have a bank of topics and title and abstract samples that you can reuse. I tend to run with 5-10 of these, of varying readiness to present (remember, you dont have to be a world expert in some of these topics to talk about it). Tweak each submission to the conference’s target audience as appropriate, like you would a cover letter in a mass job search. In a way, you’re kind of looking for a job, a very short term gig.

Get a good photo, use the same photo everywhere. People recognize faces faster than names.

Write a short bio, you’ll be asked for it over and over again. Don’t write down your life story, just a simple statement of what you do, what you identify as and what you’re generally interested in. As your speaking career grows you’ll want to have a short, medium, and long bio on your site for organizers to just copy paste without asking.

As you start getting acceptances and recorded talks, keep a list of your best talks. You’ll be asked for those in future CFPs. Make them easily discoverable and sharable, and people will start inviting you without CFP.

Example CFPs and Peer Review

Of course I have already given my advice that you should watch a bunch of talks and pay attention to titles and descriptions. But it really helps to have some example accepted CFPs so I will list what I have here:

People who have said they don’t mind reviewing first timer CFPs:

Other Advice

Peggy Rayzis:

It’s CFP season! Here’s the abstract template I use for crafting effective proposals:

  1. State the problem
  2. State your solution
  3. What the audience will learn from your talk (optional: how you plan to teach it)

3-5 sentences max.

I read hundreds of proposals for GraphQL Summit. For the first pass, I spend <30 seconds on each one.

Get to the point quickly. Otherwise, you risk losing my attention, which usually is a rejection.

Phil Nash - how to find CFPs

Next Steps & Recommended Reads

Phew, that was a long ass post. Hope it helps! Ping me if you get accepted, I will be cheering for you :)

I’m of course not the only source of advice on this stage. Here are other advice pieces I have come across:

I will also be following up this post with my thoughts on speaking advice - giving the actual talk!

Tagged in: #advice #tech #careers

Leave a reaction if you liked this post! 🧡
Loading comments...
Webmentions
Loading...

Subscribe to the newsletter

Join >10,000 subscribers getting occasional updates on new posts and projects!

I also write an AI newsletter and a DevRel/DevTools newsletter.

Latest Posts

Search and see all content