Me, a Conference Speaker? Yes, You!

I have been in your shoes: it is very intimidating to get in front of strangers and speak about your passion: technical topics where others are stronger; opinions that are the antithesis of commonly-held beliefs; real-life solutions which you don’t believe are that unique. Or perhaps the most scary: people get bored and walk out on you.

Yet, how many conference sessions have you attended or watched webinars where you thought I knew this, I know more than the speaker, or even I totally disagree, and here’s why. The speakers you enjoy listening to — the David Belvins, Holly Cummings, Trisha Gee, Josh Long, Reza Rahman, Venkat Subramaniam of the world, and many others — started simply: likely pushed, goaded, and mentored into speaking. Practice and experience — and likely multiple failures — help novice speakers into rock stars.

Admittedly, I am not a regular conference speaker, having spoken only a handful of times at JavaOne, Devoxx UK, DubJug, plus some local JUGs. I do, however, review submissions for conferences and have thoughts on what may (or may not) make for a good session.

My Lucky Break

How did I become a submission reviewer: by speaking up.

JavaOne 2012 was not a year for stellar content, at least in the sessions I attended. While it’s not reasonable to expect every session to knock your socks off, in 2012, the sessions were almost uniformly bad: repeats from previous years, no earth-shattering news from Oracle, and advanced sessions that weren’t. A former co-worker on the flight home totally agreed; both of us were very disappointed and frustrated.

A purported advanced talk on Groovy is my personal bellwether of what a talk shouldn’t be: the presenter opened up his text editor and basically said So. what do you want to see? No agenda. No topics. No goals. No preparation. Just a blank editor (no IDE) in which to write code...and when he missed multiple syntax errors in his initial Hello World, I walked out.

After reflecting on my experiences, I reached out to Stephen Chin — then an Oracle Technology Evangelist for Java and heavily involved with JavaOne — to offer (hopefully) constructive criticisms: identifying four particularly-bad sessions and identifying ways sessions could have been improved (salvaged) — Stephen’s response: inviting me to participate in the JavaOne 2013 review process.

I no longer review submissions for Oracle but currently review for Devoxx UK, which I thoroughly enjoy.

Identifying Potential Topics

With technology conferences, almost anything is a potential subject. Everyone’s backgrounds and experiences are different, and everyone has their story to share. The constantly-changing landscape leads to a plethora of ideas on ways to use and incorporate technology, and this diversity encourages us to want more: every day, you (hopefully) learn something new.

It’s possible that you’re not even aware of what you’ve achieved: diving deep into Kafka to improve your organization’s analytics; introducing Neo4J to represent relationship graphs better than in a relational database; designing a comprehensive infrastructure-as-code approach for cloud deployment; using observability tools to better understand production problems. What you offer is the knowledge that others take home to improve their work. Ideas that appeared unrealistic now seem possible. It’s more anonymous than talking with peers and friends but just as valuable.

You’d be wrong to believe that technical conferences only want in-depth technical sessions. Admittedly technology deep-dives get the buzz and excitement, but it’s not exclusive: UI/UX, imposter syndrome, careers in technology, and mental health are topics presented in recent years — different focus, but interesting and useful.

When I review, I look for talks with real-life experiences, sharing problems — both expected and unexpected — and seeing possible solutions. Elle Waters' Devoxx UK 2018 talk Accessibility for UX: Don’t Worry, It’s Much Worse Than You Think started with her story of proudly showing her father an application intended to assist the elderly in managing their medications which he — the target audience — found extremely hard to use. Fascinating talk with an engaging speaker, and it really opened up my eyes. Totally blown away; probably the top session I attended that year.

You might not have something as life-changing to share, but you do have something to share. A particular passion, technical or otherwise? A work success you’re particularly proud of? Your personal journey from music composition to software engineering? How about a one-line commit — based on months of research — that improved overall performance by 50% (true story IKYN)? Technology has an infinite number of facets and therefore an infinite number of stories to tell.

So, what story can you share with others?

Writing up Your First Submission

Besides the obvious (e.g., you won’t be asked to talk until you actually submit), the submission shows both structure and goals of whatever you want to talk about: it’s not enough to state, Let’s talk about the impact of microservices on data quality if you can’t explain why that’s important.

