A few weeks ago I put up what was intended to be a throw-away tweet.
Going over my talk submissions for 2019. This is my hit-rate from just one submission tool.— Aaron Powell (@slace) November 29, 2019
Remember folks, you'll be rejected from a lot more talks than you are accepted! pic.twitter.com/4sbcn1QhrS
This tweet shows the success, or lack-there-of when it came to submitting to conferences this year, and this is only a snapshot of one platform, Sessionize, that I've submitted via. I also have rejections in Papercall.io and countless Google Form's. So from 4 talks across 7 events (total of 8 submissions) I only had 1 talk accepted. That's not 100% accurate from Sessionize, I actually submitted 16 sessions across 7 different talks to 7 events, of which 1 was selected. Wait, that doesn't sound any better! 😕
Taking all other systems into account I presented 6 talks at 6 events (and attended a few others) and was rejected from at least that many events on top of what you see in the screenshots above.
The tweet I put up sparked some good discussions with people about getting into speaking at events so I thought I'd take some time to share a bit of my experience.
I gave my first conference a decade ago at the very first DDD Melbourne. When I gave that talk I'd only attended a single conference, that was the Umbraco conference in Copenhagen, but I hadn't been there to speak, just attend as a contributor to the project. Back in 2010 the conference scene was very different to what it is now, there wasn't that many events and the events that existed tended to be vendor-centric events, like Microsoft TechEd, with thousands of attendees and a price-point to match. So when I saw people talking about DDD Melbourne I was interested in the idea of a conference that I could attend without needing to raise a lot of money for and that I, as a nobody in the tech community, could submit a talk to with the hope of presenting.
Fast forward to 2019 and I've been lucky enough to speak at dozens of events around Australia and the world and made it part of my job. But for every event I've spoken at there's many more that I was rejected from, I wouldn't have a clue how many talks I've been rejected from over the years, it's beyond the point where I'd bother to keep count.
And with the doom and gloom aside, let's talk about some positive and practical things around getting into conferences.
Rejection Is Part Of Life
This doesn't sound like a positive first point, but hear me out. When you break it down it's a numbers game, there's only so many slots at a conference and only so many conferences that you're almost always going to be over-indexed in the number of submissions. I've worked on the agenda for NDC Sydeny twice and each year we would receive over 600 submissions for the approximately 100 slots to fill (taking into account pre-booked speakers).
So going in with the understanding that you may not make it in and that isn't the end of the world is a good perspective to have. Some events will be able to provide feedback on why your talk wasn't selected but in my experience, there aren't many events that can do that. Take NDC Sydney for example, it's hard to be able to give personalised feedback to a few hundred people, but also sometimes the reasons are that there were just too many good talks and a coin was flipped.
And don't be a sore loser if you aren't accepted. It's frustrating and you might want to share your frustration on twitter by saying a conference has played favourites or had some unfair biases in the selection. That's not going to help you and it's more likely that you'd end up on a blacklist instead. Many conferences do have blacklists, whether they are people who violated the code of conduct, presented a misleading talk (turned out to be a blatant sales pitch) or presented themselves in a way that is against how the conference wants to be represented.
With that in mind, what can you do to improve your odds?
Restrict The Number Of Submissions
Some events are starting to place limits on the number of talks that they will accept from potential speakers, but not all do. If you're submitting to an event without a submission cap don't look at that as a license to go crazy. I've been on the agenda team for events where there have been people submitting upwards of 10 talks. When I see this it makes me wonder if the person has a handle on what they can bring to the event or are they just throwing everything at the wall with the hope that something sticks. And to have produced that many abstracts, how much time has gone into thinking through the story that you want to give to the audience?
Having only a small number of talks that you are constantly refining will help to solidify who you are and why you are an authority to speak on such a topic. Which leads me to the next point.
Are You Known For That?
While most events will anonymously do initial reviews, at some points they will look at the name of who submitted the talk and use that as part of the final decision. Conferences will strive to have the people speaking be people who are knowledgable on a topic, an authority if you will, so what makes you that person? Have you been writing about it on a blog? Answering questions of Stack Overflow? Discussing it on Twitter? Presenting at meetups about it?
This can be the difference when it comes to final reviews of sessions when you've got similar content or just a lot of really strong options to pick from.
For me, I tend to extract talk ideas out of blog posts that I've written. This means that I've been able to “prove” the content in the market by writing about a topic and that there's more than just a single talk submission to show that I know what I'm talking about. And this is why it'd be unlikely that I'd submit a talk about Kubernetes to a conference, as I have no previously demonstrated knowledge in that area.
Some people think that for each event they submit to the talk needs to be 100% new meaning they are always trying to come up with new ideas and are exhausted at the prospect. This isn't the case though. Now, I wouldn't be submitting the same talk to the same conference but that doesn't mean that you can't submit it to other events. After all, the attendees aren't going to all the same at each event, especially if you're submitting to events in multiple different cities/countries.
I, in fact, have a talk about Docker that I've been giving at least once per year for the last three years and I hope to keep giving it. Giving the same talk multiple times can be really enjoyable. You get an opportunity to refine it from the previous deliveries, expand on areas based on feedback and avoid the stress of having to write a new talk in the lead up to a conference!
Each year I'll produce a couple of new talk ideas, retire some old ones and continue to refine my favourites.
This is the critical piece of the puzzle to getting accepted, if you don't write a submission you're really unlikely to get accepted! 🤣
But how do we go about writing a good submission? There are countless articles online about this and I'll share what I've learnt over the years.
I'd argue that the title is the most important piece of information about your talk. It's the hook that you use to get people to read more, whether it's those reviewing the agenda or at attendee at the event.
The title should be short and to the point, but it's also a place where you can inject a bit of your personality (I like to use wordplay in the titles I created, but that's not for everyone). Let's take the title of one of my favourite talks, Docker, FROM scratch. Here it's clear what the tech we'll be covering is, it's Docker, and read literally, the talk implies it's something beginner centric or getting basic. Then there's the fact that FROM is capitalised in it, and if you haven't used Docker you're going to assume there's a reason for it, whereas if you have used Docker you'll identify that it's from a Dockerfile.
Also, try to avoid being too cliche with titles. Phrases like “from the trenches” are overdone and I would avoid using them. Similarly with click-bait style titles, they often just come across as gimmicky.
While the title is to grab someone's attention the abstract is to sell the talk. Like a title you want it to be to the point, no more than a few paragraphs, remember, your goal is to get people to attend your talk and learn something, not to learn it all from the abstract. I like to start by framing the narrative I plan to tell.
Docker's popularity has exploded over the last couple of years, especially in the DevOps space, but unless you've spent a lot of time in that area it can be a confusing technology to wrap your head around.
From here you can then go into why you're the one to talk about this, how you'll show off your knowledge, etc.
An abstract can be written in either the first or third person and that will come down to how you like to represent your talk idea. When I write an abstract around a particular bit of tech/product/problem I'll often go to third person.
We'll look at how to apply x to y.
Whereas if I'm writing a talk that's purely about my experience I'll go to first person.
I'll show you how I learnt about x.
But experiment with it, see what reads well when you read it back.
Also think about creating an elevator pitch, a single sentence that summarises your talk as some events may use that.
The final main piece of any submission is your bio. Use it to tell people who you are and why you are the person who should speak on a particular topic. Keep it short, only a paragraph or two, don't mistake this for a resume, focus on the information about you that is relevant for the event, if you're submitting to a front-end web event, your in-depth knowledge of SQL Server might not be that important.
I like having a couple of different length bios, a one-liner for meetups and summaries plus a full bio for conferences.
When it comes to writing your submission there are a few things that will hurt rather than help you.
a long and rambling abstract that lacks any form of punctuation grammer correct spelling or capitalisation will not be doing you any favours so remember that you should always put it through a spell checker and or a grammar checker even something as simple as pasting it into a word document to do a sanity check before submitting will be valuable as a poorly written abstract doesn't do much to help your credibility as someone who is knowledgable in a certain area.
The same can be said about your title and bio, if you can't take the time to ensure you've spelt words correctly, properly cased product names or ensured you have punctuation, how does that give confidence to the event that you'll put the effort in for them?
Speaking of professionalism, don't be overly critical of things in your abstract. Your talk may be about one framework when there are others, but don't bad-mouth the others, it's not going to be constructive nor will it show that you're being objective.
Get A Peer Review
Once you've written everything down as friends and co-workers to have a read of it and give you their thoughts, after all, they are the kind of people who you want to attend the talk, so why not see if they are finding it interesting.
Where To Submit
This is probably important isn't it, after all, if you don't have somewhere to submit your talk then what's the point? 🤔
Trying to work out what's on when can be difficult, with dozens of events happening around Australia and most of them announcing via Twitter it's easy to miss them. My first point of call is to check out the DevEvents GitHub repository, which is a crowd-sourced list of conferences happening around Australia including important dates and a link to the event (and if you learn of one that's not there, submit a PR!).
Be aware that a lot of conferences in Australia happen between August and November, probably related to the new financial year budgets being available to sponsors, but this can result in a mad rush of events opening their Call For Papers (CFP) and a lot of travel in a short period.
When To Write The Talk
You've written a submission that you're excited about, so it's time to sit down and write the talk right? I hold off, I won't start writing my slides/demos until after I know I'm giving a talk. Mainly I do this because I don't want to “waste the effort” in writing a talk I might never deliver. But given that a lot of the talks I do are based off blogs that I've previously written I will have a starting point that I can write the talk from, which I find speeds up the process.
This is a bit of a random hodge-podge of ideas rolled together into a post based on my experience on public speaking over the last 10 years.
It might look like it's been a tough year, doing 6 talks out of the ~30 submissions, but it's pretty standard. Sure, it's frustrating when you submit a talk that you're really excited to deliver only to have it rejected, but it's not the end of the world.
If you're looking to get into conferences I'd encourage you to attend a Global Diversity CFP Day if there's one in a city near you. Also, here's two articles that I think are quite helpful in creating a good submission.
I'm also happy to review topics for people before they submit, just drop me a message.