There are probably thousands of tech-oriented events being ran each day. From casual meetups to full-blown, multiple-day conferences with large budgets. A significant amount of them sources their speakers through an often anonymous, Call for Proposals process.
Thanks to platforms like Lanyrd, Call to Speakers or Callback Women it has become fairly easy to browse through potential speaking opportunities, but the materials advising on writing proposals or preparing a great presentation are still fairly sparse.
I was lucky enough to experience being both a curator and a reviewee. Drawing on my involvement with such events as JSConf.eu, JSConf.AU and RealtimeConf as well as over 20 speaking engagements I would like to share a few practical tips that hopefully will land your next conference speaking slot.
Always follow outlined Call for Speakers rules
This might seem too obvious to state but you’d be surprised to learn that at least 30% of ~2,500 proposals I’ve ever read violated the predefined rules for talk abstracts and submissions that have been set. I tend to think that some of the more experienced speakers simply skip the guidelines and copy-paste proposals for many different events but the only thing this leads to is the proposal landing straight in the “rejected” pile.
There are hard requirements and more forgiving guidelines, but no matter how adept in speaking you are do read the instructions carefully before submitting and ensure the proposal is following them.
A great example is the following instruction from CSSConf.eu:
If you need more than two paragraphs to get to the point of your proposal, we ask you to slim things down.
Alternatively conferences may ask for not disclosing names, employers or gender in the proposal itself amongst many other factors. Make certain you’ve understood what you’re being asked for.
Steer clear of sloppy formatting
When writing copy we frequently check for spelling and grammar mistakes, especially when launching product campaigns or applying for jobs. Conferences are no different in that regard. Typos, errors and general laziness are easy to spot and reflect negatively on submissions.
Take time to spellcheck the abstracts. If English isn’t your first language (it’s not for me!) ask a native speaker to help you out.
Ask friends to proof-read
No matter if you’re certain of the talk abstract quality or not it’s often invaluable to ask a few colleagues to proof-read not only for errors but also confusing statements (your spellcheck won’t catch that one, my friend). There’s nothing better than a set of fresh eyes, especially after butchering a proposal all night (we’ve all been there).
Be succinct
Many language exams set a minimum and maximum limits on their writing sections. Care to guess why? Imagine going through hundreds of papers if every participant decided to go well over the threshold. Skill and knowledge don’t require extraordinary lengths of text.
Most of JSConfs receive an average of 500 proposals, assuming a very strict 1-minute reading time per submission it’s still a full workday of reading. Each potential candidate deserves a thorough read and understanding of their pitch before rating, which is hard to achieve taking into account the volume and too wordy applications.
A good rule of thumb is two to three paragraphs clearly expressing your idea.
Use inclusive language and avoid shaming
While it entirely depends on the curators, I strongly believe inclusion and the way we choose to express ourselves in both writing and spoken language are something to pay close attention to.
Unfortunately, it’s fairly common to see ableisms and shaming in talk submissions. To clarify what that means I’d like to quote “Disabling Ableist Language” post by Andy Hollandbeck:
Ableist language is any word or phrase that devalues people who have physical or mental disabilities. Its appearance often stems not from any intentional desire to offend, but from our innate sense of what it means to be normal. When we use words like lame, crazy, insane, schizo, dumb, psycho, and spazzed without thinking, we silently imply — and readers infer — that mental and physical disorders are avoidable personal failings and not medical conditions out of a person’s control.
“How to stay sane as a developer”, “crazy hack” or “a dumb framework” are just a few examples I’ve seen around. As an organiser we always want to ensure safe, welcoming space for everyone and while oftentimes these mistakes happen fairly unconsciously it’s easy to educate yourself and avoid exclusionary, hurtful phrases. Shaming competitors, tools or individuals won’t get you far either.
It’s worth going through a Glossary of Ableist Phrases to cross-check your writing (and probably learn something in the meantime).
Stay away from product pitches
Most of events specifically state product pitches or any forms of upselling are strictly disallowed. However, it’s important to note the difference between a pure marketing talk (essentially trying to sell your business to the attendees) from an interesting case study that happens to consider the product you’ve helped to build.
The latter involves lessons learned that could be universally applied in solving problems the audience is experiencing in their day-to-day work. A product pitch doesn’t offer solutions, but focuses on highlighting the advertised product. Think of it as a 30–60 minute ad. Don’t be a salesperson (at least directly).
Show, don’t tell
“Show, don’t tell” is a well-known technique equally applied in fiction and non-fiction writing. Why is this relevant, you might ask? A few successful proposals implement it flawlessly.
Instead of simply stating opinions or facts (e.g. “React is the most popular JavaScript library”) as well as revealing all of your cards instantaneously, tell a story. Create a scene that can be visualised, especially from an attendee point of view. Is there a theme? What will I learn? Focus on take-ways and leave out some unknowns, that organisers will want to see clarified.
Use your creativity and be original
At tech conferences it’s easy to see framework or library-oriented presentations. While some curators see that as a benefit, I personally find it almost detrimental, with a few exceptions. Unless you’ve actually created the library you’re talking about and are able to offer first-hand insights that can’t be found in online documentation and blog posts I don’t see it offering much value to the attendees.
It’s fairly easy for anyone to step in, read available materials and prepare a mediocre presentation. Don’t get me wrong, I’ve done it too, which now makes me able to see why we can do better. Trust me, we’ve all seen the Angular 2 talks already. Don’t copy your predecessors. Interesting angle on React Native? Experimental usage of Rails to build a realtime app? Your own personal experiences and unexpected solutions? Yes please.
Submit more than one proposal
No matter how confident you are, never bet the farm on one idea—brainstorm and prepare several talks. No proposal is too experimental or not advanced enough to pass. It takes no mathematician to calculate your odds rising with the number of proposals submitted.
Be wary of remixing the same topic though; each one should have different talking points, angles or possible learnings for the audience to be considered as a possible winner.
Hopefully these few tips will get your proposal over the line. Happy writing!
Here are a few more excellent resources that you might want to consider reading:
- How to write a conference proposal by Mike Moore
- What your conference proposal is missing by Sarah Mei
- How to write a compelling talk proposal by We Are All Awesome
- Is your conference proposal good enough? by Raquel Vélez