Three tips for getting a talk accepted at Fluent

… or any other technology conference, tbh.

Note: this post is not endorsed by Fluent or its organizers. It’s just my thoughts as a committee member who reviews a lot of proposals.

Fluent’s 2017 call for participation is open until January 10th. As a program committee member (there’s about 30 of us), I have the privilege of reviewing talk proposals to help the program chairs decide which talks will take place at next year’s conference. I’ve already reviewed about 30 such proposals, but with 3 weeks to go, I know hundreds more are on their way; most people submit within days of the deadline closing.

If you’re thinking of writing such a proposal, I have a couple of pieces of advice you should consider before hitting the submit button. If you follow them, not only will you make my life easier as a reviewer (your #1 priority, obv), you’ll greatly improve your odds of having your talk scored highly — and thus more likely to get accepted.

So without further ado, here’s three tips for getting a talk accepted at Fluent (or any other conference, tbh).

Write a detailed abstract

This is my 3rd year reviewing talks for Fluent, so I can say with some confidence that only 20% of proposals contain detailed abstracts. Most only include a few short paragraphs. Some only a few sentences! (Side note: this is crazy.)

Unless your name is Paul Irish, there’s just no way I can accept a talk that is described vaguely in a few sentences. If you’re thinking of submitting a talk, spend a few more minutes on your abstract and describe your talk in detail:

• What concepts, technologies, and/or libraries will you cover?
• What is the order in which the content will be introduced?
• What will the audience learn?

Basically, we’re looking to see that you’ve thought about your talk more than just an idea hastily scribbled on a napkin. The more you can tell us about what you’re talking about, how you’re delivering it, and what the audience will learn from it, the more confidence we’ll have in scoring your proposal highly. If this is a brand new talk that you’ve never delivered before, these steps are particularly crucial (even fuzzy details are better than none).

Submit multiple proposals, but not too many

To improve your odds of having a talk accepted, you should consider submitting more than one proposal. Many conferences advise this in their calls for participation, and most people submit 2 or 3.

The flip side is: don’t go overboard. Many people take this advice of submitting multiple proposals a little too far. If you’re thinking of submitting as many as 10 proposals, there’s a couple things you should know first:

• Reviewers are looking for speakers who are passionate about their chosen topic(s). The more proposals you submit, the harder it is for us to gauge what topic you’re passionate about — if it’s any of them at all.
• You’re less likely to write detailed abstracts, which is likely to affect your proposals negatively.
• Reviewers may get tired of seeing your name back-to-back-to-back, and may subconsciously begin to tune you out once they reach “React talk variant #8”.

My advice: stick to 2–4 proposals. And as a general rule, 2 well-thought proposals easily outweighs 4 vague ones.

Share your unique perspective

As I’ve mentioned earlier, it’s common for multiple people to submit proposals about the same topic. Ideally, you should find a way to stick out from other proposals. You’ve learned one such way is to write a detailed abstract (seriously, it’s easy, do it). Another is to be Kyle Simpson or some other web development/JavaScript celebrity. For the rest of us normals, the next best way is to share your unique perspective on the topic.

You might not think you have a unique perspective on a given topic, but you might surprise yourself:

• Do you use this technology / topic at your organization? (this 100% counts and is probably the most common)
• Are you an author, maintainer, or contributor to the technology? Even if you submitted just a single patch or issue counts.
• Have you blogged about the topic? Or given an informal talk about it? Did you learn it or use it at a hackathon?

Fluent gets a lot of talk proposals that may as well be labeled “person with no clear connection to technology X delivers a talk about said technology”. And those talks are always welcome and will be accepted just fine. But if you have an opportunity to frame your talk around your unique perspective on the technology, IMO that is always ideal.

For example, “How we use Angular at my organization” is always a better proposal than “How to use Angular”. Similarly, “How I got involved in open source and you can too” is better than “How to get involved in open source”. Another way to think about this: you may not be the authority on functional programming, but you are 100% the authority on your experience with functional programming.

There is no shortage of Angular tutorials or condescending Medium posts (hi Mom!) about how to contribute to open source. But what will always be in short supply are real stories and real experiences from real people. If you can figure out how to fit your unique perspective into your talk proposal — fully acknowledging that not everyone can or will — I strongly encourage you to.

So, that’s it: 3 tips for getting a talk accepted. If I were to highlight one tip in particular, it would be the first one: write a detailed abstract. It’s the easiest, objective thing anyone can do and I guarantee it will help regardless of experience, background, or chosen topic. Seriously, take 5 more minutes and do it.

Once more, the CFP for Fluent is open until January 10th, and I encourage everyone who’s interested in sharing their interest or experience in web technology to submit a proposal. If you haven’t delivered a talk before, or need help coming up with a topic, or just want to shoot some ideas off of someone, I’m @bentlegen on Twitter and I’d be glad to lend a hand.

On a final final note, I want to repeat again that Fluent receives hundreds of proposals — over 500 last year — for less than a hundred speaking slots. Statistically speaking, many people will apply and not get selected (I’ve been rejected many times). If that happens, don’t get discouraged. Try submitting to other conferences, or even try the same proposal at Fluent next year. Web development topics don’t go stale overnight (e.g. there have been talks on Promises every year since 2010), so your hard-written proposal can be re-used in the future. So don’t take a rejection personally; just try again until it works.

Shout-out to my fellow Fluent committee members @jsoverson, @andydavies, and other reviewers for helping convince me this article is not 100% trash.