First off, congrats! You’ll do great! I made a list of things I’ve discovered over time, but I don’t want to stress you out thinking that you have to memorize all this stuff. You don’t have to any or all of it, I’ve just found that these have made my own speaking clearer and better-received.

• Practice speaking at 80% speed. You want to train your brain to get used to a feeling of speaking almost uncomfortably slowly. When you’re in front of an audience you will likely tend to rush; forcing yourself to slow down will counteract that tendency and make you talk at a normal speed. This is also a natural counter to “ums” and “ahs”, which are usually the result of speaking faster than your brain can think.
• Practice finding opportunities to stretch out words where possible, usually along vowels. When you need to give your brain time to think, instead of saying “um” or “ah” you can just stretch out the vowels in the words you are already speaking. Seriously, just walk around speaking to yourself in your head, except trail and hold the last vowel of the word you’re saying. Suddenlyyyyyyy you’ll souuuuuuuund like thiiiis, and if you practice stretching out your words you’ll be able to do it when you actually need it.
• “Make eye contact.” I put this in quotes because each member of the audience isn’t expecting you to make personal eye contact with them – they just want to see your eyes flash up to look in the vague direction of the audience. All you have to do is flick your eyes up every now and then and scan the room a little bit. You can imagine trying to look at people’s foreheads instead of their eyes to make it less intimidating.
• Put in more pictures than you think you need. Every time I finish a talk, I always look back and regret not adding more explanatory pictures, diagrams or charts. Even if they don’t add any new informational content, pictures give some visual variety to your presentation and give time for the audience’s eyes to rest. It may seem stupid, but even just putting the logos of the products/languages/tools you’re talking about can help.
• Try not to read off your slides. This may be hard since you’re relying on your slides to guide what you’re saying, but I try to speak about the important parts of the topic and let the slide text be the more extended, complete version of the idea.
• Make your font size way bigger than you think it should be.
• If you have to show code, be minimal about it – with a large block of code, your eye isn’t drawn to any point and the audience will struggle to find where the code you’re speaking about is. Maybe only show a function and its call signature, or a single line to show off a cool operator in a language. If you really, really, really need to show a block of code, you might want to ghost it out and highlight each line of interest as a separate “slide.” This gives the audience a visual anchor to look at as you’re going through each line.
• The audience wants you to do well! They are on your side, and are actively looking to forgive any mistakes you might make. If you do make a mistake, give yourself some time and space to recover and keep going! People will remember your talk, not the 5 second pause you took to remember where you were in your slides.
• If you’re giving a longer talk (maybe 15 minutes or more), it can help to show a table of contents slide at the beginning and refer to it throughout your talk. Not only does this remind the audience how all the pieces fit together, but it can help you write the talk since you have an outline to work from.

Good luck!

I refer to my own Principles of Authorship and Delivery and the inspirational quotes and articles that follow it in my own talks repo.

Rehearse! Don’t be afraid to literally write down what you’re going to say in order to help plan timing. I know that I tend to go off on tangents and add silly remarks that take up precious time if I don’t write myself plenty of guide rail ahead of time.

Ask for help from experienced speakers! There are literally hundreds of people on Twitter who are willing to help out. Look for folks talking about “developer relations”, they’re more likely to be interested in mentoring sessions. Check if the conference at which you’re speaking offers mentoring sessions - I know that my conferences offer them for CFP abstracts pretty openly and as time permits for full talk development.

I think zach holman made a great summary: https://speaking.io

Gary Bernhardt wrote about how to prepare a talk.

0. Have something interesting to say.
1. Have a clue as to your audiences level. ie. They should be able to learn something from what you say.
2. Know what you’re talking about, preferably proving so by having done something.

If you don’t meet those three criteria, no slides or fanciness will save you.

3. Test your exact presentation setup long before the talk. ie. When the clock hits “start”, you start talking not pfaffing with your equipment.
4. Demo’s are like going into production….. you’ll be tempted to tinker to fix that last issue before you deploy/talk…. you better have a clean and tested, build, test, deploy and roll back strategy.
5. Choose a couple of friendly people about 3/4’s of the way to the back of the hall. As you give your talk, speak to them directly and personally. This will fix voice level /eye contact/nervousness problems. If need be, pre-arrange with a friend to go sit there.

Ask your self five times…. I could have just written a blog post, what am I doing that makes this a great talk, not merely a blog post?

Clues…

• I’m interacting with these specific people in front of me…. in what way am I doing something different than addressing “to whom it may concern”?

• How am I using the fact that I can change things that are before them, second by second?

• I’m asking maybe a 100 people to shut up and listen to me for an hour… that’s about 100 man hours. Have I done enough work on this to create over a 100 man hours worth of value?

• you need to convince them they should care about what you saying,

• you need to convince them you’re correct,

• you need to make it possible for 95% of them to understand what you’re saying

