Is there an art to submitting talks to speak at tech conferences? What are the boxes you need to tick when submitting a talk for a specific conference? In this article, we will try to cover most of the aspects you need to consider at the time of submitting a proposal for a tech conference. These tips and tricks come from members of our Organising Committee. This advice is not only meant to be practical for J On The Beach, but for any tech conference.
Note: Although it is called a “Call for Papers” and the spirit is similar, papers are submitted to academic conferences and it is a completely different world and process for Tech conferences.
Choosing a Topic
Ok, so you want to become a speaker at a conference but don´t know what to talk about. Well, as Ted Neward states in his blog about Speaking Tips: how to Write good proposals, the first thing you need to do is…
READ.
Most conferences have similar wide topics where you might be able to share your experience/knowledge, but it is important that you focus on the ones you are submitting to.
In the case of J On The Beach, you can easily read the topics on our website and CFP: Distributed systems, DevOps and Architectures, ML and AI, Functional Programming… there is no restriction on programming languages. However, considering these topics, a talk about how to use the latest Javascript library might not be the best fit for our event.
Does it mean that if you have a talk that is not specifically covered in our topics that it is not going to be selected? No, we are not that narrow-minded, and sometimes general or non-related topics might be very welcome in our selection. But it might be a risk that your proposed topic will be considered less relevant and then rejected.
One thing that, I personally consider, might be useful at the time of deciding a topic is to know who you are writing the talk for and then try to empathise with them.
The first people who are going to read the proposal are the members of the programme committee so if possible, check about their background and interests, their Twitter account, LinkedIn, etc. Check also the social media from the event to get a feel for their tone of voice. All of this might give you some hints about the conference and how to approach the topic.
At JOTB, the members of our organising committee have a diverse background mainly focused on distributed systems, Java and DevOps technologies but there are also non-technical people like me who take into consideration non-technical aspects of the submission like the speaker’s motivation or communication skills.
For all attendees or for a niche?
You will probably have more chances to succeed if your talk is related to a topic that is generally known by most attendees and not with a very narrow one that will only be of interest to few people. However, if you consider that this topic might delight the likes of our programme committee, just go for it. I have seen opposite ratings for a talk that was considered too narrow from one member and extremely interesting by another. So, it is really your choice but if your topic is too narrow and the proposal is accepted do not get disheartened if not many people show up. At least you know they will be enthusiasts.
Up-to-date, new and original!
Another suggestion at the time to select a topic is to choose a relevant and up-to-date topic that might be interesting for the event and I am not talking about blockchain…!
One of my favourite talks from out of all the editions of J On The Beach is probably Joe Armstrong’s “Good ideas that we forgot”. In this talk, good old Joe describes his experience and thoughts about these ideas; he makes them his own and makes these ideas relevant to our current time. There is no blockchain, no microservices and no quantum computing but just old ideas that can be useful to our current time period.
Now that you have an idea of a topic you want to submit, let’s start writing.
At some point, writing a talk for a tech conference is like writing an elevator pitch. In 3-4 paragraphs you will have to explain the problem you want to solve, describe the solution that you are planning to share with the audience and the key takeaways and give a short intro about yourself.
You will probably have a rough idea of what you want to share and like many speakers you won´t work on the whole talk until few days before the event, and that is perfectly fine but at the time of writing the talk, you should be clear, concise and structured.
The Title
Short or long?
I personally think that length is not a problem if it is no longer than 10-12 words and easy to remember. You should consider that your talk must be later published on webpages, mobile apps and printed on leaflets, banners and agendas where space is limited. The design and marketing people from the conference will curse you and they will cut it wherever they think it looks nicer and that might mean that no one knows what the talk is about. On top of that, attendees don´t go to listen to your talk on the “Busy developer guide and the hitchhiker coder had a microservice baby without the hype in la-la- land”.
Catchy or aseptic?
On this point, I personally disagree with Ted Neward who thinks that catchy or cute titles are not appropriate and it’s better to keep plain and boring titles that help the audience understand what the talk is about. I do agree that it is going to be easy for the audience to identify the topic of the talk, but I do also think that a boring title would not help the speaker stand out from other talks taking place at the same time.
I personally do enjoy catchy, original and appealing titles. That said, I have found that there are many idioms overused on the titles of many talks that have been copied from one conference to another like the following:
-
“The busy developer’s guide to…” (sorry Ted) this also usually appears as “The hitchhiker’s guide to…”
-
“blah blah blah without the hype” aka “blah blah blah without the fuzz”
-
“X on steroids”
-
“WT*” and “What the hell...anyway”
-
“From X to Y: 5 golden rules…”
-
“Mastering XXXXX” and “Getting started with YYYY”
It does not mean that these idioms are wrong options and we have even accepted talks like these but I personally find original and fun titles more appealing.
In case you cannot find an original title just go for a straightforward title for your topic and that will probably work better.
Abstract
High level or detailed?
One thing that has been discussed in some posts like Ted’s, Zach Zolman’s or the excellent post from Katharine Beaumont from Devoxx UK is whether the abstract should be high level or detailed. While the first two consider that it is better to keep the abstract abstract, the latter nudges you to go for details.
I had many doubts about this and at the beginning, I was inclined to go for the golden middle road but, after reading many of the comments from the rest of the members of JOTB’s programme committee about high-level talks I changed my mind. Now, I think that the abstract should get into details of what the talk is going to be about. If the abstract is too abstract there are always doubts and comments wondering whether the talk might be too basic or even if the talk is full of smoke.
Concise and to the point
You have 3-4 paragraphs maximum to explain what the talk is about; in fact, you can write far more, but consider that our time is limited, and more than 4 paragraphs is already going to be too much.
Here is a good outline:
-
Paragraph 1 - Introduce the talk, the pain, the problem you faced
-
Paragraph 2 & 3 - Go into details about why and how you solved the issue at hand
-
Paragraph 4 - Summarise the key takeaways of the talk
And be as targeted on your topic as you can.
A common mistake I’ve seen in recent proposals are abstracts where the speaker tries to cover a lot in a session. Yes, you want to explain how to solve all scalability problems existing in the world but unfortunately, you will only have 50 minutes maximum and if you write this in your abstract, you will just generate many doubts about how deep you will be able to go in your talk.
Good things to have in the abstract
For me it’s always a plus if the speaker plans to include the following:
-
Live coding
-
Demos
-
Interactive activities with the audience. (Why not try to use sensors or beacons shared within the audience?)
-
Daily life applicability
-
Hardware is always welcome
Things to avoid
All sales pitches
I must say that there are always doubts when a speaker plans to share lessons learnt while building vendors solutions or when the speaker wants to sell a product masked by some OSS behind it. Considering that many OSS are ultimately supported by corporations it is difficult to draw a line to what is exactly a sales pitch or not. You should be quite clear about the key takeaways attendees will learn with or without your product.
Sloppy reading
We mentioned this at the beginning of the post. Read the conference’s instructions.
About 20% of the proposals at J On The Beach are rejected because speakers don´t answer the few requests we ask in our form.
We always ask the following:
1.- Provide a link to a video of a previous speaking engagement. In case you do not have a video it, record a short introduction with your mobile or your computer.
2.- Tell us the reasons why you want to be a speaker in JOTB.
-
Please be original!
If applicants do not provide a video AND explain the reasons to take part in JOTB the paper will not be examined.
Many times, applicants don´t provide a video or the video is not in English. If the video is not in English then we usually ask for it.
If the applicant does not provide a video or reasons to speak at our event and we feel the application is practically a copy-paste from another event, we usually reject the proposal.
On the other hand, I give an extra rating to people who do not have any talk recorded and provide instead a short introduction of their talk recorded on a mobile or webcam.
At the time of explaining the reasons why you want to speak in an event, try to customise and personalise your reasons. There are common reasons that are often used like those about “sharing your knowledge”, “ you like teaching”, “you like public speaking”, “you are the best person to give this talk”, “you have 100 years of experience”, etc.. Even though these reasons might sound honest, they also sound very general and could be used for any other conference in the world. I recommend you to explain why you really want to speak at our event, what you do like about it. Is it the beach? Fine. Is it because you like Spain? Great. Is it because of previous speakers like X, Y, Z? Awesome. Show some interest, show off your personality, and make the programme committee feel that you are strongly motivated to become a speaker in the event.
I am sure that if you start customising your answers (even a little bit) and show some interest you will increase the percentage of talks you are accepted to.
New talk or not?
Although I do understand that many speakers submit the same talk to different events, I usually give an extra rating to brand new talks that have not been presented in other conferences yet. At the end of the day, all events want to be unique, exclusive and original and I value if the speaker considers our event the same way and prepares something special for us. Or at least, the speaker can tell us that our event is the first place where this talk will be given.
In summary, there is no magic recipe to master talks as at the end of the day each conference has their own process and different committees. I have just shared our own experience rating 5 years of talks at J On The Beach. I hope some of these tips might be useful for other conferences and I encourage you to keep on submitting your talks to J On The beach now that you know our secrets it will be easier to succeed.
Good luck and see you on the beach!
Luis Sánchez
Co-Organiser JOTB