On Saturday I was fortunate enough to attend the Speaker Workshop for DDD: East Midlands, which was aimed to supercharge the speakers' talk game, as well as help support newer speakers and give them a set of more formal tips and tricks to get started with.

Anna and I aren't speaking, but we are going to be on a stand talking about Hacktoberfest, which this will definitely look at helping, as well as some of the other speaking engagements we've got coming up.

The wonderful Dylan Beattie was running the workshop, and entertained us very well through the day.

I've written up my notes from the day, but as it was a full day with lots of points and a few interactive sessions, I haven't quite covered it all. Also, I've not necessarily written it to flow in the most prose-like manner, so it may read more like notes in places.

What makes a great talk?

The first section was talking about what makes a good talk. Dylan spoke about how it isn't actually a science, as some want you to think, but something that you need to work on and may find what works for you.

It makes the most difference if you've got enthusiasm for a topic, and actually care about what you're talking about.

You need to build a connection with the audience, get them interested, and share your thoughts.

Determine what the main things that kill the connection between the audience and the speaker and stop doing them, for instance:

• distraction - keep them engaged, to the point that you make them forget that they're uncomfortable
• offense - you could make a bad joke, you could misspeak - be aware and try not to!

Building the talk

In this section, Dylan had noted that you should get over the sound of your voice / your appearance on video. You have to deal with it, as that's what everyone else hears and sees you as, even if you don't (due to science!).

Talk titles

Dylan mentioned that you should look to have a snappy title, with a hook, such as:

X: the pain and the promise

Describe a problem for the group, and then solve it.

X is dead! long live X

I.e. if you were talking about how Java isn't what you used to hear about

how I learned to love X

This is great for unpopular / not very intuitive things.

10 things didn't know about X

It may be like a BuzzFeed clickbait story, but it works!

from X to Y: engineers journey

Instead of going for "this is the only right way to x", you are showing others your thought process and experiences. Because engineers are generally people who like being correct (and technically correct, at best) it means that they'll likely pick holes in your story if you play it as a "right way" to do something. If you instead share it as your own thoughts and experiences, they can't find faults in it.

It also helps to validate others' approaches and make them think "hey, we've done stuff in a better way than them - awesome!".

how X really works: shocking truth

A good way to dig into the internals, while being quite catchy.

Focussing on the content

Dylan noted that the slides should be your last thought - the whole point of the talk is the content and the act of you talking, not the way it's presented on a screen.

You need to think about the raw content, making the real focus on the words you will be speaking rather than the pretty stuff behind you, drawing attention away from the words.

Dylan mentioned that generally he will write out all his content, in its entirety, as a sort of script. However, he knows that on the day he won't actually be word-for-word, but it's more for structuring the content and seeing how much he actually knows about the subject, leading to what needs to be researched.

Dylan noted that he's done a number of talks now so he has a baseline of how many characters he can say a minute, leading to being able to extrapolate the time a given "script" will take. He noted that there are of course issues with this because when starting out, you'll be faster or slower on stage, so may throw that off, but over time you'll be less nervous and will start to have a consistent speed.

We spoke a little about the difficulty of shorter talks, where you're incredibly confined by the timelines, such as the DevOpsDays Ignite talks or the PubConf talks, where you have a set time limit and number of slides, and you have to hit your time perfectly - no chance to repeat even a sentence.

Speaking of slides, Dylan spent some time talking about whether you actually need them. He recounted some "chaos situations" where not having slides has helped where i.e. the projector has broken, or there's been a fire drill and they've had to continue the event outside, but haven't had the screen or weather for slides. He noted that because you're there to deliver a talk, not death by PowerPoint, you should focus on that content.

If you can give the talk with no slides whatsoever (but still the option to have notes), that makes the talk just about the talk. This removes your safety net of having the slides there to distract the audience from gawping at you, but it's a great tip I'll have to think about for a future talk.

Knowing your audience

