What even is this?
This is a full chapter from my started-but-never-finished book called Conference Speaking for Everyone. I’m posting this finished single chapter that’s been sitting on my laptop for nearly a year to a) Get some feedback and hopefully some impetus to finish the book, and b) Put what I hope is some useful information into the hands of the people who need it. So enjoy the entire full chapter (all 3000+ words of it), and if you like it and would like to see the finished book… MAKE SURE TO PESTER ME ON TWITTER!
— Gary
Call For Papers
So, How Do People Get Selected to Speak at Events Anyway?
In my experience, there are two ways speakers end up presenting at technical conferences. Either the conference organisers ask you directly if you’ll speak at their event, or there is a Call for Papers (CFP). As a new speaker, it’s unlikely a conference is going to ask you to speak directly, so you’ll likely get into the habit of looking out for Calls for Papers.
A CFP is when a conference invites potential speakers to submit the information on the sessions they’re interested in delivering. This information grouped together is often called an abstract, and once the conference has enough abstracts, or a set time has passed, they look through the abstracts and pick the talks they’d like at the event.
It can seem intimidating for the inexperienced; it used to scare the life out of me when I first started submitting to CFPs. Luckily, there are a few robust strategies we can use to stack the selection process in your favour.
What on Earth Am I Going to Speak About?
Before we discuss how to tackle our first CFP, perhaps we should think about what we would talk about. It’s easy to fall into the trap of thinking you have nothing exciting to say or aren’t knowledgeable enough to speak on a technical topic. Let me let you in on a secret; some of the best talks I’ve seen have been personal stories about how people solved problems, mistakes and all.
Think of the last big technical challenge you solved. It doesn’t need to be work-related; it could be a side project or an open source project. I’m willing to bet you didn’t solve it the first time. How you eventually got to the correct solution (for you) is an interesting story for many people. People love to hear how we failed just as much as how we succeeded, and the most intriguing stories I’ve listened to have been stories about the progression through the failed solutions until the problem is finally solved.
Have you used an exciting new tool or development concept recently? These can be ideal ideas to base a talk around. While you’ll see a lot of experts giving deep-dive style talks on subjects they are very knowledgeable about, there’s also room on a schedule for a gentle introduction to a tool or process a portion of the audience may have never used or even heard of.
During my developer career, I’ve learned about some handy tools and how they fit into my work, from gentle introductions to the topic. Things like Redis, Graphite, and Gherkin have all been introduced to me through very light conference talks, and I’ve adopted them all into commercial projects at some point!
Abstracts
There’s an essential point to make which also answers a commonly asked question—”Do I need to have written the talk before I write the abstract?”
No! At no point have I ever written even the outline of a talk before writing the abstract. With that said, I’ve always got an excellent idea of what the talk will contain before I write the abstract, and I know other speakers who will have an outline or mindmap before they even consider the abstract.
I curate ideas in my head for a time before I feel they are formed enough to make an abstract. Some talks will make it to abstract form a few weeks after thinking of them; others will take years before they’re developed enough to submit. Your mileage may vary (as they say).
Occasionally, I submit talks before I’ve learned all the information needed. This may seem crazy, but there are several technologies or tools that I want to know more information about; my to-do list is full of them. There’s nothing like having a talk about the OWASP Top 10 accepted to force you to do the research and learn all about that thing you never got around to learning!
I wouldn’t recommend submitting a “Deep Dive Into…” type talk without knowing the subject matter in depth, but I certainly think you can learn enough about a topic to submit “An Introduction To…” with only enough knowledge to understand the basics.
Talk Length
Every conference is different, but there are some slot types which persist across many of the events I’ve attended. Let’s take a look at the most common ones.
Lightning Talks
Typically between 10 and 20 minutes, lightning talks are a fantastic way to dip your toes into speaking at events because they are usually significantly shorter than the full scheduled slot. Lightning talks can cover a single technology or thought quickly and lightly, or can be a brief look at a tool or concept. Either way, having only 20 minutes of content to write can be less intimidating than writing a full talk—particularly first time out.
I’ve seen some delightful lightning talks that have amused, entertained, and informed; some of my favourites have not even been on technical subjects. Organisers are more likely to “waste” a slot on their schedule on a non-technical matter when it’s a lightning talk just because there are more of those spaces to go around.
Regular Slots
These are the bread and butter of most events and are usually between 45 minutes and an hour. This is an excellent length talk as it allows you to deliver content with an interesting narrative (more on this later), and work to a fulfilling conclusion. At most events I’ve attended, the talk slot length also includes questions, so it’s worth planning on finishing 5 or 10 minutes earlier depending on the number of questions you anticipate and are happy to answer.
Tutorials
Longer teaching slots are not really talks. Usually three, six, or even eight or more hours are for training rather than speaking engagements, and won’t be covered any further in this book.
Keynotes
Keynotes are sometimes picked from submissions but may be negotiated directly. These talks are typically the bookends of the conference. Usually, they are the only talk during that timeframe (in multi-track conferences) and are generally by people of note in (or out of) the community and contain a powerful message. Keynote slots are usually given to experienced speakers and aren’t something you should worry about at the start of your speaking career.
Writing Abstracts
I use a tried and tested formula when I’m writing my abstract. It’s crucial that your abstract conveys a certain amount of information for the eventual audience, but I always write my summary with the organisers in mind. I’m still trying to think of how I can convince the organisers to pick my talk when writing my talk abstracts. If the event organisers do not feel invested, the talk will never be delivered.
We’ll cover writing a great abstract soon, but first, we need to mention something equally as important.
Talk Titles
Your talk’s title is arguably the most essential piece of the puzzle. A good title can help an average abstract, but a great title can be intriguing enough to get the talk selected and entice more people to attend. It’s also worth mentioning that at most events the schedule the attendees pick talks from only show the title. People often make snap judgements based on the title alone and not the abstract. In my opinion, the title should clearly convey the topic of the talk with bonus points for clever wordplay, but I’ve seen many people have success with weird and wonderful titles that may have nothing to do with the topic.
My advice when beginning your speaking career would be to make the title clear and evident without trying to be too clever. You’ll have room to grow in this department as you get more experience. I’ve never seen a talk rejected because the title was too obvious.
Good Titles
- Climbing the Abstract Syntax Tree
Explains we’ll be looking at something called the abstract syntax tree with a clever little pun.
- Learning Machine Learning
Tells you exactly what you’re going to learn in the session without wasting any words.
- Step Into Debugging
We’re going to learn about debugging and “Step Into” infers it will be an introduction, as well as being a term used in the debugging process.
- DDD for Beginners
Almost the perfect title for me, we’re covering DDD, and it’s for people with no prior experience. But, would a beginner audience know DDD means domain-driven design?
Not-So-Good Titles
- Lean, Extreme, and Bulletproof
What is this talk even about? It doesn’t tell us anything about what will be covered. It may be smart when considering the abstract, but don’t forget many people will never read your abstract.
- The UI is application
This makes no sense. It makes me wonder if your abstract will make sense. Remember, organisers will be reading hundreds of abstracts and sometimes will not even read your synopsis if your title is not even grammatically correct.
- Don’t fix bugs, prevent them and harden your code!
While this may seem like great advice, as a title, it doesn’t work for me. If I were going to attend this talk, I’d want to know what skills or tools were going to be covered to ensure I wasn’t learning about something I already use.
- STEADY REVENUE: A FEW TIPS ON HOW TO EARN MORE WHILE DEVELOPING FEWER WEBSITES
It’s too long, and it’s all in capitals. While you may be tempted to scream your title from the rooftops because you’re proud of your idea, it doesn’t help. Try and keep your titles short and catchy. The double space between “fewer” and “websites” also doesn’t help either.
The Abstract
“Write for the organisers” is such good advice that it’s worth repeating. In my mind, the abstract is something I’m using to try and get the organisers to pick my talk, while the title is something I’m using to try and get the attendees to attend the sessio. With that said, there are three key pieces of information I like to include to try and get my talk selected.
I’ve stolen and adapted these ideas from the tweets and ideas of @grmpyprogrammer so my thanks go out to Chris Hartjes.
The Problem
You’ll likely be trying to teach the attendees about something, but before I want to learn about something, I need to know what problem it will solve for me. What’s hard in a developer’s life that you can make easier for them?
The Solution
Now that we’ve outlined what’s hard, here we can explain how we can make it easier. Talk about the technologies you’ll introduce or the skills you’ll hone. Make it clear that we’ll solve the problem outlined above using the tools or skills we’re informing about here.
While the problem and the solution should be provided, sometimes it’s possible to combine them into one paragraph or even one sentence.
The Take-Away
I like to finish by making it clear what anyone attending my talk will leave the session with. Often I’ll use phrases like “You’ll learn about $x,” or, “You’ll leave having a solid grounding of $y.” I like to set expectations in this section, so anyone who attends (who’s read the abstract) will have no illusions about who the talk is targetted towards, and what they’ll take away.
Examples
Here are some examples of my abstracts that follow this formula. I’m in no way saying these are great abstracts. These examples are from my own abstracts and show the formula at work, ensuring my submissions are at least getting read and understood by the people selecting the talks.
Getting started with Zend Framework 2 is relatively easy. But once you have a basic CRUD application up and running where do you go from there? Knowing how you should build your application with maintainability and scalability in mind can be very daunting. But there are some hard and fast rules you can use to help to factor your application into something functional, maintainable, and performant.
In this tutorial, we will take a pre-built ZF2 application straight from GitHub, and apply some simple(ish) rules to make a basic ZF2 application run in a more modern way. Say goodbye to
getServiceLocatorin your controllers, and say hello to the full power of dependency injection, event listeners, and framework plugins.
This is a good example of outlining the problem and solution, then finishing with the takeaways.
Dependency injection is everywhere, and dependency injection containers and programmatic service locators are very popular right now. Zend Framework’s Service Manager is one of the cornerstones of the framework, but using the right feature at the right time can be difficult. Join us as we cover exactly how and when you can use the Service Manager, from the simplest “invokables,” through “factories” and “abstract factories,” all the way to “initializers”
and “delegators.”
Here we combine the solution with the takeaways, but both points are covered.
At some point, in any successful web application’s life, you’re going to need to remove things from the request and response cycle to improve performance. From sending out emails to publishing information on social media channels, we’re finding ourselves trying to shoehorn more and more processes into the traditional HTTP request/response.
This talk will help explain how you can use ZF\Console based command line PHP to control workers that take and process jobs from a queue, helping to make sure each and every one of your responses is lightning fast. Using popular technologies like Redis and Beanstalkd to manage and monitor worker processes is a skill every developer will benefit from sooner rather than later.
Again we outline the problem, then give the solution and takeaways in the second paragraph.
While I find this system works very well for me, and I’d encourage you to use this in your early submissions, it’s likely that with experience you’ll find your style. As my own presentations evolve I sometimes see myself not outlining the solution because I want the big reveal to be in the talk itself, but this format has worked well for me and it’s something I end up going back to—particularly when I want to talk about a technology or tool.
Other Information
As well as the title and abstract, organisers usually ask for more information to judge your submission. Often organisers will provide a separate field to allow you to pitch your talk (and yourself) to them without the public ever seeing the information. I suggest that you use this field to your advantage to give organisers confidence that you’ll deliver a fantastic talk. Have you presented this talk before at a conference or user group (we’ll talk more about these later)? Make sure to let them know. You can also give some information about why you should be selected, and this is particularly useful if you’re a new speaker. Being honest can help, saying you’re new but you understand what’s involved and you’re confident you can deliver an exciting talk will help organisers to take a chance on you for your first few presentations.
If you’re submitting on a given technology, it can help to explain why you’re qualified to speak on that topic. Do you contribute to an open source project that you’re submitting on? Make sure to mention it as these qualifiers can help tip the balance in your favour if there are many submissions on a similar topic. Don’t be afraid to sing your own praises. Not many people are comfortable with self-promotion, but an honest reflection of your incredible talents can help you get selected.
Don’t be tempted to leave the “other information” box empty, particularly if you’ve never spoken before. I always put something in the box, either links to feedback from previous talks I’ve given or if it’s a new talk why I think it’s incredible. You’re given the opportunity to pitch yourself to the organisers — use it!
An Aside on Expenses
Often organisers will ask you if you need help with travel and accommodation costs if your company is interested in sponsoring the event, where you’re travelling from and a myriad of other logistical information. If you need help paying for your travel and accommodation, then don’t be tempted to lie about the fact. You’re doing the organisers a massive favour by agreeing to speak at their event for free (or even at your own cost) so don’t undersell yourself by agreeing to pay your own way. Of course, I can only give my own opinions here the final decision is yours, but think about the time you will spend submitting to the event, writing the talk and slides, practising the presentation and then travelling to the conference and delivering your speech. This can add up to tens and sometimes hundreds of hours of time you won’t be compensated for, so the least the conference can do is to pay for your expenses to present for them.
Most conferences are open and upfront about their policy to reimburse speakers expenses, and I would personally advise to only submit to those with a transparent and fair expenses policy. Some events will try and claim that speaking for them will give you exposure and boost your career, but don’t forget they are charging people to be at an event that couldn’t happen without people like you speaking there.
Personally, as an experienced speaker who is lucky enough to count presenting as part of my job, I do sometimes break my own rules to speak at events while paying for hotel and/or travel myself. But these times are rare, and usually, when the conference has particular morals I agree with such as being free or very low price to encourage people to attend, or have a certain topic I feel is important enough to donate my time and money to present on (such as my talks on mental health). My rules of thumb is I expect a ticket to the event and my travel and hotel covered before I will submit to an event.
It can be tempting to attempt to pay your way to your early acceptances, but I would recommend against it.