Data Minutes #2 took place on January 21st 2022

On Friday January 21st 2022, I had the absolute joy and pleasure to present a lightning talk at Data Minutes, ran by William Durkin and Ben Weissman. 10-minute timeslots assigned to a large number of speakers, where I used mine to share my thoughts on writing a session abstract for conferences, user groups, or other types of events. I mostly kept our Data Platform / Power BI (community) conferences in mind, as these are the type of engagements I am most experienced in. Basing myself off my prior activities as an attendee, a speaker, a program committee member, and a conference organizer, I thought back on things I liked when looking at session abstracts. If you are interested in watching the recording, you can find it at the Data Minutes YouTube channel (link), and find the slides over on my GitHub page (link)

Disclaimer

In the end, this is a single person writing down thoughts on what works for them. As a result, there are a bias and subjective thoughts involved, and my advice is to take these as nuggets to mold into your own set of handles. Every conference, user group, .. has their own set of subtleties, and will have different things they require and prefer. Meaning, this is not your “easy-mode, get accepted anywhere” solution. You are still the one responsible for providing quality work, and doing the research.

Just 1 more thing before we start.

Before you’re starting to write your abstract, there are a few things you may want to consider. For me, the most important thing to ask yourself is this:

Why do you want to present your session? What are your goals?

Are you simply happy to share your experience? Do you want to have standing room only in your sessions? Are you looking to promote yourself, your product, your organization? There are no wrong answers on this question, as whatever works best for you is what drives your ambition.

The one thing that took me some time to realize, is that you are not trying to draw in as many people as possible to your session, but you’re trying to keep out those people that don’t fit well with your target audience. It’s an odd statement, I know. But in the end, you want to have the people that attend your session to be satisfied with what they have seen, attend other sessions presented by you, or maybe even do business with you. People that misunderstood your intent and message, have a higher risk of being discouraged, and they might not want to attend another session by you again. If you are in it for the long haul, you’ll definitely want to see people attend multiple times, as the attendee pool is not all that large as you might think.

Then, I want you to think about where you are applying to speak, and research the subtleties of that activity. Most organizers put a lot of effort into describing their target audience, and the types of sessions that have worked for them in the past. In essence, they are handing you the building blocks for you to engage with their audience on a silver platter. Is this a more formal conference? Are they looking for 30-minute sessions only? Is this specifically aimed at launching new speakers? Read up on the details organizers provide you, and do some research about prior editions (if applicable). Odds are likely you will find some really useful information you can turn to your advantage to increase the odds of being selected.

Why bother?

Writing these abstracts isn’t just a trivial task you get out of the way because you have to do it. Most of us don’t have the reputation or relations to dictate where we want to speak, we have to prove our proposed topic will be useful to include. After having written the abstract, multiple groups of people benefit from this, to use in their decision-making process. The abstract is a tool in your belt for you to sell yourself to them, and get a chance to share your thoughts on a topic. For me, those stakeholders are:

1. An organizer, and/or member of the program committee
2. A potential member of your audience
3. Yourself

You are pitching yourself to organizers and committee members, as they usually make the decisions who gets planned on their conference schedule, and what sessions are compatible with their goals. You are pitching yourself to members of the audience, as they will assess if the session is right for them, and they will learn something new or have a good time. Unfortunately, some audience members don’t read anything, and end up voicing their discontent (/rant). At some conferences, it is even the audience members voting for which sessions end up being planned.

Most importantly, you are pitching the session abstract to yourself, as this is your first formal moment to think about the scope of the session, content you want to cover, which personas you would like to have attend your session, .. This is where the intent gets a form of reality, and you have to deliver something before next steps can be taken.

Things you’ll want to define

Okay, we’ll start going into the actual abstract, just after you answer these 4 simple (not really) questions.

