cyberz.wtf

Working in the cyberz makes for many WTFs

Oct 30, 2023 - 9 minute read - Conferences

Confessions of a Conference Program Committee Member

I made this post on Linkedin earlier this year, when the blog was still collecting ether-dust. I decided to publish it here because it was very well recieved, mostly by people who are on other conference committees and review boards. It’s not my intention to discourage anyone from submitting a talk to a conference, quite the opposite in fact. Conference organisers want lots of submissions, but they need them to be good. Hopefully this will help some of you who are thinking about it hit the mark.

TL;DR: Be clear, be concise, be qualified.


 
This year I was privileged to be part of the conference program committee for the Australian Cyber Conference, AKA Cybercon 2023. It’s a huge honor to be able to play a part in shaping the conference, and I’ve been grateful for a chance to give something back to the Aussie cyber community.

Practically speaking, the main job of the program committee is to review talk submissions from people who want to present at the conference. Cybercon runs for 3 days and has over 20 streams, which means there are a lot of slots to fill. It also means there are A LOT of submissions to review. We had over 500 in the first round, which works out to hundreds of hours of effort, considering they all get reviewed by every member of the committee.

It wasn’t my first time reviewing CFP submissions, but I’d never done it such a massive scale before. When you have so many submissions to review, you can only spare a few minutes on each one (if that), and I quickly developed filters to help weed out the ones which either didn’t meet the required standard of quality, or had some other disqualifying issue, because without them it’s impossible to get through them all efficiently.

Believe it or not, despite the huge number of first round submissions, we had to go to a second round. That meant another few hundred papers to review, which took to grand total to over 800. You might be thinking that the fact a second round was needed to fill the program despite receiving so many first round submissions speaks to some fundamental issues with the quality and types of submissions we received. Well, you’d be right.

So, to make everyone’s life easier (but mostly mine), I thought I would write a bit of a primer on how (not) to write a conference talk proposal. In other words, here’s some advice on how to avoid getting filtered and ensure your paper gets a proper review.

Standard disclaimer: Everything below is based on my own personal opinion and experience as a committee member. These views are my own, I don’t speak for or represent the views the AISA board or any of the other committee members.
 

1. Don’t Blather.

Open with what your submission is going to be about, then move onto context. If your submission opens with “In today’s challenging cyber landscape it’s more important than ever to be aware of emerging threats and blah blah blah blah…” or some other pointlessly verbose scene setting nonsense that reads like it was copied out of a marketing brochure, you’ve already lost me. If your submission has 3-4 paragraphs of this before it gets to what the talk is actually going to cover, I’m not even going to bother reading it. I will maybe skim forward to see if I can find a paragraph starting with “this talk will discuss…” or something, but chances are I’ve already made up my mind that your talk is probably going to be a similar amount of generic and/or useless context with little content of actual value.

Reviewers want to get the best understanding about your paper in the shortest amount of time possible. That doesn’t mean write one paragraph and leave it at that - very short submissions will be skipped for the same underlying reasons - it’s not clear what the value proposition of the talk is. If you want to get your message across well, be clear and concise. Talk to your content, methods, and lessons. Avoid jargon and buzzwords. Most of all, don’t bullshit.

Also keep in mind that what you put in the talk abstract/description is what will end up in the program, a punter is going to have the same reaction we do if your submission is 500 words long - they’re going to find something else that seems more accessible.
 

2. Read the instructions.

You wouldn’t believe the number of submissions we received where the submitter clearly didn’t read the instructions. Some tried to put 3 or more speakers into a breakout session, despite the fact that the instructions were very clear that it was a maximum of 2 and anything bigger should be formatted as a panel. Others tried to cheat the system that limited a speaker to 3 submissions by registering multiple speaker accounts. Even something as simple as using the “key takeaways” box to continue blathering on about the content because they ran out of words in the description section, without actually listing any key takeaways.

Be aware that program committee members are usually chosen because they are smart people, you’re not going to fool anyone with cheap tricks or trying to cheat the system. More likely you just get binned for disrespecting their time.

And while we’re on the subject of instructions…
 

