How to Write Good Proposals: Part I
How to Write Good Proposals: Part I
In this three part series, frequent conference speaker Ted Neward gives advice on getting your speaking proposals approved.
Join the DZone community and get the full member experience.Join For Free
Buckled up and all set to kick-start your Agile transformation journey? 10 Road Signs to watch out for in your Agile journey. Brought to you in partnership with Jile.
For many years, I’ve quietly mentored a few speakers in the industry. Nothing big, nothing formal, just periodically I’d find somebody that wanted to get in front of audiences and speak, and either they’d ask me some questions or I’d get the feeling that they were open to some suggestions, and things would sort of go from there. Now, as I start to wind down my speaking career (some), I thought I’d post some ideas and suggestions I’ve had over the years.
Mind you, none of these are ever guaranteed to make you a hot topic, or the next TED presenter. That, as it turns out, is the result of these tips, hard work, and a lot of experience (usually in the form of thousands of presentations). And, of course, every presenter will have their own stories, their own tools, and their own particular approach to accomplishing things. As they say on the Internet, Your Mileage May Vary.
Without further ado….
Most speaking experiences start with first getting accepted to speak at a conference, user group or some other gathering, and that isn’t going to happen until a proposal has been written and submitted to the body in question.
(Yes, sometimes the conference will specifically ask someone to do a presentation for them—it’s happened to me more than once. However, that’s only happened recently, and that’s only because I have an existing body of work that they seek to draw from. Again, certainly exceptions are possible, but for the most part, you’re going to have to work your way up to get to that “invited to speak” status.)
Generally, a conference puts out a “call for papers” or a “call for proposals”. Unless the conference is an academic conference, however, the “call for papers” isn’t really a call for papers; that’s a term that’s a holdover from the academic world, where one would write a paper, submit the paper to the conference, and offer up a short overview of the paper’s contents to the audience and take questions on it as part of the presentation. That’s not really how the modern software development conference or user group works anymore. (Whether that’s a good thing or a bad thing is, of course, open for debate.)
Instead, the conference is expecting would-be speakers to submit short abstracts—usually somewhere in the 100 - 500 words range in length—describing the presentation that is being offered. Note that different conferences will have different requirements around the abstract, and that takes us to our first tip.
Let’s take as a practical example the most recent (now closed) call for proposals for Seattle Code Camp, which utilized a centralized proposal tool called Papercall.io. (Again, the “paper” here is the misnomer term I mentioned earlier; it really should be “talkproposalcall.io”, but that clearly doesn’t roll off the tonue nearly as easily. It sort of trips and stumbles and bleah twists up the tongue.)
Read the Directions
It is absolutely amazing to me how many times a would-be speaker submits a talk abstract that violates one or more of the conference’s stated requirements. It would seem to be pretty straightforward, and yet, sometimes….
First of all, note the opening and (most importantly) the closing date. While it’s often not impossible to submit talks after the closing date (depending on the conference, the number of submissions they have or haven’t received, and/or what your excuse is for why the submissions are late), it’s never guaranteed. Besides, do you really want to be “That Guy” or “That Girl” that is always trying to turn in your homework late?
(Yes, conference organizers do talk to one another, and yes, they do share stories about speakers.)
Next, examine the call for any hints or ideas about what kinds of topics are (and are not!) accepted. Trying to put talks on NodeJS in at a Ruby conference isn’t always a guaranteed rejection, but unless your NodeJS talk somehow maps to the areas of interest that conference (and its attendees) have, it’s not likely to make it past the filter.
For Seattle Code Camp, the body of the CFP reads as follows:
We are interested in topics that touch on all aspects of software, database, dev-ops, web and mobile development. Hardware hacking topics are popular with our attendees so talks about IOT, robotics, 3d printers and Arduino are sure to be a big hit. We’ve also seen plenty of soft skills talks at past camps.
OK, without going any deeper than this, we can see already a set of topics:
- Hardware hacking (IOT, robotics, 3-d printers, Arduino)
- Soft skills
This is a pretty wide range of topics, and more importantly, note how they haven’t set up any sort of restriction around the kinds of tools, languages, or vendors. This is a very broad range of possible materials to choose from; this is also a community Code Camp, which tend to reflect the community’s involvement in various tools around town. Probably going to be fair bit of .NET and Java, a little Ruby, a little NodeJS, and some Android/iOS.
By comparison, let’s look at another conference call, this time for RubyConfIndia 2017. (Why this one? I wanted to pick something that was some distance away from a Seattle Code Camp, and this one happened to be in the list of OpenCFPs when I wrote this.) Here, their presentation requirements are a range of topics, both occupational (i.e., about Ruby, Rails, code-heavy, etc.) and organizational (i.e., about team dynamics, communication, etc.), and all applicable hybrids. We want talks aimed at developers coming from a wide range of experience levels, from beginner-friendly how-tos to cautionary tales to deep dives for experienced devs. We want talks about all the different parts of the Ruby/Rails ecosystem, including related technologies (data stores, front-end frameworks) and related teams (QA, product management, clients).
A similar set of topics, but under the larger umbrella of Ruby and Rails. Note the “We want talks aimed at developers”, not just because they are looking to target all levels (which implies that they’re looking for some entry-level developer talks), but that talks aimed at dev managers and/or CEOs/CTOs are probably not going to be welcome here.
But notice how even though these are two wildly different events, there’s significant overlap? It turns out that most events are all looking for much the same kinds of things, only “slanted” to accomodate the community that event seeks to attract. One could almost replace “Ruby” with “Java” and “Rails” with “JavaEE” (or “Spring” or “Play” or …), and have a paragraph easily ready for any Java-based conference environment.
Most conferences want the same stuff.
Stay tuned for Part II, where we'll go into detail about how to write a good proposal.
Published at DZone with permission of Ted Neward , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.