Auntie Aja is back. This time I want to talk a bit about conference session proposals. It is CFP season. I’m busy submitting talk proposals to events I want to attend. My coworkers and friends are doing the same. Like many folks, I’m asking coworkers and friends to review my abstracts to make sure I’m not missing anything important. I’m also advising people who don’t submit to events very often on how to improve the chances that their submission will be accepted. Today I’ll cover some of the issues I see over and over. To demonstrate my suggestions, I’ll be improving one of my old abstracts that never got accepted. Here’s the original abstract:
Some years ago several of my friends got together and had a study group for SICP. While I have a CS Degree, I had never written an interpreter and barely knew Scheme, so I learned a lot during this process. That study group spun off several more over the following years. Those study groups made me a better developer, and I’m fortunate that I’ve had that experience.
In this talk, I’ll tell you how our SICP study group, which finished in under a year, was organized. I’ll also share the list of books we’ve completed since that original study group. I’ll talk about how we organize our code repositories, how often we meet, and what I believe makes a good book or course for a study group to follow.
It Is About the Attendee
One of the most common issues I see with abstracts is the writer focusing on themselves. It is about their accomplishments, their projects, or their employer. I’ve never seen this go over well with a program committee. Conferences mostly exist for the attendees. Even conferences about a specific product, exist to get the attendees excited about the product and to help them be more successful. So an abstract needs to be focused on the attendee’s experience. Sarah Mei puts this very well:
- Don't mention yourself. The proposal isn't about you. It's about what attendees can do with the information you present.
— Sarah Mei (@sarahmei) December 31, 2015
My example proposal uses the words “I” and “we” a lot. Reducing the use of “I” should improve it. The word “we” can be good or bad. If it refers to you and the audience of your talk, as in “We will build a simple example app,” that’s good. If “we” is just the plural version of “I,” like, “At my employer, we are the absolute best at checkers,” you should remove it.
Another part of focusing on the attendee is removing biographical information about yourself and your employer. Your bio will be in the program. You don’t need to put it in the abstract as well. If the biographical information explains why you are qualified to speak on this topic, include it in the part of your application/proposal that only the committee can see.
Also, try to use words like learn and improve as opposed to show and demonstrate. When I worked in EdTech, we focused on what students should be able to do after they finished a lesson. Think about your talk the same way. What will attendees be able to try or do after your talk? And make sure your answer isn’t, “After my talk attendees will be on their way to being half as awesome as me.”
With all that in mind, here’s an improved version of my abstract from above.
Study groups are a great way to learn new things. This talk will teach you everything you need to know to have a successful study group, including how often to meet, where to meet, and what types of books work well for self-teaching. After this talk, you’ll be ready to start a study group at your meetup.
Connect the Dots
Focusing on the attendee improved my abstract some, but I can still do better. If I pretend to be an attendee reading the abstract in a conference program, it is hard to see why the talk is relevant to me. When you are writing an abstract, you are often the worst person in the world do so. You know your topic better than the attendee, and often you’ll leave out the parts that seem obvious to you. Your job is to explain to the attendee why your talk is relevant to them and why they should attend your session instead of others in the same time slot. If you are struggling with this, it may help to use the Rubber Duck technique and imagine your duck is asking “but why should I go to your session instead of taking a nap?” over and over.
It is also good to think about any other biases you may have. I’ve helped speakers who assume that the attendees are just like them, with the same preferred tools and approach to coding. These speakers are surprised when they get to the event and realize most folks have a different background or perspective than they do. So check your assumptions by doing a bit of research online. You can also look for opportunities to explain how your approach/topic/tool can be generalized to other situations. My proposal above is specifically about a community study group. It feels like I shouldn’t have to explicitly say that you can apply the same lessons to a workplace, but that is a common question I’ve received when talking about study groups. I can improve the abstract by stating it applies to more than just meetups. Here’s another version of the abstract thinking about these tips.
Have you wanted to learn a new technology or language but didn’t make a lot of progress? Study groups can provide accountability and help you meet your learning goals. This talk will teach you how to run a successful study group including, how to structure your group (where and when to meet), what types of materials are good for group study, and how to overcome common hurdles. After this talk, you’ll be ready to start a study group with your coworkers or friends.
Be Clear and Be Exciting
One of the other issues I see in a lot of abstracts is jargon and abbreviations. Once, I observed a technical communication workshop where each participant had five minutes to explain their area of expertise, and anytime they used specialized language someone held up a sign that said “jargon!” Watching that exercise taught me how much technical vocabulary we use without even realizing it.
Read through your abstract and think about whether any abbreviations need expanding and what technical terms people may not already know. If your talk is for an experienced audience, you can use more technical language than you would in an introductory session. Pay particular attention to terms specific to your organization. Inside Google, we talk about our Ruby gems and Node modules as language libraries. But when I speak to external audiences, I have to remember not to say language library but to say gem, module, SDK, or package depending on the community.
Finally, it can help to have an exciting or catchy title or abstract. A talk titled, “A technical overview of my API” doesn’t sound particularly exciting. Adding a verb can help. “Introducing: my API a tool to do a thing” is better. It still isn’t great, but it is better. Other verbs I see in many titles are exploring, learning, and building. If you are going to do a cool demo, call that out in your abstract. I remember deciding to attend a talk just because the abstract mentioned a robotic blimp.
You can take the “be exciting” thing too far. Too many exclamation points and adding unrelated demos will make folks roll their eyes. But program committees want talks that will draw a crowd, so talk about your examples and demos, and don’t be afraid to be a little ridiculous.
Conclusion
There are many more ideas for how to improve your abstracts on the web, these just happen to be the ones on my mind right now. If you’ve reviewed abstracts or given talks what tips do you have for speakers?
Top comments (0)