3. No sales pitches.

The Cybercon CFP is very clear that all talks are meant to be vendor neutral and not be sales pitches, yet we received a massive number of submissions from vendors that were either blatant sales pitches, or thinly veiled attempts to hide one by talking about the advantages of XYZ technology when it just happened to be the core function of their product. Honestly this was probably the one thing the whole committee was united on, anything that smelled even remotely salesy was an instant bin.

Along similar lines, if you’re going to submit a panel, don’t have all the panelists be from the same company. This was something we saw more from consultancies and service providers rather than vendors, but the principle is the same. We’re not here to provide you with a photo op for your execs to put up on your website.

My advice to vendors that want to have an on-stage presence at the conference is don’t send a sales person, send an engineer, a developer, an auditor, or some other person close to the tech and processess. I will say that this can vary depending on the conference and the audience, but for any conference I review for, a submission from a technical person is far more likely to get accepted than the exact same submission from a sales rep, no matter how senior your sales rep is.
 

4. Think twice about jumping on the trendy topic bandwagon.

As you might expect, we got more submissions on AI than any other stream this year. But let me tell you something - when it comes to trendy topics, bleeding edge and emerging tech, unless you have PhD in the subject, or at least deep and direct experience working with it, no one cares about your opinions. Having 20 years of experience in infosec does not make you qualified to talk about AI. Being a CISO, or VP of sales at a massive cybersecurity vendor does not make you qualified to talk about AI. Have a degree in machine ethics? OK, I’m listening.

Oh and in case you are wondering, we do check. If you claim to be an AI expert in your bio, I’m 100% going to look you up on Linkedin, Twitter, and whatever institution you claim to have studied at, etc. If your experience doesn’t match your claims, we’ll know.

Qualifications aside, the competition for speaking slots on trendy topics is fierce. Thinking that your talk being topical gives it a better chance of being accepted is delusional. There’s a fixed number of speaking slots in every stream, if you want a better chance of being accepted, pick a stream which isn’t likely to get many submissions (Cybercon Hint: Most other streams except strategy/leadership, GRC, awareness/behaviour change, and threat intelligence).
 

5. Key take-aways are KEY

Our CFP portal has a whole separate page for people to put in their key take-aways, and this is really the place to sell your talk to the reviewer. This is where you spell out exactly what someone who goes to your talk is going to get from attending. If all you can be bothered to write is “principles for enterprise risk management” or “the challenges of running a modern SOC” then I just assume your talk has nothing noteworthy to say. Be specific about your key take-aways if you want to really demonstrate that your talk has substance.

As I mentioned above however, DO NOT use this space just to provide more context or background for your content, or talk about yourself.
 

6. Proof read before submitting.

Call me a pedant, but if your submission is full of spelling or grammatical errors I just assume your ability to deliver a coherent message verbally is equally poor. Every modern browser has a spell checker with real time visual feedback built-in, there’s no excuse for typos or spelling mistakes.

I’d also recommend getting a peer to review your submission first to make sure you didn’t miss anything like having and “or” instead of “of”, and also to check that it actually makes sense. There were at least a couple of submissions this year that were literally unreadable because they were so convoluted and nonsensical.
 

7. Don’t bullshit in your bio

I generally try to read a submission description fist and a bio second to avoid forming any preconceptions, but even so, there were times when I changed my mind about a paper because the bio was full of bragging and self-aggrandisement. Calling yourself a thought leader, a sought after keynote speaker, or some other self appointed expert doesn’t impress anyone, it’s more likely to get you an express ticket to the bin. Likewise for pasting in a laundry list of certifications you claim to have.

A speaker bio should be more than a CV, it should tell us who you are. Honestly I reacted better to bios which talked about being a nerdy board gamer, or what sort of kid they were, than the ones which were a dry list of professional achievements, because they demonstrate the human side.

Yes, its important to establish that you have experience or credentials to speak on your chosen topic - but stay on topic. Being a CISSP is not really important if you want to talk about APTs, but working in a team which tracks APTs is.


 
I could go on, but I’ve probably ranted long enough for one post already. There will be more tips to follow in Part 2.