There are a number of ways to gauge your audience - for instance, what do you as the speaker want to get out of it? Are you expecting a future employer to be there? Are you looking to hire someone? Or someone to work on your Free/Open Source project? What about looking to find someone who may have the answers for you? Are you looking to entertain them? To teach them? To connect and inform them?

All very interesting questions to ponder when thinking about the next talk.

It's also worth thinking about the technical levels in the room - if you're in a Java conference, you could likely assume at least some Java knowledge, but it's not worth expecting everyone to know the language and tooling in and out, because then you make it harder for beginners to get involved; but you also need to be careful not to make it "too simple" for the experienced folks.

Dylan shared a graphic of the viral nature of conversation - if you're able to connect with even one person in the audience who's engaged with the talk, they'll go away and share with others. And each of those people may also share it with others, and so on and so forth.

Dylan shared an anecdote about having a message from someone he didn't know saying thanks for helping him get a job. Confused, he asked more, and found that a talk he gave several years prior convinced someone to re-start a tech meetup. That then meant that this person went along for several months, and then found their new job through it, which is really cool to find out quite a long way down the line.

Humour

We heard a bit about the risk of humour and its place in an international setting. Being an incredibly funny person, Dylan is evidence that humour can work well. But he spoke about all those times it can go wrong, for instance alienating a room of PHP developers because of something they have no control over - the language.

Dylan mentioned that we should poke fun in i.e. the language, but not the developers, but I think it's an even finer line, because it's quite a personal thing to say "lol PHP sucks", which many people are aware of the historical PHP issues. But modern PHP is a very (awesomely) different language, so you're belittling the work folks have done to make things better. And for newcomers who may only know PHP, you're instantly making them feel awful because they may not know why you're saying those things and so are regretting learning it, etc.

We heard a little about the stereotypes of humour around the world, and that they can be based in the fact that different regions and countries have different types of humour. If you're not sure about whether a joke will land, check the cultural references with the organisers to make sure the joke will land. Dylan also recommended running through your jokes with "someone who doesn't look like you" to make sure that it's applicable to more diverse groups, and doesn't cross any boundaries.

Dylan also shared a great tip - before the talk itself, try playing some comedy sketches to see how the audience react, as it'll help you pick up on any dos or donts.

Speaking of the organisers - check very carefully that you're not going to break the code of conduct - both with these jokes, and generally. Find the code of conduct for the event, and read it carefully. Be wary if there isn't one, as it may be that the event hasn't thought that much about inclusivity.

Colloquialisms

Another interesting point is to be careful about colloquialisms - in the UK you'll hear crazy and guys thrown around - the former simplifies and belittles mental health disorders, and the latter is not in any way a gender neutral term (read You Guys if you've not heard this before). These are just some specific examples - but if you do slip up (and you likely will at some point), simply apologise and move on, and see if there's anything you can do in the future to learn from it.

Audience Interaction

Audience interaction can always be hit-and-miss, because you may have someone who just doesn't get it, or someone who's too good and ruins the fun. It could be great, or it could be horrible. It's generally better if you have everyone interacting, as you get a bell curve across all the group which gives you some balance and diversity.

Questions

A really great idea around questions is that you should never let go of the microphone as it'll help you stop people saying "this isn't really a question, but .." - by keeping physical control of the microphone you can control the interaction much more easily.

Dylan mentioned that maybe it's better to take questions off the stage, as it'll allow the next speaker to come in and get set up as well as give you more time to actually discuss with the audience without needing to rush to get to all the questions.

Receiving feedback

It's useful to get feedback from the audience on something that they found positive, and something they'd do to improve the talks. We did this with the group on the day, and there was some really awesome stuff being shared both good and constructive.

But remember that some people just flat out won't like your talk, so remember to not take everything too much to heart! Try and take the feedback as a whole.

Slides

Onto slides, we learned some more about how to actually do them by first running through the hall of fame of what not to do, discussing some of the horrible choices that had been made.

Blank slides

