So here I am in the middle of a series of articles about doing a good technical talk when one of my Relevance co-workers asked the obvious question zero: How do I get my talk proposal accepted in the first place. Good question. Answer follows.

Help Us Accept You

I should start by saying that most of my experience with this sort of thing is from the other end: I help organize RubyNation, and a big part of that is picking the speakers every year. One surprising thing about the RubyNation organizers and, I suspect, the organizers of most other tech conferences is this: We want to accept every proposal that comes through the door. Think about it: Technical conferences are mainly volunteer affairs, put together by people who have a passion for the subject and for the community and who just want to give a little bit back. So here at the RubyNation world headquarters (generally an unused conference room in some nameless office park) we see every talk proposal as an offer of help, frequently from people we have never met. Yes, some talk proposals are better than others. Yes, some we take and some we turn down. But if we could hug everyone who ever sent in a proposal I suspect we would.

Having said that, we do take some talks and turn others down. How do you make sure that your talk is one of the ones that gets accepted?

The Bone Headed Stuff

One thing that you can do is to proof read your proposal. If you have been reading this blog for a while you know that I am not the king of spelling, the godfather of grammar nor the prince of punctuation. Neither are my RubyNation colleagues. Nevertheless we will tend to accept a proposal that is carefully written over one that is full of spelling and grammar mistakes. Look at it this way – a technical talk is all about communication and your proposal is the first bit of communication that we see from you.

You should also make sure that you take a look at the conference speaker guidelines. These will typically give you a hint as to what you should be talking about and how long your talk should be. Pay special attention to that how long thing. Every year we get a few proposals for talks that want to explain Life, The Universe and Everything – in 40 minutes.

Another thing is to make sure that you get your proposal in on time. Again there are no the rules must be followed people on the RubyNation organizing committee, but we do all have a sense of fairness and simple fairness says that proposals that come in on time will have a huge advantage over the late ones.

Tell Us What You Want to Say

So you’ve cranked up your spell checker, and you’ve read the speaker guidelines. Now what? Three things: Tell us what you want to say, a little about how you are going to say it and why you are the person to do the saying.

Of the three, what you want to say is the key. Keeping your eye firmly on the amount of time that you will have to talk, just tell us what you want to talk about. Not in general, like “CoffeeScript is the greatest thing” but specifically: “Why every web developer should use CoffeeScript” or even better “The three advantages of CoffeeScript”. I can’t speak for everyone, but I’m a sucker for the three quarters fact, one quarter passion approach, so better still is: “CoffeeScript’s three advantages and why I love it so.”

Surprisingly we get a fair number of talk proposals every year that wax poetic on the perspective speaker’s love of some topic — perhaps CoffeeScript — without ever mentioning what they want to say about it. Yes, tell us why the subject is important, but don’t leave out what you are going to say about it.

Tell Us How You Are Going to Say It

We are also interested in how you are going to do your talk. Is it a straight lecture or a tutorial? Are you going to code live? Are you going to try to be a little or a lot funny or deadly serious? Is your talk a call to arms or an amusing look at whatever? Will there be audience participation? There’s no right answer here, we just want to know that you have thought it out a bit.

Within reason, it helps if your proposal is written in the same spirit as your talk. Funny proposals for funny talks have a much better chance than a serious proposal for a funny talk or (Lord help us) a funny proposal for a deadly serious topic.

Tell Us About You

It also helps to talk about yourself: What is your background in the topic? Why do you care? What is your public speaking experience? One of the best things about running RubyNation is that we like to give new speakers a chance. All you have to do is convince us that you can do a decent job.

One way that you can convince us is to direct us to other things that you have done. If we haven’t heard of you our first step is to do some creative google’ing. You can help us — and yourself — by directing us to internet places where you show up. Got an open source project or ten? Have you done some previous speaking? Or a podcast? Written an article? Do you have a blog? Point those things out in your proposal. Just be careful not to oversell yourself. If you are one of the industry’s leading lights then a) you don’t need my advice and b) we will figure it out.

So there it is: A talk proposal should say what you want to talk about, how you are going to talk about it and why you are the guy or girl to do the talking. As I say, we want to have you come speak. Help us.

– Russ