As a developer, doing talks at tech conferences is great for lots of reasons: boosting your career, promoting your company, and getting more excitement into other parts of your life. As an introvert, though, the best perk as far as I’m concerned is the stream of people who come up and talk to me. No more awkward unstructured break time!
I’ve done almost 30 conference talks since 2009, but I still remember how hard it was to figure out at first. The biggest mystery in the whole process, for me, was responding to a Call For Proposals (CFP).
When a conference has an open CFP, even if you’ve thought of some topics you want to talk about, it’s not obvious how you translate that into a title, an abstract, and a description. I’ll talk about those three here. Sadly, I still have no idea how to write a speaker bio, so you’re still on your own for that.
The easy stuff
Noel Rappin has done an excellent job covering the basics of conference proposals, and I highly recommend reading those articles if you haven’t already. The short version is: clearly identify your topic, be respectful of everyone, be interesting, and don’t pitch your company.
Here’s the downer: you can do all those things and still be rejected by conferences. In reading through hundreds of conference proposals in the past year, I’ve come up with some techniques you can use to move your proposal to the top of the pile.
The problem with sales
Proposals are mysterious, because they’re a different type of writing than developers are used to. Proposals are actually sales material.
No wait, come back! Not that kind of sales. No boat shoes, blazers, or rounds of golf involved. But when you’re writing a talk proposal, you’re trying to convince people to spend 30 minutes listening to you. You’re convincing them to part with their time.
When you’re writing a sales brochure, you’re convincing them to part with their money. The topics are different (thankfully!), but the way you think about the writing is the same. You have to orient your whole writing process around what someone else will think when they read it, and crucially, what they will do afterwards.
That can be hard. Most developers don’t have a lot of experience with sales, but it’s easier than you might think! Here’s an exercise that gets me in the right mode when I’m writing a proposal.
Step 1. Imagine who will be at the conference
Concretely. Like, actually picture them. Imagine their faces. Think about them walking around. Where are they from? What are they talking about?
As an example, the Ruby community (where I’m from) is experiencing a big influx of newcomers, thanks to programming bootcamps and more widespread adoption of Rails in general. So when I’m writing for a Ruby conference, I imagine developers of different experience levels. Rubyists from the days of _why, engineers from other languages making the leap, and new programmers on their first development job.
I actually imagine them all sitting at the same lunch table, introducing themselves, and talking about their monorail applications, their javascript frameworks, and their infrastructure.
Step 2. Imagine the decision to see your talk
For the purposes of this thought experiment, your talk is on the schedule, but the presenter is someone else. You’ve decided to go, and you really want your lunch friends to come with you. How would you convince them to go? Why should they be interested?
Step 3. Capture that excitement in your proposal
Let’s make this concrete by applying this methodology to a conference proposal that was written by an actual person who is not me. Tim Chevalier graciously volunteered to go along with me on this experiment. Here’s his original talk proposal:
Writing Web Services in Haskell
Abstract
I’ll show how to write concise, elegant code in Haskell through the example of a simple Web service. No previous experience with Haskell is required.
Description
The Haskell programming language encourages clear, concise programming through its excellent facilities for abstraction, including higher-order functions, pattern-matching, and laziness. In recent years, the Haskell library ecosystem has blossomed. I’ll introduce the language by example, by developing a simple Web service (an anagram server) and explaining functional programming concepts along the way. I’ll use the Happstack server for this example. I’ll show the unique ways in which Haskell makes it easier to write web services, exploring the features of the language that make this application possible.
I will assume that you have programmed in at least one language, but will not assume any experience with functional programming. I will introduce all the concepts you need to know through code examples. I expect to cover recursion, string processing using higher-order list functions, pattern-matching on algebraic data types, writing effectful code, and implementing a simple HTTP server with Happstack. If time permits, I’ll present testing with QuickCheck and creating GUIs with Threepenny.
I will set up a tutorial using FP Complete’s online IDE for Haskell so that participants can write code during the session without having to install a compiler. To make the best use of the time available, I’ll provide participants with a partly-implemented server and devote part of the session to pair programming exercises in which participants will turn it into a working system.
This is already a good proposal. It’s clear, it’s respectful, it’s interesting, and it’s not a pitch. Let’s run it through the exercise and see what happens.
Step 1. Imagine who will be at the conference
Tim submitted this proposal to Open Source Bridge, a large community-run multi-track conference that covers all topics related to open source software.
At OSBridge, I imagine meeting folks from many different technical communities — Ruby, Java, Python, Perl, JavaScript, even .NET. I imagine developers, community managers, project managers, QA folks, lawyers, release managers, system administrators, operations people…a huge mix of attendees with a wide range of backgrounds in different parts of technology. I hear people talking about contributors, security patches, and community. I see a lot of thinkgeek t-shirts and I hear some Perl 6 jokes.
Step 2. Imagine the decision to see your talk
“So what are you doing this afternoon?”
“I’m super pumped for this Haskell talk. Haskell used to be so academic, but apparently you can actually build things with it now. It’s functional, which means it’ll make me smarter. And (eye roll) I keep reading that learning new languages will make me better at what I do now. So FINE, I’ll go eat my vegetables. Plus it’s going to be awesome because by the end of the talk I will have written a web service, an actual thing, in Haskell! I can totally put that on my resume, right?”
Step 3. Capture that excitement in your proposal
Build Actual Stuff in Haskell
Abstract
Haskell may have started its life as an academic exercise, but these days, a blossoming library ecosystem makes Haskell development, dare I say…practical? And it is seriously cool, with nifty features like higher-order functions, pattern-matching, and laziness. Who doesn’t love laziness?
Even if you’ve never seen Haskell before, come learn how to get going with this concise, elegant language. We’ll see what all those features actually mean, we’ll build a real web service, and you’ll gain a whole new way to think about programming.
Description
This is a code-along session, using FP Complete’s online IDE with Haskell, so bring your laptop! We’ll develop a simple Web service that serves anagrams on top of Happstack, and learn functional programming concepts along the way. You’ll see the unique ways Haskell makes it easier to write web services, and explore the features of the language that make it all possible.
You’ll get the most out of this session if you have programmed before, but your experience doesn’t have to be in a functional language. You’ll get all the fancy concepts you need through code examples. Expect material on recursion, string processing using higher-order list functions, pattern-matching on algebraic data types, writing effectful code, and implementing a simple HTTP server with Happstack. And don’t worry if that last sentence didn’t make sense. It will.
Breaking down the rewrite
Okay, that was a little bit like how to draw an owl. Let’s see what happened.
In the title and abstract of his original proposal, Tim very clearly laid out what he will do in the session, which is a great start. However, there’s no information about why an attendee should be interested in doing it.
“What?” and “Why?” are very different questions. As the speaker, you answered the “Why?” for yourself a long time ago. You think the topic is obviously worth thinking, writing, and speaking about, so “Why?” isn’t your motivation anymore. Instead, you’ve been answering the “What?” question a lot. But your audience hasn’t caught up.
If you relentlessly focus on answering “Why?”, your proposal will get more interest, more attendees, and better reviews. This is what makes conference proposal writing, and sales writing by extension, different from other forms of communication.
Fortunately, you generated the “Why?” answers in the thought experiment we did earlier, when you imagined the decision to see your talk. All you need to do now is assemble those answers into the abstract.
Some assembly required
Tim already has some of those answers in his original description, so in the rewrite, I moved them up to the abstract and combined them with ideas from the exercise.
Here are two “Why?” sentences from the original description:
The Haskell programming language encourages clear, concise programming through its excellent facilities for abstraction, including higher-order functions, pattern-matching, and laziness. In recent years, the Haskell library ecosystem has blossomed.
Here’s the rewritten abstract, including other ideas from the exercise.
Haskell may have started its life as an academic exercise, but these days, a blossoming library ecosystem makes Haskell development, dare I say… practical? And it is seriously cool, with nifty features like higher-order functions, pattern-matching, and laziness. Who doesn’t love laziness?
Even if you’ve never seen Haskell before, come learn how to get going with this concise, elegant language. We’ll see what all those features actually mean, we’ll build a real web service, and you’ll gain a whole new way to think about programming.
Protip: Tell a story
The best proposals have some kind of story arc, in addition to answering why an audience is interested in attending. An abstract is a very small space, but that second paragraph in the rewritten version tells a reasonable story.
Here’s the story: you show up, I help you get started, you learn some cool stuff, you build something, and you leave smarter than you came in. Story arcs are a powerful writing device, because the attendee can imagine themselves playing their part in that story. That narrative compels them to show up and listen.
Protip: Don’t bury the lead
Don’t hide the fundamental “Why?” question inside the description of the talk. Put it in the title and abstract, where the most people will see it.
Here’s why: attendees decide on talks in the moment, and usually all they’ve got to work with are the titles on the signs outside the rooms. If you’re lucky, they’ll read the abstract in the brochure. If you’re really lucky, they’ll take a moment to ponder their goals and needs, and read the description. Make it easy for them.
Reviewers try to be more disciplined than attendees, but scale is the biggest problem I faced there. With just a few weeks to rate hundreds of proposals, if the title and abstract didn’t grab my attention, I’d move on to the next talk.
Seal the deal in the description
The title and abstract sell your talk, so the description is your chance to tell them some new or supplemental information. In his original description, Tim did just that, and the content is pretty good. However, the writing is oriented around Tim, the speaker. Using the first person (“I” sentences), he talks about what he will be doing, and what he will be showing.
Here’s something even more powerful: reorient towards the attendee. Write “you” sentences instead. When you’re writing a proposal, of course, you’re thinking about what you personally will be doing, so it’s natural to write in first person. Do that for the first draft. Later, rewrite those sentences to directly address the attendee’s goals.
For example, this original sentence is oriented around the speaker.
I will assume that you have programmed in at least one language, but will not assume any experience with functional programming.
Here’s the same sentence, oriented around the attendee.
You’ll get the most out of this session if you have programmed before, but your experience doesn’t have to be in a functional language.
This is a subtle distinction, but an important one. People don’t go to talks for the content. People go to talks because they think they’ll become more badass. So help them out with that! Make it easy for them to imagine their newfound superpowers, and they’ll match your level of excitement.
But wait! What about the reviewers?
Now you have a title, abstract, and description that gets attendees pumped to see your talk. But to get it accepted at the conference, you have to convince the reviewers — a totally different group of people — to rate it highly.
Uh oh. Should you have been focusing on them, specifically, this whole time?
Well, in my experience, not really. The goals of reviewers and attendees are pretty well aligned. I read and rated all 429 proposals we got for RailsConf this year, and I’ve been on program committees for other conferences in the past. Proposals always broadly fall into three categories:
- Wow, I want to see that talk! (~5% of our RailsConf submissions this year)
- Other people want to see that talk. (~85%)
- Nobody wants to see that talk! (~10%)
As a conference proposal writer, your goal is to be in the first group. Those talks almost always make it on to the program.
Caveat scriptor
Life doesn’t come with any guarantees, and that goes double for CFPs. During the final selection process, conference organizers have a lot of things to consider: reviewer scores, topic relevance, program balance, and speaker credentials, along with other conference-dependent factors. So even if you’re in group one, you will still sometimes be rejected. Much to my chagrin.
But ultimately, conference organizers pick talks to sell tickets. Selling tickets means building a program that makes people go, “Wow! I want to see all those talks!”
In other words, if your proposal sounds truly fantastic for the attendees, the reviewers will be right there with you. After that, it’s out of your hands.
Getting to “Wow!”
Tim’s proposal is already good, probably near the top of group two. A clear, respectful, interesting proposal might be accepted as-is. If your proposal meets the basics, yours might be, too.
However, my experience with RailsConf this year showed me that improvement is straightforward. The RailsConf review process (which I’ll detail in another post — it’s fascinating and effective) encourages conversation between reviewers and proposers via comments. So, I left comments on lots of talks that were less-detailed versions of this blog post.
In response, people edited their proposals, and some of them moved right out of group two and up to the top of group one. You can do that, too. Conference organizers, and attendees, will love you for it.
And you’ll never stand awkwardly at the edge of a group again.
<3
Many thanks to Tim Chevalier for volunteering his proposal, to RubyCentral for inviting me to help with the RailsConf program, and to Lillie Chilen for organizing the Double Union conference talk workshop where I solidified my thoughts on this topic.