Dylan spoke about having slides intentionally left blank, and that you should avoid it at all costs - the audience will think you've not noticed the projector has broken and will be looking to get your attention.

If you must leave a slide devoid of content, maybe have an image that supports your point? But then why do you need a slide at all for it? Something to think about.

If you're leaving lots of blank slides, why not remove your slides all together? Dylan mentioned it's hard to mix having some empty slides and some that aren't - you really have to go one way or the other. Maybe have a static photo so there's something displayed behind you, but otherwise do the talk as a talk, not a presentation.

Bullet points

If you decide to have bullet points, make sure that you give the audience time to read them one by one. You should have a maximum of 6-7, and shouldn't have nested bullet points, because then that should be its own slide with the nested bullet point as the slide's bullet points. Bullet points should make sense in the context of the other bullet points - if they don't, split them out.

Transitions and Animations

Transitions and animations should be used only when they actually make a difference, such as animating an arrow being drawn, or a UML diagram that visually increments with the flow.

Fonts and Colours

Dylan had a few key comments in terms of making slides visible:

• "Make the font bigger. Yeah, bigger than that"
• Make the text brighter
• Add better contrast by mixing brightness and colour
• Fill the slide with the text, so it's more visible at a distance

A recommendation from Helen was to put the slides in greyscale, as it'll help the contrast pop and allow you to see whether the slides work well.

Remember that your lovely colour scheme for code snippets may work when looking at it on a large monitor, a few inches from your face, in a well-lit room, but on a projector, in a poorly lit room, it really won't work well.

Dylan recommended stepping back ~6-12 foot from your laptop and squint a little, and check if you can read the text. If not, your audience isn't going to!

Live demos

This section works a lot better with the video Dylan showed, but it was all about never doing live demos especially if you're going to be writing code in front of people. In this video he showed himself writing some code, making a few mistakes, then a few more, and finally getting to the bit that the audience actually wanted to see after a couple of minutes, totalling ~5 minutes of demo. This can be an excruciating process that is never fun to do on stage, and when something goes wrong, you could have hundreds of people wanting to shout the right command or sequence of steps to go through to fix it.

With some clever editing work, he was able to trim it down to ~2 minutes of polished demo, which required him to exactly 0 live coding. He now had time to narrate over the top of the video, instead of trying to type and talk which makes for a much better audience experience, too.

We heard a little about being able to do it if you're incredibly well prepared, but what's the point? Unless you need to completely wow people (in which case, who says it's actually all real and you're not faking it anyway?) then you may as well pre-record it, so then you don't need to rely on WiFi, you don't need your own machine and you don't need to be in the right mindset to be able to write all the right code - which is hard enough without people watching you!

If you're using hardware you could always have the devices on stage to hold up and show people what you're talking on, but it doesn't need to be using them live - because they're also going to be dependent on WiFi and may even be impacted by whatever tech is in the room, too.

And for proof of how good you should be to do a live demo, I would say Scott Hansleman's talk Open Source C#, .NET, and Blazor - everywhere PLUS WebAssembly at FOSDEM 2019 is the bar. Don't do it if you can't be as good as this!

Top 10 Speaker Tricks

Dylan ended the day with a Top 10 list, which was not the clickbait it most likely could've been!

The clicker trick

If you've got a clicker (which you really should do) and want to know whether it works when you're up on stage, the recommendation is to have two slides that look exactly the same to the audience, but have different speaker notes.

This will help you flick between them and easily pick up on any issues, before actually changing the slides for the audience.

Intro video

Dylan recommended that, depending on the structure of the event you're speaking at, you could have a video setting your talk up. Note that this intro may not be "this is Jamie and this is what his talk is about", but rather a way to provide some structure and allow the audience to know when you're going to start.

For instance, having a 5 minute countdown on the video would allow the audience to know when they need to be back for i.e. if they need to pop to the loo, or grab a drink.

It's also a great way to grab attention, because people are like "ooh it's only 30 seconds to go!", as well as having an engaging video to get them ready for your talk.