• you need to reduce what you’re saying to a small concrete set of things that they will still remember next week.

Overarching all this is the pay off…..

ie. What, when they get back to their day job, will they individually and personally, do different and how will that benefit them personally?

Does that sound like a very tough ask? Yup, but you asked for a “Great” conference talk not merely a good one. You might want to dial back your expectations a little. ;-)

Anything Gary Bernhardt says, which boils down to “practice, practice, practice” anyway.

Also, no wall of text in the slides, definitely do not read from them. Make sure the colors are legible.

If you’re sure your jokes are good, go for them, but unless you’re really funny, they probably aren’t. I rather see a clearly explained talk, with good content but potentially “boring” than someone trying to be funny and engaging but only succeeding half the time.

Also, avoid live demos like the plague. Murphy hates them.

Other than that, good luck, read the other comments, they’re way better than mine. Keep cool and it will be alright =)

Rehearse. Revise. Rehearse. Revise. Rehearse some more. Rehearse to a friend you trust. Revise. Rehearse again.

Tired advice, I know, but it’s because those are the foundation of a talk. It strips away all the impurities and leaves just the talk itself, purified. Often the raw and refined versions nothing like each other. Revision often shows you a better, clearer structure, and you cut everything away and start anew.

Some people are (quite reasonably) concerned that too much rehearsal will make the talk seem artificial or scripted. It’s the opposite. Turning the talk into muscle memory means you don’t have to concentrate on remembering it. Your focus is better spent on things like reading the audience and giving life and presence to your words. You can tell when a person hasn’t rehearsed, because you keep noticing that it’s a talk.

In terms of specific techniques, make recordings of your rehearsal and watch them. Identify what you like and what you want to improve. One big thing I found out is that I talk way too fast, peaking at 220 wpm when I get excited. Now I deliberately practice speaking more slowly, which makes the talks a lot better off.

Do not try to expose too many different ideas. Simplify your message and repeat it over several times with different words. If it relates to something else (a GiHub repo, etc) don’t spend time getting deep into that, just give a brief reference (“and this can be checked in url blablabla). Summarise. If they are interested in dig deeper, they’ll go to the linked stuff.

Practice. Slow down. Have pauses, it’s okay to not speak for a moment. Try to have fun, if you look like you’re having fun speaking people will have an easier time enjoying it.

Nina Zakharenko has a really great series of articles on making great tech talks: https://medium.com/@nnja/the-ultimate-guide-to-memorable-tech-talks-e7c350778d4b

Which things do you like and dislike when attending to a conference talk?

One thing I dislike in particular are talks that just give a tutorial about how to use X. They’re boring and quite frankly useless.

That doesn’t mean that all introductionary talks are bad, just the ones that parrot the tutorial/tour/whatnot. For example, I spent some time preparing an introductionary talk about Go which explains a bit about the semantics of the language, the reason why things work as they do, contrasts to some other languages, and other observations based on my ~3 years working as a Go programmer.

I find this much more useful, because it adds to the tutorial, rather than just repeat it.

One other tip: rehearse into an electronic recording device where you can: 1) time it and 2) hear what you sound like. You’ll hear where you stumble, where words or ideas are not clear. And timing it is important. You don’t want to end up being either rushed because you have more material than the time available (and be tempted to talk too fast) or run out of material (although you can always have a Q&A session planned, or have extra material available).

Remember, you’re giving the talk because somebody thought you had something important to contribute. The audience will respect that and will go in expecting to hear something good. You’re up there because you’re the expert. Be confident.

Above all, relax. Your audience will have a certain amount of empathy for you; they will feel what you are feeling. If you’re relaxed, they’ll be relaxed. And if they’re relaxed, they’ll be more open and receptive to what you have to say.

Bill Murray: “The more relaxed you are, the better you are at everything: the better you are with your loved ones, the better you are with your enemies, the better you are at your job, the better you are with yourself.”

I like Conference Presentation Judo by Mark Jason Dominus.

Hey! I’m also giving my first infosec talk for CircleCityCon in 3 weeks.

I’ve given talks before at work, and at a 3d printing con (MRRF). I’ve also had my first heckler with that conference. That was rather enlightening on how I handle questions like that. That was an interesting experience… I had to completely grasp the theoretical proof and able to convey it accurately, calculate an error for practical calculations, and able to do so gracefully. I eventually said “I’d be glad to talk further about my implementation and your concerns after the talk, along with anybody else interested or concerned”.

I don’t see having hecklers at CircleCityCon. I might, and I’ve already prepared for a semi-hostile Q&A. I’ve also been able to give a variant of my speech where I work for a lunch and learn (focused on identification of radio devices,searching vuln websites, defense, and removal if needed. I ran at 54m for an 1h talk, which was 6m of Q&A.

My last talk included a live coding demo with good visuals, and it was popular.