Target Audience? Are you planning on going very technical, discuss business scenarios, ..? Do you want to give useful tips to new starters, or provoke the seasoned veterans to think hard about a specific subject? Usually, you can distil a target audience if you ask yourself questions about the message you want to send. The target audience for your session has to match with the target audience at the place of your speaking engagement to obtain the best results, especially if you want your attendees to have interest in attending your sessions again.

Session Level / Complexity? In the Data Platform realm, sessions are typically measured using a numeric value in the range of 100 to 500, but these ranges can vary often. They are designed to represent session complexity in an increasing scale. A level 100 session will typically be an introductory session, where a level 500 (or higher) session will be at the expert level. For the sake of providing you with a practical example, I’ll use the session levels we use for dataMinds Connect. 100 (Introductory and Overview), 200 (Intermediate), 300 (Advanced), 400 (Expert), 500 (Guru), and 9000+ (Over Nine Thousand). I’ve witnessed a lot of discussion about levels in the past, and am well aware that this is not exact science. Being as transparent as possible about learning objectives will help you set the session level.

While this number seems trivial, it is a very important tool for you to provide information about your session. Not every audience member reads an entire abstract, but they will base themself off a session title and session level. It is in your best interest to consider the level of your session. For instance, organizers and committees may be specifically looking for an Introductory session on a certain topic, or a session that is diving very deep in some internal stuff of the product. The majority of sessions get submitted in the 100 – 200 range, which means you want your session abstract and topic to stand out.

Prerequisites? Do you expect a session attendee to have prior knowledge about SQL? Do they need to able to understand how joins work? Or how Query Plans can be read? Is it an absolute must to understand Filter Context in DAX? If you are planning on building on a certain topic, and are making assumptions about the knowledge of your attendee(s), it makes sense to make that known. Again, it is about creating that bond between yourself and the attendees, and having them attend your sessions again in the future.

Learning objectives? When everything is said and done, what do you think are the key topics an attendee could have learned? If you consider something to be a key topic in your session, you will most likely want your attendees to pick this up as a learning point from attending your session.

Common Structure

In the majority of conferences I’ve engaged with, a session abstract consists of 4 key segments. In some larger events, there are more segments added, especially when program leaflets are being handed out to attendees. Our community is looking like it is standardizing on Sessionize, which provides these as standard. To limit myself to what I’ve encountered in most cases, these are the key segments:

• Title: 1 sentence, used in schedule, website, leaflets, ..
• Abstract (Body): Synopsis of your session, typically 3 – 5 paragraphs
• Notes: Private to you and organizers/program committee
• Bio: Personal presentation
• Blurb (Short version): Limited number of characters allowed (ranging from 140 – 200), to explain session outline, and to be used for a more detailed schedule. This is more of an exception to what I have encountered, but it is representative enough to include.

Title (Short, Sweet, Fantastic).
Personally, I prefer these to be short and catchy. Briefly describing the problem that will be (attempted to be) solved, or describing the scenario at hand. At maximum, I’ll make them 10 words long. This is my bias as an organizer showing, as long titles impact formatting on pretty much everything we design for a conference. This means schedule, website, intro slides, posters, .. But also, as an attendee you might be turned off if this is a very long sentence, for something that could probably be explained in a few words.

Abstract (The Meat ‘n Potatoes).
As a rule of thumb, you will want to avoid stating the exact same thing as in your title, or put in a ‘to do’. As I explained before, the abstract is your pitch and you want to it to be thorough and useful for those reading it. For writing the actual abstract, we are going to reuse the results of the questions you have answered before, as these are things we definitely want to use.

To start, it makes sense to describe the problem we’re trying to solve, the business scenario we’re facing, or describing the situation. Then, we want to include the audience, prerequisites and learning objectives we defined before. This should result in about 3 – 5 paragraphs, which I think is the good balance between having enough text to explain the specifics, and being too long causing no one to read it. But again, this is a personal preference.

When writing the abstract, I try to look out for usage of good grammar and spelling, especially about product names, or industry related terms (I will defer from starting a riot about AlwaysOn at this point). Yes, people make mistakes and we are all allowed to do so. But if a quick quality check can fix these problems, it will cause a lot of people to make a prejudice that may not be true.

