Thread by @rmoff

⚡️Writing an abstract for a lightning talk…a thread 👇️

#DevRel

Lightning talks are generally 5-10 minutes. As the name implies - they are quick!

A good lightning talk is not just your breakout talk condensed into a shorter time frame. You can't simply deliver the same material faster, or the same material at a higher level, or the same material with a few bits left out

A good lightning talk has been specifically conceived of as a *lightning talk*. Let's say it's a ten minute talk. You get on stage, clear your throat, thank everyone for coming. You're a minute in.

You probably set the scene, explain why you're there, make a lame joke about conference coffee. Two minutes in. Eight to go.

You have time to make one or two *at most* salient points that you want the audience to walk away with at the end

The whole tell people what you're going to tell them / tell it to them / tell them what you told them -- that's ok by me, it's tried and tested - and so let's give a minute for "what you'll tell them", and a couple of minutes for "what you told them" recap

Now we're down to five minutes. FIVE MINUTES to actually tell the audience something useful. That's *plenty of time* if you've thought long and hard about what that useful nugget or two of info is. But it's not going to materialise out of a breakout session abstract.

Think of your "elevator pitch" about the thing you want to talk about, and then flesh it out _just a tad_. That's your lightning talk there. Don't start with a long talk and cut it down. Start with the interesting nub of an idea and build around it _just a little bit_.

Now you need to write your abstract.

Your abstract should mirror your talk: snappy, interesting, to the point, and engaging.

If your abstract for a lighting talk takes longer to read and grok than the talk itself, you're maybe doing it wrong.

Your abstract should set the scene, make it *crystal clear* what the one or two things that you're going to deliver in your talk are, and then wrap up. That's all.

You need to be specific.

"I'm going to talk about our project" is not specific.
"I'll explain why we opted to deploy Kafka Connect in distributed mode rather than standalone" is specific.

Lightning talks can be out of the context of a larger project. Taking the example above - deploying Kafka Connect distributed vs standalone. Whether you did or didn't in your project, a lightning talk is a great way to share a cool tidbit of information you've learnt.

⚡️Found a cool way to run Kafka Connect in a Docker container that's not so well known? Good lightning talk idea.
⚡️Got a really cool code pattern for checking that messages are delivered? Good lightning talk idea.

⚡️Come up with a good workflow for debugging a Kafka client request in-flight that'll be useful for others? Good lightning talk idea.
⚡️Written a neat open-source tool that'll make Kafka SREs' lives easier and want to show it off? Good lightning talk idea.

(Why open-source? Well, showing off a tool you've written that no-one outside your org can actually use is a bit like taking your cool toy to school and boasting about it and then saying "ner ner ner you can't use it 😝" to anyone who asks for a go)

Your abstract is your pitch; your abstract is the way the program committee will judge if your talk is likely to be any good. If your abstract is vague, waffly, boring, turgid, etc - the program committee are likely to assume that your talk will be too

A good lightning talk is *harder* to do than a breakout session in some ways. You have to be more disciplined in your delivery, you don't have the luxury of time to settle into it - by the time you've done that it's time to wrap up

So the program committee will be looking for abstracts that suggest the speaker is capable of delivering a good lightning talk - not just a breakout session delivered at speed.

What's a good lightning talk look like? For me, the canonical example has to be this legendary one from @garybernhardt - WAT destroyallsoftware.com/talks/wat.