Submitting Conference Proposals
Posted August 30, 2013 by Jeff Casimir
Conferences are a great way to grow your network, learn more about your craft, and have a great time along the way. In the Ruby world, we have dozens of great conferences you might consider, with some of my favorites being RubyConf, GORUCO, GoGaRuCo, and Rocky Mountain Ruby.
Those conferences are only worth the time and effort if there are great talks. Over the years I’ve written dozens of talk proposals and they get accepted about two-thirds of the time. More and more conferences are going to a “blind selection,” which is advantageous if the proposal reviewers weren’t going to recognize your name anyway.
Before you can submit a proposal you’ll have to find a CFP. Here are a few options:
- @CallbackWomen tweets 10-20 CFPs from across the industry per week
- Lanyrd gives you a great idea about upcoming Ruby conferences
- RubyThere has been a great resource in the past, though it doesn’t appear to be maintained at the moment.
Writing a Proposal
Instead, there’s more weight on the proposal itself. Here’s my outline for a good proposal:
- Opening that explains the problem
- Concrete outline that demonstrates you actually have something to say
- Conclusion with what the attendees will take away from the session
As an example, here’s a proposal I just submitted to RubyConf 2013:
Writing good Ruby is all about creating abstractions. Meanwhile, there are amazing abstractions right beneath your fingertips: electrical signals abstracted into binary numbers into logic gates into flip-flops, registers, ALUs, on up. Let's bring the world of low-level hardware into object-oriented Ruby and explore: * Building foundational logic gates in Ruby to mimic the hardware * Using those gates to construct flip-flops and multiplexers * Using those components to create memory and adders * Then building fundamental components like ALUs and CPUs * Implementing fundamental instructions (like the 8088 set) * Using those instructions to implement algorithms * Visualizing the whole execution path while instructions are clocked through the system High-level languages offer us the privilege of ignoring the hardware. But developing a deeper understanding of how the machine is constructed can influence how we design and abstract complex systems.
Sound easy? Obvious? A few other things you should keep in mind:
Keep It Short
Many conferences are going to review over a hundred submissions, and some as many as five hundred. The organizers are already stressed trying to nail down the venue, sell tickets, all while trying to do their jobs and live their lives.
You’re not doing yourself any favors by writing a dissertation. Your proposal should be readable in under a minute.
Be Humble, But Not Too Humble
I described an author once by saying “if he had three hands, they’d all be patting himself on the back.” The voice of your proposal betrays your attitude, and no one wants to deal with a prima donna.
But don’t undercut yourself, either. Look to remove words that soften your message: “probably”, “often”, “sometimes”. You’re going to stand on stage and deliver a message – you must be confident that it’s worth hearing.
If you have some related credential make sure you mention it in the proposal or (preferrably) in a note to the organizers. You’re pitching a talk about a Gem you wrote? Or you’re on the core team? You’ve deployed your strategy in an app that’s serving bazillions of requests? Mention it.
Pay Attention to Your Audience
This is a lesson I learned the hard way.
In the Ruby community, there’s about a 96% overlap (warning: completely made up statistic) between people who work with Ruby and people who work with Rails. But for conferences there can be more of a distinction.
Pay attention to the name of a conference. Is it called a RubyConf? If so, don’t propose a talk about Rails. The organizers were intentional about choosing the name, and proposals that are doing interesting things with Ruby away from Rails are going to stand out.
It’s OK to Not Know
One of the most frequent things I hear from people that don’t submit conference talks is “I’m not expert enough in anything.” Guess what? Me either.
Giving a conference talk isn’t about being an expert. Some of the best talks I’ve seen are explorations – “I started with this question, and here’s how I found the answer.”
I often use conference talks to push me to learn new things. Two years ago, I’d never used Internationalization in an actual app. I wrote up a conference proposal with the pitch that I’d explain how to get going with i18n and some pitfalls to watch out for.
Then, only once the talk was accepted, I started working with it. I admit this technique is not for everyone, but I work best under pressure. Most of the time you’ll have two or three months between when a talk is accepted and when the conference happens, which should be plenty of time to learn and practice whatever you pitched.
That proposal up above? I’ve thought about it, but I haven’t written a single line of code. I don’t know how logic gates are used to create flip-flops. I can’t remember 8088 assembly. But if the talk gets accepted, I look forward to learning it over the next few months.
Propose in Plurality
If you really want to get into conferences, spend some time writing up three different proposals. Then submit those three to every single conference that opens an RFP. If you’re lucky, a single talk will get accepted to a few conferences and you’ll have the opportunity to refine the material each time.
Speaking at a conference is stressful, fun, a great way to meet people, supporting your community, and valuable to your career. The only way you’ll get good is to do it – so go submit a proposal. The RFP for RubyConf ends tomorrow.
In the future I’ll follow-up with posts about how, once accepted, you should plan and deliver a great presentation.comments powered by Disqus