Depending on the conference you are submitting to (do the research!), you can find a balance between formal writing, and sneaking in some quirky remarks or references. The writing style can swing both ways, which is often forgotten. Write too formal, and a community driven, lighthearted conference might not want it. Write very informal, with lots of lame jokes, and you may not make the cut at an academic research papers conference. Again, do the research and find out what works!

Then, I try to avoid using sentences like: ‘we will look at a number of techniques’, or ‘we will describe a few scenarios’. They are very vague, and probably written at a time you were not completely decided on the content you wanted to include in your session. Instead, it can pay off to quickly describe the items you want to cover, as an attendee can decide if they are new and exciting to them, or they may not be as relevant to them as you think.

Personally, I’m not a big fan of including parts of a biography in the actual session synopsis. For instance : ‘Join John Doe, author of Book XYZ and presenter of show ABC with over 25 years of experience in 17 different technology companies throughout the globe with distinguished accomplishments 1234 ..’ is something I think is better suited for the presentation of the speaker, not the session description.

Notes (Insert Bribes Here**).

As an organizer, I barely see the Notes section being used, but it actually is a really useful space. Anything you put in here is private between the organizer, program committee, and yourself. This is an excellent place to include feedback or references from prior versions of this sessions, or the indicate your willingness and flexibility to make this session fit better into their schedule by changing complexity or adding an extra solution method. In the end, an organizing committee always has a certain idea of which types of session and topics they want to include, and it is up to you to prove it can be a good fit.

** For the sake of completeness, this is not to be taken as a serious remark.

Bio (About yourself).

Now let us present a few things about ourself, that can be relevant to the story we want to tell. Depending on where we are submitting, the writing style can vary. In the end, I personally try to keep this somewhat professional regardless of where I am submitting. It can definitely contain some quirks and references, but I don’t think anyone is interested in the fact that you ate 37 hotdogs at the company picknick in 2017.

Which leads to the point that you want to include relevant and updated information about yourself. If you have changed employment 4 years ago, it is definitely time to reflect that in the bio as well. Also, consider the photo you are using for your abstract. Do you really want to use the “after photo” from said picknick in 2017, or the late hours of the Christmas Party in 2018? The photo you choose here, definitely has an impact, so consider your options.

Then, make sure you are including links to you online portfolio, or places where people can learn more about you. Think your blog, LinkedIn page, Twitter profile, GitHub Repo, .. If you already have supporting videos, blog posts, or prior instalments about your topic, this will definitely help your case.

Before you submit

Good, we’ve written everything we needed to. Let’s hit send as quickly as we can, right? Right? As my final piece of advice, I suggest you put some time into the reviewing process. First, make sure you review the content yourself, to assess if it effectively portrays the message you want to convey, and that there are no large grammatical errors included.

Then, I have always had great experiences with getting external opinions on what I wanted to submit. Ask other people to review the abstract for you, and answer a few basic questions. If the responses come back to something completely different than you would expect, you may want to review the abstract again. The questions I am referring to are:

• Who should attend the session?
• What are we trying to solve / describe?
• Why are we doing this?
• What are we learning?

Reaching out to other people can be virtually anyone, and they don’t even need to have prior experience in the topic. Heck, they don’t need to have any knowledge about the subject domain at all. If someone that is completely new to the topic can answer the questions, you can say for sure the message is coming across the right way. But also, other speakers and organizers can have valuable input for you. Cathrine Wilhelmsen phrased it so well by stating we are “aggressively friendly” in our community, and we will always try to help, or find someone who can.

Wrap Up

To wrap up after another lengthy post, I want to thank you for making it to this point. I’ve shared my thoughts here, and I hope you can take away a few things to mold into what works for you. To conclude. Do the research, and be thorough!
Let me know if you have made some changes to your session abstracts, and if it helped you!

Take care!