Say at least something useful and new that most people in the audience do not know already. If this is not the case, better to rethink the talk from scratch. Audience should go aways thinking "I learned a few new things".
Whilst I personally agree that talks are better when you learn something new, there seem to be whole conferences dedicated to intentionally restating the same things over and over again. Its almost as if some people go to these events to have their ideas _confirmed_. Project management conferences I am looking at you!
I agree but I'm not sure this is intentional... I've the feeling that commercial conferences are just simpler to run that way: professional talk-giving persons always saying the same things over and over, with little efforts and without being part of any actual "research" in the field.
One thing that has always helped me is mugging the first few lines until you can get in your rhythm. Sometimes that glare of hundred eyes causes you to forgot about your talk.
This!
It's one of the most important thing to remember – people paid money and came to listen here, and you've been invited as a speaker, so that means that you have something important to tell, and people really want you to succeed.
I also recommend a fantastic book on the topic by head of TED conferences, Chris Anderson - "The Official TED Guide to Public Speaking". It helped me immensely when I was preparing to my first big public speaking event.
Agreed! As I wrote to a comment elsewhere on this page: "Most of the time, they selected your talk based on their interest in the contents (and less so on your delivery), and so they want to learn a thing or two. They will be graceful towards your presentation (style, delivery, slides) if at the end they got what they came for: you sharing data, knowledge, insights or wisdom. You don't want [to make] that too difficult for them, so you should work hard on improving your presentation delivery, but sharing knowledge is appreciated over sharing jokes or just well-designed slides."
You don't have to help people get from A-Z. Quite often they don't even know where to start so going from A-D is enough. Know your audience in advance though.
Remember to pause and speak slower. It gives the impression you are really considering what you are about to say next and allows you a break.
Don't drink alcohol before the talk (unless you need a shot to calm your nerves) and do have a bottle of water available as your mouth will most likely become dry.
Lastly relax. The audience is unlikely to call you out unless you make a total hash of it and they usually want you to succeed.
> Lastly relax. The audience [...] usually want you to succeed.
Great insight, and I've found that to be true. Most of the time, they selected your talk based on their interest in the contents (and less so on your delivery), and so they want to learn a thing or two. They will be graceful towards your presentation (style, delivery, slides) if at the end they got what they came for: you sharing data, knowledge, insights or wisdom. You don't want that too difficult for them, so you should work hard on improving your presentation delivery, but sharing knowledge is appreciated over sharing jokes or just well-designed slides.
Best advice I had about giving talks (from a non-techie) was 'tell a story'. People like stories more than information. If they want information they can mine you for it afterwards.
A lady who runs a daycare once told me, it's easy to get kids to eat their vegetables, if you hide them in mashed potatoes (as a rule, kids hate vegetables and love mashed potatoes).
Don't just tell a story. Use the tools of story telling. Have a three act structure (Setup, confrontation, resolution). Have a plot. Use foreshadowing. Use one of the common generic stories as a framework (Hero's journey, coming of age, etc). Make it personal - bring in either parts of the audiences life, or of yours. And close with a positive message
You know when you were a kid, and you had that one funny relative who'd always tell great stories? Be that relative.
Is it strictly a tech talk? As someone else said here, skip the cruft and get to the point. I came to your talk to learn about the technology, not your life story.
Some people are good at wrapping tech talks into interesting stories. But they are very rare in my experience. If you don't have a story to tell, don't force it. Don't try to present everything as this grand idea that's related to everything you've done since childhood. It gets old really fast.
I've seen students take a course in speaking where they hammer into them this "three act structure". Invariably, the talks they give would be much better if they would just stick to the technology.
In my experience, one of the most important things is to keep your audience in mind. I recently gave a talk about how docker works internally. I knew that a good chunk of the audience was aware of the difference between docker and a VM, so in the beginning, I explained these differences via a more or less fun story. People who already knew the content were not annoyed, the rest got the information they needed.
Another thing is, tech talks tend to be as dry as the Sahara desert. So try to make your talk interesting. Do not just focus on getting the information across, but make it fun to listen.
Practice your talk without slides. This has two benefits: You concentrate on the content, so your stuff by heart at the end. And you don't depend on the slides, in case something goes wrong.
Lastly, prepare for 4:3 - even if they say you get a 16:9 beamer, chances are it's not. And prepare for offline, your Laptop being broken and in case you are doing a live demo: Have a video of it as a backup.
These tips are all just from my experience and may not apply to you, but maybe it's helpful. :)
Plan for any tech or other collateral to not work properly on the day and have contingencies to continue - even things such as having a printout of your presentation storyboard or bullet points to hand.
Just as a guideline, I’ve found that about 1 slide per minute (with not a ton of text per slide) is pretty good. This has worked for me for topics ranging from graduate level math to programming topics.
But as an addendum, your talk should not depend on the slides - the slides should illustrate or add information, trigger people's visual memory for what you said during that slide.
If you write slides with bulletpoints and read them, then er, just, don't.
Know you're talking about. That alone will make the talk more natural, as you'll be able to adapt to your audience due to having knowledge outside of just your research.
This was the biggest change between the presentations I had to give in high school and the ones in college and above. In high school, the topic was usually given to us, whereas in college and later, I got to choose the topic I was most knowledgeable about. The latter meant I was more passionate, more able to answer audience questions and more able to tailor the delivery to the audience.
One piece of advice I heard was that if you absolutely have to talk about a topic you're not familiar with, talk about being a beginner in that topic. Talk about your perspective as an outsider learning that topic in the first place.
To expand on that with "obvious" advice: Know your audience. Present accordingly.
Are you an expert or a beginner relative to your audience? If I'm explaining something technical, I might take a more assertive tone when glossing over details with a novice but speak with more deference to an expert. (e.g. Throw in a few "I think ..." or "My understanding was that ...")
Getting a quick grasp of where the speaker is coming from helps the listener really engage at the right level. Should I double check what the speaker is saying or are they the authority on the matter? Nothing get's eyes rolling faster than someone making blatantly wrong factual errors overconfidently.
+1 I gave a lot of conference tech and HR talks and always failed when talking about something I didn't have deep knowledge about, but thought "that would be cool, now read about it"
Always do at least 1 full rehearsal with a timer, preferably two full rehearsals where the first one you do keep a timer but also have a notebook (physical) present to quickly write down adjustments you want to make.
Do a live demo, people love live demo's, but be prepared for when disaster strikes (it will), if possible run your live demo on a physical device with you during the presentation.
Most places allow you to have 2 devices connected, or quickly switch the HDMI cable to the demo machine.
Do not use a linux machine, I know this sounds harsh, but with all the types of beamers/screens out there, a windows or mac machine will just have a much higher success rate. (I learnt this the hard way, in the end I could choose between mirrored 640*480 or full hd on the beamer only, which makes live demos much harder).
Create short slides, the slides are there to guide you and the audience. Try to prevent reading the slides out loud.
Use images and videos, they can tell more then a thousand words.
I often use the STAR approach to tell my story, this helps structure your talk. You don't need to follow star exactly, but if trying to explain something, it often helps to first give a bit of background why you did what you did.
Make sure you let the audience know if and when you will be answering questions, some talks really benefit from interactivity, but if you are short on time, let people know they can ask their questions later (perhaps add a slide at the end with sources and your contact information).
Also, relax, the audience has already decided they want to listen to your presentation.
It really depends on the topic of the talk. If it's something that can be demonstrated in a quick and straightforward way, do a demo by all means. But I've seen talks where people were forcing a demo into a talk about complicated concepts. There's little value in seeing someone type in a page of code, compile and run. Or seeing something run without understanding what is happening on screen. I would much rather have the speaker spend those minutes discussing the topic.
> Do not use a linux machine
Better advice: make sure you know how to setup an external screen on your laptop and how your presentation software works with it. Try it before hand with an old VGA monitor.
> Create short slides, the slides are there to guide you and the audience. Try to prevent reading the slides out loud.
I would argue that the slides are there for the audience. Ideally, you need to be able to present your talk without seeing your slides. They are not cue cards for the speaker.
Very short slides light on content (e.g. memes, one word or sentence per slide) make for a terrible tech talk in my opinion. Do make your slides informative. They should complement what you are talking about. Show a relevant graph, code snippet, etc. related to what you are talking about. If you can't do that, fall back to a summary of your spoken content in a 3-4 bullet points per slide.
Personally I disagree with this point and have developed a presentation style I'm happy with based on the slides being my cue cards (average 5-10 presentations / year for the last 15 years).
I do NOT read the talk from my slides and can't stand it when speakers do that! But, each slide should jog my memory of everything I need to say at that point. Maybe I'm talking about some stats as background, fine, the slide should be a bar chart of those stats, or a map, or an illustrative photo. Rarely a list of bullet points, though I don't prohibit them altogether and will tend to conclude with a list of bullets to leave in the background as a summary while I take questions. Overall the slides should complement the talk, not be a duplicate. But they serve a second function of reminding me of all the things I need to say.
As a programmer you will appreciate the reason for this: I have cut the number of entities I have to process in my head from three (slides, audience, notes) to two (slides, audience). Keeping track of and having rapport with the audience is essential to me, even if that just means looking at people to see how engaged they are. With notes/memory in the equation I used to get a lot more nervous and not pay enough attention to the audience. Cutting out the notes allows me to focus on communicating better. It's a shared context, the audience can see exactly[1] what I can see.
If you're in sales then I see another tactic used instead, which is to memorize the talk so thoroughly that you don't need notes or presenter view. Fair enough. I'm an academic researcher; while they say all our presentations are a sales pitch on some level or other they clearly aren't expected to be as slick as "sales" sales. My constraints are having limited time to prepare, and wanting to stay natural. I do rehearse but I don't over-rehearse as I find that kills my own interest in the talk as well as taking more time. Usually the minimum for me is two full run throughs, probably stopping the clock multiple times during each to apply edits as I see fit (hopefully only a few edits second time).
HANDLING CONTEXT SWITCHES
The one exception to [1] is context switches. As others have said, finding the perfect words for the introduction to each new topic really helps get the flow going. These can be remembered, written on notes, written on slides, written on slide notes visible in presenter view, whatever.
I'm a big fan of presenter view, not for notes, but purely for the ability to see the next slide and introduce it slightly before the change. It helps to leave each slide knowing what direction you're going in so you're not surprised by the next one. I do worry slightly that I'm dependent on presenter view and turn up early at each venue to make sure I can get it working (not all of them can).
NERVES
Someone said don't drink too much alcohol. Based on my experience as a performing musician this is true :) Same goes for caffeine for the opposite reason, it really heightens the nerves. On the subject of nerves, just accept that some talks seem to go better than others. If you find yourself having a failure of confidence, take a deep breath and keep going. Easier said than done I know, but it always feels worse on the inside than it really looks; I have had people come up to me after talks where I thought I did awfully and tell me how engaging they found it.
AUDIENCE ENGAGEMENT
If you can find a way to further engage the audience without forcing it - quiz questions, polls etc - go for it. Quiz questions can help set context for a new topic. Despite my love of the material I've never really been a lover of talks and can get pretty bored in the audience, so I really appreciate this sort of thing.
Example: on a few of my talks lately I've showed a picture of some protestors up trees by a road, asking who can name the incident. (P...
> If you're in sales then I see another tactic used instead, which is to memorize the talk
Majority of my talks in the last years have been in academic settings, but I'm definitely on the side of "over-rehearsing" on your scale. I've never done a sales talk in my life.
I guess it depends on how well you can improvise on stage. I never managed to master that. For myself, I can only "stay natural" and not be nervous when I'm well prepared.
> quiz questions, polls
I personally don't like this when listening and rarely do it as a speaker. It can be a double-edged sword. I've often seen speakers fall into the trap of asking "how many of you are familiar with X", and then proceed to spend next 10 minutes explaining X even though it's obvious that the audience already knows X very well. If you're asking questions, you should be prepared to act on the answers.
Fair enough, there is diversity of preferences in both speakers and listeners :)
I agree on familiarity polls that you should adapt content based on audience familiarity with the topic.
Whether or not audience engagement is appropriate also depends a bit on the length of the talk. It can be great for a context switch in a 45 minute talk, like a mental reset button for the audience. If you only have 5 minutes it will detract from things unless you want it to be the main focus.
I would argue that the slides are there for the audience. Ideally, you need to be able to present your talk without seeing your slides. They are not cue cards for the speaker.
I would argue the exact opposite. I think you should desire to be able to do your talk without seeing your slides, because the goal should be to do the talk without slides at all. You want the audience focused on you and what you're saying, IMO. Slides are a (sometimes) necessary evil just to help keep the talk on track.
Much of the time, there's a machine already there ready to go. If that's the case, probably best to use it.
Seems to me that these days, the safest way to handle your slides is to have them on the web, with a backup on a USB drive. No need to worry about operating systems or video modes. The site's IT guys already did the work.
There are various shiny frameworks to do this (revealJS.com et al), but even PowerPoint presentations can be viewed in-browser, with OneDrive.
> prevent reading the slides out loud
Good advice.
> Use images and videos, they can tell more then a thousand words.
Indeed. This hints at another good 'rule': avoid wordy slides. Let your talk itself be the wordy bit. The slides just support.
> Also, relax, the audience has already decided they want to listen to your presentation.
>Always do at least 1 full rehearsal with a timer, preferably two full rehearsals where the first one you do keep a timer but also have a notebook (physical) present to quickly write down adjustments you want to make.
two are still too few IMO (I'm not a native speaker but still). I like to do at least ~5, where I can get a feel for the sentences I'll pick for transitions (like some sort of theater play) so should I get stuck somewhere I know how to transition to the next talking point/topic.
>Do not use a linux machine,
eh, my experience with linux machines was mostly positive, what I can recommend though is to have the slides ready (4:3 and 16:9 aspect ratio) in the cloud as a "safety net"
So, if I understand gnur's meaning, you present a situation you were in, what task (or target) you were attempting to achieve, the actions you took, and the results.
"The website suddenly went down as traffic increased. I needed to find out which backend service was becoming overloaded and triggering the failure. I quickly deployed and configured WhizBangMicroservicesAnalyzer, and used it to assess the current status of our various backend microservices. It detected that our caching servers were running out of RAM due to a misconfiguration causing them to hit a corner case. I was able to fix the configuration error and bring the website back online."
One thing that tends to trip me up is people's different abilities to parse graphics and texts.
Physicists are so used to looking at plots most of us are really good at interpreting them. But this is a hard-earned skill. If I talk to the general public I have to take great care in keeping plots and graphics really really simple.
I hear the humanities have similar issues with text. So whatever your background is, tailor not just your content and language to the audience but the visual language as well.
The do not use a Linux machine advice is funny. I have been using my Linux machine forever for presentations and only once I got an issue because I switched to KDE and forgot to have kscreen installed. Once in like 7 years. I see much more often people with Macs who cant project anything because they dont have the right adapter to begin with.
> I see much more often people with Macs who cant project anything because they dont have the right adapter to begin with.
Yes, as a regular Linux user I've never had major issues with presentations from Linux, but I've seen Mac users stumble many times for this exact reason.
If possible, have multiple output options built into your laptop. I have both HDMI and VGA on my current laptop and this has proved quite useful over the past few years.
> have both HDMI and VGA on my current laptop and this has proved quite useful over the past few years.
Agree. I have VGA and DP, and VGA is a life saver sometimes when you are at a venue that has only analog input. And frankly, VGA works very nicely for projecting static images anyway, which is what most presentations do.
I have done a lot of presentations over the years, and to the best of my recollection, every single one has been done using a Linux machine, and this has mostly been a non issue.
I think a better adage might be "get there early so you have time to deal with technical issues, bring any potentially required adapters, and have your presentation on a thumb-drive in case you need to borrow someone else's machine to present in a pinch." I say, "on a thumb drive" as opposed to "in Dropbox" or whatever, because you may rarely find yourself in a position of not having net access in the location of the talk.
> Always do at least 1 full rehearsal with a timer, preferably two full rehearsals
Personally, for me to feel very comfortable in delivering the talk, I practice the whole presentation at least five, six times.
The first couple of those practice runs, I tend to adjust the slides and my talk, to iron out the wrinkles in either my slides, my words or the transitions/logic between the slides.
The latter practice runs are essentially to memorize the whole talk. I typically write out my whole speech in the speaker notes, but after two-three practice runs I don't need to look at them anymore.
The result is a presentation delivery that as an intronerd I'm very comfortable with -- even the jokes have been practiced and perfected -- and one that I could deliver practically verbatim the next day.
If you're projecting from your own laptop, shut down any apps that might give bouncing notifications. Really, just shut down all apps. And don't have your browser open with bookmarks tab and window tabs showing.
Don't spent 10 minutes on the introduction. A very common mistake is people step too slowly through the setup material. Just lay out the problem and GO. In fact, even throughout the talk, assume the audience is smart and can fill in the obvious blanks.
What do you do when the demo fails. I like to get all flustered and go down in flames but you might prefer to have a way of dealing with that eventuality.
When rehearsing record yourself (i.e. with your phone mounted on the tripod or just against something). I realized, that before that I didn't do full rehearsal, just was repeating the talk in my mind or even if speaking aloud - I was sitting instead of standing, had lots of interruptions, etc.
Then watch the recording. It's painful, but worth it.
Observe your body language. Try to face the audience, not sit or stand with your back towards them to read the slides. Move a little bit, don't just stand there.
This. When rehearsing in your head, it's easy to gloss over parts that really need some working. When treating it as a proper presentation, those spots are painfully obvious. Better to find them alone, even if watching yourself is a bit awkward.
I also like to record myself because sometimes I find a good way to explain something, which I want to remember and explain the same way during my talk. It also helps with pacing. Am I too slow or too fast?
- Ask yourself what is your real goal of the talk. Are you trying to teach people something? Or are you making a live-action advertisement for a product/service (or for yourself)? Optimize your talk ruthlessly for that goal.
- If you're doing a talk in front of a small audience (say, 30 or less people), and you're going to discuss details of code or charts presented on slides, then put all those code snippets and charts you want to discuss in a single document and give everyone a printout. A printed document has much higher resolution and quality than a slide (especially for the people sitting in the back), and will allow them to look back (or forward) at an important figure if you're currently showing another slide. Paper is cheap and quite ecological, so don't worry about that.
173 comments
[ 9.6 ms ] story [ 470 ms ] threadI also recommend a fantastic book on the topic by head of TED conferences, Chris Anderson - "The Official TED Guide to Public Speaking". It helped me immensely when I was preparing to my first big public speaking event.
Remember to pause and speak slower. It gives the impression you are really considering what you are about to say next and allows you a break.
Don't drink alcohol before the talk (unless you need a shot to calm your nerves) and do have a bottle of water available as your mouth will most likely become dry.
Lastly relax. The audience is unlikely to call you out unless you make a total hash of it and they usually want you to succeed.
Great insight, and I've found that to be true. Most of the time, they selected your talk based on their interest in the contents (and less so on your delivery), and so they want to learn a thing or two. They will be graceful towards your presentation (style, delivery, slides) if at the end they got what they came for: you sharing data, knowledge, insights or wisdom. You don't want that too difficult for them, so you should work hard on improving your presentation delivery, but sharing knowledge is appreciated over sharing jokes or just well-designed slides.
You know when you were a kid, and you had that one funny relative who'd always tell great stories? Be that relative.
Some people are good at wrapping tech talks into interesting stories. But they are very rare in my experience. If you don't have a story to tell, don't force it. Don't try to present everything as this grand idea that's related to everything you've done since childhood. It gets old really fast.
I've seen students take a course in speaking where they hammer into them this "three act structure". Invariably, the talks they give would be much better if they would just stick to the technology.
Another thing is, tech talks tend to be as dry as the Sahara desert. So try to make your talk interesting. Do not just focus on getting the information across, but make it fun to listen.
Practice your talk without slides. This has two benefits: You concentrate on the content, so your stuff by heart at the end. And you don't depend on the slides, in case something goes wrong.
Lastly, prepare for 4:3 - even if they say you get a 16:9 beamer, chances are it's not. And prepare for offline, your Laptop being broken and in case you are doing a live demo: Have a video of it as a backup.
These tips are all just from my experience and may not apply to you, but maybe it's helpful. :)
I find it helpful to go train the whole talk with a metronome (at a slowish tempo) to have an upper bound on how much time the talk will take.
If you write slides with bulletpoints and read them, then er, just, don't.
get there very early and check that the tech is sorted.
have a short list of explicit goals - feel free to write them out.
practice at least once, for real, out loud. If no one will help, present the talk to a stuffed bear.
do not read your slides to the audience.
expect live demos to fail - have a practiced contingency plan.
no lewd illustrations and don't put people down - you are in a position of responsibility.
at the end, sum up.
This was the biggest change between the presentations I had to give in high school and the ones in college and above. In high school, the topic was usually given to us, whereas in college and later, I got to choose the topic I was most knowledgeable about. The latter meant I was more passionate, more able to answer audience questions and more able to tailor the delivery to the audience.
One piece of advice I heard was that if you absolutely have to talk about a topic you're not familiar with, talk about being a beginner in that topic. Talk about your perspective as an outsider learning that topic in the first place.
Are you an expert or a beginner relative to your audience? If I'm explaining something technical, I might take a more assertive tone when glossing over details with a novice but speak with more deference to an expert. (e.g. Throw in a few "I think ..." or "My understanding was that ...")
Getting a quick grasp of where the speaker is coming from helps the listener really engage at the right level. Should I double check what the speaker is saying or are they the authority on the matter? Nothing get's eyes rolling faster than someone making blatantly wrong factual errors overconfidently.
Use this ance-data to shape your tone and phrasing.
Do a live demo, people love live demo's, but be prepared for when disaster strikes (it will), if possible run your live demo on a physical device with you during the presentation.
Most places allow you to have 2 devices connected, or quickly switch the HDMI cable to the demo machine.
Do not use a linux machine, I know this sounds harsh, but with all the types of beamers/screens out there, a windows or mac machine will just have a much higher success rate. (I learnt this the hard way, in the end I could choose between mirrored 640*480 or full hd on the beamer only, which makes live demos much harder).
Create short slides, the slides are there to guide you and the audience. Try to prevent reading the slides out loud.
Use images and videos, they can tell more then a thousand words.
I often use the STAR approach to tell my story, this helps structure your talk. You don't need to follow star exactly, but if trying to explain something, it often helps to first give a bit of background why you did what you did.
Make sure you let the audience know if and when you will be answering questions, some talks really benefit from interactivity, but if you are short on time, let people know they can ask their questions later (perhaps add a slide at the end with sources and your contact information).
Also, relax, the audience has already decided they want to listen to your presentation.
It really depends on the topic of the talk. If it's something that can be demonstrated in a quick and straightforward way, do a demo by all means. But I've seen talks where people were forcing a demo into a talk about complicated concepts. There's little value in seeing someone type in a page of code, compile and run. Or seeing something run without understanding what is happening on screen. I would much rather have the speaker spend those minutes discussing the topic.
> Do not use a linux machine
Better advice: make sure you know how to setup an external screen on your laptop and how your presentation software works with it. Try it before hand with an old VGA monitor.
> Create short slides, the slides are there to guide you and the audience. Try to prevent reading the slides out loud.
I would argue that the slides are there for the audience. Ideally, you need to be able to present your talk without seeing your slides. They are not cue cards for the speaker.
Very short slides light on content (e.g. memes, one word or sentence per slide) make for a terrible tech talk in my opinion. Do make your slides informative. They should complement what you are talking about. Show a relevant graph, code snippet, etc. related to what you are talking about. If you can't do that, fall back to a summary of your spoken content in a 3-4 bullet points per slide.
STYLE
> [slides] are not cue cards for the speaker
Personally I disagree with this point and have developed a presentation style I'm happy with based on the slides being my cue cards (average 5-10 presentations / year for the last 15 years).
I do NOT read the talk from my slides and can't stand it when speakers do that! But, each slide should jog my memory of everything I need to say at that point. Maybe I'm talking about some stats as background, fine, the slide should be a bar chart of those stats, or a map, or an illustrative photo. Rarely a list of bullet points, though I don't prohibit them altogether and will tend to conclude with a list of bullets to leave in the background as a summary while I take questions. Overall the slides should complement the talk, not be a duplicate. But they serve a second function of reminding me of all the things I need to say.
As a programmer you will appreciate the reason for this: I have cut the number of entities I have to process in my head from three (slides, audience, notes) to two (slides, audience). Keeping track of and having rapport with the audience is essential to me, even if that just means looking at people to see how engaged they are. With notes/memory in the equation I used to get a lot more nervous and not pay enough attention to the audience. Cutting out the notes allows me to focus on communicating better. It's a shared context, the audience can see exactly[1] what I can see.
If you're in sales then I see another tactic used instead, which is to memorize the talk so thoroughly that you don't need notes or presenter view. Fair enough. I'm an academic researcher; while they say all our presentations are a sales pitch on some level or other they clearly aren't expected to be as slick as "sales" sales. My constraints are having limited time to prepare, and wanting to stay natural. I do rehearse but I don't over-rehearse as I find that kills my own interest in the talk as well as taking more time. Usually the minimum for me is two full run throughs, probably stopping the clock multiple times during each to apply edits as I see fit (hopefully only a few edits second time).
HANDLING CONTEXT SWITCHES
The one exception to [1] is context switches. As others have said, finding the perfect words for the introduction to each new topic really helps get the flow going. These can be remembered, written on notes, written on slides, written on slide notes visible in presenter view, whatever.
I'm a big fan of presenter view, not for notes, but purely for the ability to see the next slide and introduce it slightly before the change. It helps to leave each slide knowing what direction you're going in so you're not surprised by the next one. I do worry slightly that I'm dependent on presenter view and turn up early at each venue to make sure I can get it working (not all of them can).
NERVES
Someone said don't drink too much alcohol. Based on my experience as a performing musician this is true :) Same goes for caffeine for the opposite reason, it really heightens the nerves. On the subject of nerves, just accept that some talks seem to go better than others. If you find yourself having a failure of confidence, take a deep breath and keep going. Easier said than done I know, but it always feels worse on the inside than it really looks; I have had people come up to me after talks where I thought I did awfully and tell me how engaging they found it.
AUDIENCE ENGAGEMENT
If you can find a way to further engage the audience without forcing it - quiz questions, polls etc - go for it. Quiz questions can help set context for a new topic. Despite my love of the material I've never really been a lover of talks and can get pretty bored in the audience, so I really appreciate this sort of thing.
Example: on a few of my talks lately I've showed a picture of some protestors up trees by a road, asking who can name the incident. (P...
Majority of my talks in the last years have been in academic settings, but I'm definitely on the side of "over-rehearsing" on your scale. I've never done a sales talk in my life.
I guess it depends on how well you can improvise on stage. I never managed to master that. For myself, I can only "stay natural" and not be nervous when I'm well prepared.
> quiz questions, polls
I personally don't like this when listening and rarely do it as a speaker. It can be a double-edged sword. I've often seen speakers fall into the trap of asking "how many of you are familiar with X", and then proceed to spend next 10 minutes explaining X even though it's obvious that the audience already knows X very well. If you're asking questions, you should be prepared to act on the answers.
I agree on familiarity polls that you should adapt content based on audience familiarity with the topic.
Whether or not audience engagement is appropriate also depends a bit on the length of the talk. It can be great for a context switch in a 45 minute talk, like a mental reset button for the audience. If you only have 5 minutes it will detract from things unless you want it to be the main focus.
I would argue the exact opposite. I think you should desire to be able to do your talk without seeing your slides, because the goal should be to do the talk without slides at all. You want the audience focused on you and what you're saying, IMO. Slides are a (sometimes) necessary evil just to help keep the talk on track.
Much of the time, there's a machine already there ready to go. If that's the case, probably best to use it.
Seems to me that these days, the safest way to handle your slides is to have them on the web, with a backup on a USB drive. No need to worry about operating systems or video modes. The site's IT guys already did the work.
There are various shiny frameworks to do this (revealJS.com et al), but even PowerPoint presentations can be viewed in-browser, with OneDrive.
> prevent reading the slides out loud
Good advice.
> Use images and videos, they can tell more then a thousand words.
Indeed. This hints at another good 'rule': avoid wordy slides. Let your talk itself be the wordy bit. The slides just support.
> Also, relax, the audience has already decided they want to listen to your presentation.
Well, not always.
two are still too few IMO (I'm not a native speaker but still). I like to do at least ~5, where I can get a feel for the sentences I'll pick for transitions (like some sort of theater play) so should I get stuck somewhere I know how to transition to the next talking point/topic.
>Do not use a linux machine,
eh, my experience with linux machines was mostly positive, what I can recommend though is to have the slides ready (4:3 and 16:9 aspect ratio) in the cloud as a "safety net"
https://en.wikipedia.org/wiki/Situation,_task,_action,_resul...
So, if I understand gnur's meaning, you present a situation you were in, what task (or target) you were attempting to achieve, the actions you took, and the results.
"The website suddenly went down as traffic increased. I needed to find out which backend service was becoming overloaded and triggering the failure. I quickly deployed and configured WhizBangMicroservicesAnalyzer, and used it to assess the current status of our various backend microservices. It detected that our caching servers were running out of RAM due to a misconfiguration causing them to hit a corner case. I was able to fix the configuration error and bring the website back online."
https://en.wikipedia.org/wiki/Situation,_task,_action,_resul...
Physicists are so used to looking at plots most of us are really good at interpreting them. But this is a hard-earned skill. If I talk to the general public I have to take great care in keeping plots and graphics really really simple.
I hear the humanities have similar issues with text. So whatever your background is, tailor not just your content and language to the audience but the visual language as well.
Yes, as a regular Linux user I've never had major issues with presentations from Linux, but I've seen Mac users stumble many times for this exact reason.
If possible, have multiple output options built into your laptop. I have both HDMI and VGA on my current laptop and this has proved quite useful over the past few years.
Agree. I have VGA and DP, and VGA is a life saver sometimes when you are at a venue that has only analog input. And frankly, VGA works very nicely for projecting static images anyway, which is what most presentations do.
I'm not sure if I agree with that, in my experience they seem to fail or underwhelm about 50% of the time.
I have done a lot of presentations over the years, and to the best of my recollection, every single one has been done using a Linux machine, and this has mostly been a non issue.
I think a better adage might be "get there early so you have time to deal with technical issues, bring any potentially required adapters, and have your presentation on a thumb-drive in case you need to borrow someone else's machine to present in a pinch." I say, "on a thumb drive" as opposed to "in Dropbox" or whatever, because you may rarely find yourself in a position of not having net access in the location of the talk.
Personally, for me to feel very comfortable in delivering the talk, I practice the whole presentation at least five, six times.
The first couple of those practice runs, I tend to adjust the slides and my talk, to iron out the wrinkles in either my slides, my words or the transitions/logic between the slides.
The latter practice runs are essentially to memorize the whole talk. I typically write out my whole speech in the speaker notes, but after two-three practice runs I don't need to look at them anymore.
The result is a presentation delivery that as an intronerd I'm very comfortable with -- even the jokes have been practiced and perfected -- and one that I could deliver practically verbatim the next day.
2. Describe your approach to solving it.
In general, have something to say, know your stuff, and the rest will flow naturally.
http://blog.voxgig.com/2018/07/13/welcome-voxgig-newsletter-...
Don't spent 10 minutes on the introduction. A very common mistake is people step too slowly through the setup material. Just lay out the problem and GO. In fact, even throughout the talk, assume the audience is smart and can fill in the obvious blanks.
I also like to record myself because sometimes I find a good way to explain something, which I want to remember and explain the same way during my talk. It also helps with pacing. Am I too slow or too fast?
- Ask yourself what is your real goal of the talk. Are you trying to teach people something? Or are you making a live-action advertisement for a product/service (or for yourself)? Optimize your talk ruthlessly for that goal.
- If you're doing a talk in front of a small audience (say, 30 or less people), and you're going to discuss details of code or charts presented on slides, then put all those code snippets and charts you want to discuss in a single document and give everyone a printout. A printed document has much higher resolution and quality than a slide (especially for the people sitting in the back), and will allow them to look back (or forward) at an important figure if you're currently showing another slide. Paper is cheap and quite ecological, so don't worry about that.