My Experience Submitting Proposals to Big Data Conferences
At the beginning of the year, I decided I wanted to speak at technical conferences and meetups. This decision was based on how much more I learn when I am tasked with explaining things to other people. It’s the same reason I like to blog and the same reason I liked to tutor when I was in college. I had the opportunity to speak at conferences (mostly local) before, but I wanted to focus on some of the big data conferences like O'Reilly and Spark Summit. After looking over the names accepted to these conferences, I felt quite overwhelmed at my own prospects of getting accepted. This post is about my journey to get proposals accepted at these technical conferences.
First Approach
Most conferences have some general advice on topics that are likely to get accepted. This is usually a small note on the page where you submit your talk. Often, this advice is general and vague and won’t provide much help. This was my experience at the first 8 conferences I submitted proposals to. I got a list of conferences from KD Nuggets website and chose conferences I had heard of before or ones that matched my skill set. For each conference I curated a new proposal, trying to align with their past speakers. I also made it a point to talk about workflows I successfully ran on production.
For the most part, I thought this was a good approach. I knew that the architectures I was wanted to talk about were not cutting edge or sexy. They employed technology that companies have been using for years, and are usually the first pass for distributed data architecture. Not to say there weren’t cool wrinkles, but the wrinkles were not enough to catch anyone's attention. My proposals also focused too much on the importance of the architectural choices, and the tradeoffs of doing so rather than talking about the superiority of it compared to the most common or emerging architectures.
Once all the proposals were out, rejections trickled in. I was 0/8 on being accepted to conferences and it really sucked. I spent a non-trivial amount of time putting proposals together and it’s never fun taking that many L’s in a row. I decided to take a closer look at my approach and do some things quite a bit different.
Second Approach
I started at a drawing board and read through proposals that were accepted for the conferences I was rejected at. I noticed immediately that there were much more “off the reservation” type of proposals. Many of the proposals focused on tricks and tips, others about weird hacks and some others about optimization and performance. I was in the right mind of thinking, but focusing on the wrong parts of my technology in my proposals. At this point, I started a fresh set of proposals. I focused on adjustments I made to traditional systems, how I helped solve some of the operational challenges at my company with technology and detailed drill ins on specific parts of distributed data architectures. This approach was much more successful. To date, I am 5/5 with this approach and had to turn down one conference because of a conflict.
My Tips
- Review old talks. Go back as many years as possible and read through proposals. Get a feel for how to write them and practice writing them.
- Keep the technology to a minimum. Talks are typically 30 minutes to 45 minutes and there is not ample time to describe a complex system. The fewer moving parts the better.
- Have a friend review your proposal. Do this mostly to make sure that it flows logically and isn't just technical regurgitation.
- Reuse old submissions. It takes a long time to come up with a good proposal and even longer to put together a good presentation. If the talk is applicable to multiple venues, go ahead and submit it again.