Introduce yourself

Most speakers do this, but it's still worth mentioning - it's a great idea to introduce yourself, making sure to say your full name. This helps in situations where the name may not be as common, as well as helping the audience get to know you a little better. It will also help with future conferences / sessions where someone can rewatch a video of you speaking and can find the pronunciation of your name.

It can be useful to share why people should care you're spouting words at them - why are you i.e. an authority they should listen to?

It's also a great way for you to introduce how to reach you elsewhere.

One great tip I follow after a few folks shared it with me is having your i.e. Twitter handle on each slide, as then people who've missed the initial slide can always see what your handle is so they can interact with you and share comments about the talk.

Breaking up the talk with video

Dylan recommended this as a way to give yourself time to catch your breath. This can be a video that emphasises the point, but it could also be something to just give you a little break.

Katie Fenn has mentioned in the past that she uses GIFs as a way to break up her talk, and give her time to take a drink, as well as give the audience time to take in the talk, as well as having a cute/funny GIF to enjoy.

Take an HDMI cable

Dylan recommended taking an HDMI cable to test with the hotel TV, so you can have a run-through of your talk, as well as use it for i.e. Netflix afterwards.

Empty your pockets

Dylan mentioned that it's hugely important to empty your pockets! For instance, you can't put your hands in your pockets if they're full of stuff! It also means that you're removing unnecessary noise, as i.e. your keys may be jangling as you move.

It's also recommended to remove things like your lanyard (if the event has them), as it can only get in the way of your microphone and doesn't need to be on display at this point.

The stage is a landscape

This was a nice way of thinking about the visual ways to give a talk, for instance "the client is over here, the audience is over here", to which the audience may react by thinking "oh god he's gone over there, what does the client want now?"

This makes it more like entertainment, but keeps the story engaging.

Assume everyone is a dev

It's an unfortunate case that it still needs to be said, but never assume what role someone has just by looking at them. Break every assumption you have about what a developer (/ someone technical) looks like, as it will only make things painfully awkward, and non-inclusive.

Dylan recounted a time where he was in Israel having drinks after a conference and was approached by two soldiers with AK47s, who "wanted to speak to him". After a nervous exchange or two, he found that they wanted to ask details about his talk. The two soldiers were in the signals unit of the Israeli Defence Force and as such, if they're going as part of a work event, they needed to be there fully kitted out.

Assume that everyone is technical, and that they want to talk to you - assuming anything else will be a bad idea!

Sharing slides

Dylan mentioned that generally your slides should not be in a place where they're built for out-of-context reading. If a event is pushing for them, then yeah, you can share them, but they may not be useful for anyone but you.

Dylan mentioned that instead of sharing slides, he would prefer to turn the talk into a blog post, using his pre-prepared script, so others can read in long form the talk, instead of having to i.e. watch a video.

Also, reserve the right to change them! The tech industry is constantly changing, so if you're sending slides months in advance, does that mean the event is happy with out-of-date information?

Keep audience involved

Make sure they're still paying attention, and keeping them engaged.

Conclusion

I'd originally thought that the whole group would be asked to present during the day (as there were two slots in which we would be presenting with and without slides) but when finding it was a voluntary effort, Anna and I decided not to speak. I'm not sure if this was the best idea longer-term as it would've been good to have some feedback from the group, but it's too late now!

This was a great day, and I learned absolutely tonnes. Although I've given a few talks now at meetups and conferences (without anything formal in terms of how to speak), this helped put me on the track of "wow there's a lot I've not thought of that I need to do to try and make things better for the next one". I've got lots of new things to try and to hone my existing talks - but I think the biggest winner will be plan it further ahead and practice it!

There's a tonne of content I couldn't get down, because there were so many great stories and anecdotes from Dylan, but I promise you - it was all funny, interesting, and made his tips more appealing!

Huge thanks to Jess and Moreton for organising it and inviting me to it, and again to Dylan for running it and sharing some great tips and stories.