Structure your speaker proposal for success

Adam Boas

Adam Boas

 Guest Blogger: Adam Boas – Principal Engineer, Tiny Robot Army

Ultimately creating a great proposal is all about detail. Even the best proposal can fly under the radar if there isn’t enough information for the reviewers and stream chairs to get a sense of how awesome the presentation is likely to be. Having been an advisor for the conference for the past 3 years I have seen and reviewed many many proposals.

Every year the number of speaker proposals grows and the competition for speaker places grows with it. Last year we had close to 200 submissions and we expect to have at least that many this year. I have put together this blog post to try and explain the current system and help people get their speaker proposals noticed and accepted.

Over the years we have experimented with different ways of helping would-be presenters to get a paper up. Last year we started using an online and public system for speaker proposals and that continues this year. The aim of the online system is two fold. Firstly to make the selection process as transparent as possible. Secondly, and more importantly, we wanted to encourage presenters to be Agile. In this case that means allowing presenters to post as early as possible, allow feedback from all stakeholders (including the conference delegates) and let presenters iterate on their proposal to have the best chance possible of being accepted.

We have put up stream descriptions on the main conference site here to give presenters a good idea of the type of content each stream is looking for. But I’d like to take the opportunity to talk about the structure of a speaker proposal and what presenters can do to improve their chances of having a good talk be noticed and accepted.

I’ll start with the number one misunderstood component; The mechanics section. The mechanics section is intended for presenters to provide some insight into how their talk is going to run. What we are really looking for here is a break down of the presentation:

The first 15 mins will introduce XX, I will take questions on XX for 5 mins before moving into an in depth discussion on YY. This will lead into a series of slides detailing how ZZ impacts on project delivery outcomes. I will then finish with another 10 mins of Q & A

In general reviewers and delegates will assume that speakers use slides. You don’t really need to mention that in the mechanics unless you are planning to use a different presentation approach. I only mentioned the slides above to make the description read nicely, it was not core to the mechanics description.

Next I’d like to mention the Learning Outcomes section. For me this is the most important section in the proposal. A presentation without learnings for the attendees is unlikely to get up at any conference. Stories are awesome, but delegates generally attend to learn. Learning about what to do, learning about what not to do, learning about areas that need more research and for which there is currently no definitive answer are all equally great. Just telling a story about what happened to you might be really interesting but is unlikely to get up as a speaker proposal, regardless of public votes.

Spending a bit of time detailing what the learning outcomes of the presentation will be can often be really useful to the presenter in focussing the talk. It is also the key area that reviewers will focus on when trying to decide between two equally good proposals on a particular topic. I recommend spending some time working through your presentation learning outcomes, not only to increase the chances of being accepted but to improve the quality and focus of the presentation itself.

The summary is the section that most submitters focus on. Generally people do a really good job of writing a summary of their presentation. I would like to make one strong point here though. If a submitter cannot think of more than one or two lines to detail what their presentation is about, please don’t submit. As I mentioned above, the online submission system is intended to allow early submission and iteration, but it is not intended as a tool to help crowd source your presentation content. Please work through your idea and have a reasonable first cut before submitting it.

Hopefully the above few points have helped explain the motivation behind our online submission system and also help people to get their presentations accepted. Good luck, I look forward to reading all the proposals and hearing some of you talk at Agile Australia 13.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s