[And IMO it’s also not enough to say I’m a Java Rock Star; trust me. JavaOne had multiple submissions chosen strictly from past reputation which ultimately failed.]

To help understand what a typical submission looks like, I’ll use my Devoxx Morocco submission to explain the different sections. All Devoxx conferences use the same app (and a great app at that!); other conference will ask for similar but not necessarily identical information, but hopefully, this gives you the basic concept.

1. Title: Intriguing or interesting enough to attract the reviewer’s attention and get her/him to continue reading.
2. Tags: After Track (#4) helps to further categorize the submission, e.g., AOT, IOT, Cloud, Microservices, Java, Scaling, Garbage Collection, whatever.
3. Description: What attendees read to decide the sessions to attend, your main (only?) opportunity to grab their interest and, hopefully, get them to attend. Key point: what do attendees walk away with?
4. Track: Top-level grouping, Devoxx Morocco subdivides their sessions into Architecture, Security, Data and AI, Devops & Cloud, Development Practices, People and Culture, Programming Languages, and Ui & UX sessions.
5. Session Type: IMO, session types are more about the length than the actual type of talk, based on your available content or comfort level; new presenters often want a shorter slot.
6. Elevator Pitch: Your sales pitch to reviewers, a quick attention-grab to get them to spend time digging deeper into your submission (reviewing slides or watching videos takes time).
7. Notes: Notes are the most important tool in allowing reviewers to better understand a submission’s purpose, goals, topics, and organization that the submitter hopes to achieve.
8. Slides link: Slides, blog posts, GitHub repos, whatever provides backing information; you may create prototype slides for a new talk or use material from an internal work presentation to better show what you intend to talk about.
9. Video Link: Usually the most challenging for new(-ish) presenters. Devoxx UK asked me to record a trial presentation for my first submission, which I did with work peers. In the future, you’ll have recordings from other conferences, which is helpful even if the talk is totally new.

My Red Flags

Previous experiences help to identify submissions that require a dose of skepticism. This doesn’t guarantee immediate rejection, but does require more effort when reviewing: who is the submitter, what is her/his background, has s/he posted on this topic, are there other submissions that are stronger, does the topic/subject stand on its own?

• Everything: The Let me tell you everything about X submissions are usually either too general or unfocused (or both), and similar posts are often available online.
• Live Coding: Do you attend conferences for group Pair Programming sessions as a result of the presenter not finding their syntax/logic errors? I don’t. I’ve witnessed too many fiascos and don’t trust them (aside from Tricia Gee and Simon Maple, who proved themselves to be masters).
• Multiples I: Multiple submissions from single submitter of identical content, either in multiple tracks or of different session types. It may be that the submitter is unsure of her/his content, which may be resolved by working with the submitter, or that the submitter is fishing for an acceptance.
• Multiples II: A large number of submissions from a vendor attempting to raise their technology’s visibility, usually hoping that something resonates with the reviewers. Requires effort to sort through the different submissions to find something appropriate for the conference.
• Numbers: often of the 50 x in 50 minutes form: kitschy, buzzwordy, general interest, and rushed, rarely leaving time for Q&A.
• Vendors: Contentious among reviewers: is it a vendor explaining best practices for solving common problems or a blatant product push? I prefer submissions from those who use the technology as a client of the vendor rather than the vendor itself, but not always possible.
• Weird/Inappropriate: Topics or subjects that divide people are not appropriate for conferences, such as a submission (roughly) entitled Introducing Religion Into Secular Software Engineering. Universally down-voted.

And If You're Not Ready?

Other options exist if presenting at big-time conferences is too big a leap, and you want to start small, such as presenting at work or local user groups. These groups are often smaller, and you may feel more comfortable among acquaintances.

Another possibility is conference labs, where you can help others come up to speed more quickly on a specific technology, protocol, or approach. Again, many possibilities exist, from authenticating using OIDC to making Pepper the Robot walk and talk. Labs tend to require more preparation, which may explain why not many are submitted (especially in recent years).

Closing

So, how soon are you going to submit your talk? Take the leap, It’s personally rewarding and professionally beneficial, and you may even surprise yourself.