Ask HN: What are the things keep in mind while giving/preparing for a tech talk?
173 comments
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.
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.
This x10. Being aware of "who" / "what" is in the room - and then (the tricky part) self-aware of how they may see you.
Use this ance-data to shape your tone and phrasing.
Use this ance-data to shape your tone and phrasing.
+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"
A little bit of stage fright is generally healthy. It shows that you care enough to be concerned and you're not getting too cocky. That's an old lesson I learned doing (of all things) middle school acting class and it's proven itself to be true over and over again.
Think about your slide and presentation style. For example, I have enormous decks for most of my talks (think like 55 slides for 30 minutes) but I burn through them very quickly, usually less than 20 seconds per slide. I came from film editing before moving to software so I approach my Powerpoints like a movie, it's just my nature. Others have really short decks that are information dense so the emphasis is on the talking part of the talk and the slides just provide a reference in the background. Others forego slides in favor of straight-up demos, which is certainly slick if you can pull it off (high risk, high reward) and need little pictorial illustration.
Use the old 5 paragraph essay rules from high school as a starting point for structuring your talk: tell you're audience what you're about to tell them (thesis, topic, core argument) and how you're going to tell them (outline), then tell them (supporting paragraphs), then tell them at the end again what you told them and how you told them (conclusion, restating your intro).
Humor helps, generally. This isn't supposed to be a standup set so definitely don't go overboard, but it can really help. Particularly if you can tie it in with some empathy for your audience. ("We're gonna do this in Perl. I love writing Perl, you just hold shift and smash the number row for awhile.")
And for heaven's sake don't read your slides.
Think about your slide and presentation style. For example, I have enormous decks for most of my talks (think like 55 slides for 30 minutes) but I burn through them very quickly, usually less than 20 seconds per slide. I came from film editing before moving to software so I approach my Powerpoints like a movie, it's just my nature. Others have really short decks that are information dense so the emphasis is on the talking part of the talk and the slides just provide a reference in the background. Others forego slides in favor of straight-up demos, which is certainly slick if you can pull it off (high risk, high reward) and need little pictorial illustration.
Use the old 5 paragraph essay rules from high school as a starting point for structuring your talk: tell you're audience what you're about to tell them (thesis, topic, core argument) and how you're going to tell them (outline), then tell them (supporting paragraphs), then tell them at the end again what you told them and how you told them (conclusion, restating your intro).
Humor helps, generally. This isn't supposed to be a standup set so definitely don't go overboard, but it can really help. Particularly if you can tie it in with some empathy for your audience. ("We're gonna do this in Perl. I love writing Perl, you just hold shift and smash the number row for awhile.")
And for heaven's sake don't read your slides.
When the slides contain a lot of text, it is not possible for me to simultaneously read and comprehend the slide and understand what the speaker is saying. The slide appears, I start reading. You start talking, so I have to decide where my attention goes. Often it is neither the slides nor the speaker, just a jumble of words coming at me. Then the next slide comes up...
I feel like the solution to this is to have slides without a lot of text on them, but then include what you say in the "speaker notes" section when you distribute them so that people who didn't attend the talk understand them.
I think the 5 steps is too "high school" and overrated for the adult world. Sometimes there is no time nor audience patience for cliches like "how you're going to tell them" and "how you told them". Intro, content, what's next. That's all that matters.
That's why I said "as a starting point."
The five paragraph form itself is a beginner's tool: any good essay will deviate.
However, one nugget to borrow from the five paragraph form is the centrality of the thesis statement. Having a thesis for your talk is _crucial_ IMO. It doesn't have to explicitly stated, and it could be as simple as "I'm going to convince you that $FEATURE is awesome," but you need a focal point. You could restate what I'm saying here as honing your elevator pitch for you talk or in any number of different phrasings, but the idea is the same: a short statement that sums up the absolute core idea of your talk and provides a focus for you and your audience. Anything that doesn't fit your thesis is a good candidate for trimming.
The five paragraph form itself is a beginner's tool: any good essay will deviate.
However, one nugget to borrow from the five paragraph form is the centrality of the thesis statement. Having a thesis for your talk is _crucial_ IMO. It doesn't have to explicitly stated, and it could be as simple as "I'm going to convince you that $FEATURE is awesome," but you need a focal point. You could restate what I'm saying here as honing your elevator pitch for you talk or in any number of different phrasings, but the idea is the same: a short statement that sums up the absolute core idea of your talk and provides a focus for you and your audience. Anything that doesn't fit your thesis is a good candidate for trimming.
This is a good resource about how do better slides:
http://presentationzen.blogs.com/presentationzen/2006/01/con...
http://presentationzen.blogs.com/presentationzen/2006/01/con...
There's really nothing wrong to read your slides. The trick is coming up with more explanations.
Everything is wrong with reading your slides. Really...don't do it. In fact, your slides shouldn't have much text at all, because it's a distraction from where your audience should be placing their attention: You.
Ideally, you should never need to look at your slides while giving a talk. Every time you turn away from your audience, you lose a little of their attention.
Ideally, you should never need to look at your slides while giving a talk. Every time you turn away from your audience, you lose a little of their attention.
That's way overstated. Just don't only read your slides verbatim. Some people may not be able to see slides because of obstruction or their vision, so repeating key points is almost a courtesy.
I appreciate it when a slide is a visual piece with limited text, and the notes are roughly true to the spoken portion (for when slides are distributed after a talk).
I appreciate it when a slide is a visual piece with limited text, and the notes are roughly true to the spoken portion (for when slides are distributed after a talk).
It really isn't. Your goal should be to have no text, and never look away from your audience during a talk.
You can (and should) repeat key points, but every time you read, you lose your audience. And yes, you can have a little bit of text -- but since most people go too far in the other direction, it's best to aim to eliminate text entirely.
Slides should be simple graphical content to provide signposts and communicate things that otherwise cannot be expressed vocally.
You can (and should) repeat key points, but every time you read, you lose your audience. And yes, you can have a little bit of text -- but since most people go too far in the other direction, it's best to aim to eliminate text entirely.
Slides should be simple graphical content to provide signposts and communicate things that otherwise cannot be expressed vocally.
I think you're overshooting in your advice in the service of preventing the bigger mistake of turning around and reading slide contents verbatim (on which I certain agree with you). That's fine, but for veteran presenters, I think your advice is wrong. First, you should have text because you lose your audience no matter what (sneezing, emails, bathroom, etc). You should let them recontextualize and that involves judicious use of text. Also, everyone asks for slide decks after talks and they should be useful in that case even without a recording. Lastly reading doesn't mean, "turn away from your audience and read", it is the same as repeating key points - this can be done for emphasis or pacing, as long as it's intentional. This is my opinion based on my experience, at least.
"Also, everyone asks for slide decks after talks and they should be useful in that case even without a recording"
I am happy to provide copies of my slides, but no, I am under no obligation to make them useful without me presenting them. They're my tools, not your reference.
IMO, this expectation has been driven by bad presenters leading people to believe they can get the same content without bothering to show up to the talk. Maybe that's true, but if it is, you should wonder why you're giving the talk at all.
I am happy to provide copies of my slides, but no, I am under no obligation to make them useful without me presenting them. They're my tools, not your reference.
IMO, this expectation has been driven by bad presenters leading people to believe they can get the same content without bothering to show up to the talk. Maybe that's true, but if it is, you should wonder why you're giving the talk at all.
If your slide contains a picture, whose details you're describing (say for instance a medical photo or city zoning plan or something), certainly you want your audience's visual attention on it as you're describing its pertinent specifics.
Are we actually talking about tech talk?
I can understand marketing talks where all you need is you and your words, accompanied with some useless images.
It would be an utter waste of time if a tech talk turned up like that.
I can understand marketing talks where all you need is you and your words, accompanied with some useless images.
It would be an utter waste of time if a tech talk turned up like that.
Smart people always vastly overestimate the technical interest level of their audience. Even in audiences composed exclusively of brilliant, technical people, the average level of commitment to whatever you're saying is damned near zero. Accordingly, you must keep your message exceedingly simple. Thinking is hard for everyone, and you have to persuade people to do it. It doesn't come for free.
You may not like "marketing", but you're giving a talk to sell a vision. Always. Once you win people over, they'll seek out the details for themselves.
You may not like "marketing", but you're giving a talk to sell a vision. Always. Once you win people over, they'll seek out the details for themselves.
That's why more and more talks are simply bullshit.
No I afraid it is not - the fact that its about "technology" does not really change the talk that much when compared to speeches in the roman senate.
You still use the same rhetorical devices and ethos pathos and logos.
You still use the same rhetorical devices and ethos pathos and logos.
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.
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.
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.
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.
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.
> Do a live demo, people love live demo's
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.
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.
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.
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.
Edit: added headings!
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. (Protests vs Newbury bypass construction). Followed by more protestors and an airstrip (former US nuclear base Greenham Common). Most of my UK audiences will get these right. Finally I asked what links these two things. They may or may not get the latter: the success of commercial development on Greenham Common, when it ceased to operate as an airbase, was blamed for the failure of transport models to correctly predict the effect of Newbury bypass. Doesn't matter whether anyone guessed the final answer, which is obviously a bit specialist. The point is I've now got people thinking about the many interconnected elements of simulating transport which is a great intro to the topic.
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. (Protests vs Newbury bypass construction). Followed by more protestors and an airstrip (former US nuclear base Greenham Common). Most of my UK audiences will get these right. Finally I asked what links these two things. They may or may not get the latter: the success of commercial development on Greenham Common, when it ceased to operate as an airbase, was blamed for the failure of transport models to correctly predict the effect of Newbury bypass. Doesn't matter whether anyone guessed the final answer, which is obviously a bit specialist. The point is I've now got people thinking about the many interconnected elements of simulating transport which is a great intro to the topic.
> 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.
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 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.
> Do not use a linux machine
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.
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.
This is also what I like to do although I prefer using static PDFs because they are the most portable and fool proof format
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.
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.
STAR: Situation, task, action, results
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...
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."
>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"
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"
> 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.
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.
Do not use a linux machine
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.
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.
For anyone guessing at what STAR meant:
https://en.wikipedia.org/wiki/Situation,_task,_action,_resul...
For anyone guessing at what STAR meant, I suspect it's the following. It seems to be about interviewing but It seems to apply.
https://en.wikipedia.org/wiki/Situation,_task,_action,_resul...
https://en.wikipedia.org/wiki/Situation,_task,_action,_resul...
Can you elaborate a bit more on the STAR approach? A link, perhaps, on how to use it when giving a talk?
> Do a live demo, people love live demo's
I'm not sure if I agree with that, in my experience they seem to fail or underwhelm about 50% of the time.
I'm not sure if I agree with that, in my experience they seem to fail or underwhelm about 50% of the time.
People decide in the first 10 seconds whether they're going to listen to you or use your session to catch up on email. So make your intro good. Catch their attention. Surprise and intrigue them. Memorize and practise your intro over and over again so when you walk on stage you can get comfortable without having to worry about the specific words you're saying. Memorize your conclusion too so you can bring it home with a strong call to action (bonus points if you tie it back to your intro!). People remember the first and last things you say the most, so make those words count.
I always dislike this advice because
1. I simply don't think its true - there have been many talks where I have become interested 10 minutes in.
2. It puts tremendous pressure on the speaker for some kind of fireworks in their first 10 seconds.
Your 10 seconds went badly? Who cares just make sure the next 10 seconds are interesting, or the next.
1. I simply don't think its true - there have been many talks where I have become interested 10 minutes in.
2. It puts tremendous pressure on the speaker for some kind of fireworks in their first 10 seconds.
Your 10 seconds went badly? Who cares just make sure the next 10 seconds are interesting, or the next.
The advice is very actionable, and it is something that can be practiced. As far as advice goes, I'd consider it fairly well thought out.
As far as its actual effectiveness, it doesn't seem meaningful to involk anecdotal data (i.e. "I've seen counter examples") as the parent post isn't stating that you must, but rather it's a generally good idea or a hack.
Given the data around interviewers making pass/reject decisions within the first few minutes of an interview, I would find it surprising if it wasn't true.
As far as its actual effectiveness, it doesn't seem meaningful to involk anecdotal data (i.e. "I've seen counter examples") as the parent post isn't stating that you must, but rather it's a generally good idea or a hack.
Given the data around interviewers making pass/reject decisions within the first few minutes of an interview, I would find it surprising if it wasn't true.
Given the data around interviewers making pass/reject decisions within the first few minutes of an interview, I would find it surprising if it wasn't true.
This is ludicrous, given that an interview and a tech talk are completely different things. In particular, an interviewer doesn't generally expect or hope to learn anything useful during an interview. That difference alone makes the situations not comparable.
it doesn't seem meaningful to involk anecdotal data
That anecdote is the only bit of data at hand. The comparison to interviews is mere wild speculation.
This is ludicrous, given that an interview and a tech talk are completely different things. In particular, an interviewer doesn't generally expect or hope to learn anything useful during an interview. That difference alone makes the situations not comparable.
it doesn't seem meaningful to involk anecdotal data
That anecdote is the only bit of data at hand. The comparison to interviews is mere wild speculation.
> In particular, an interviewer doesn't generally expect or hope to learn anything useful during an interview.
Really? then why are they always asking questions? :p
Really? then why are they always asking questions? :p
I agree. I think better (and much more easily actionable) advice is just to make sure that your first 30 seconds include a clear description of what your talk is about and what kind of conclusion you're going to draw. Long rambling intros do put people off pretty quickly. But I'll still keep listening to a relatively flat, unexciting intro if it's giving me useful information about the rest of the talk.
I like it, maybe for some other reason though. But as a presenter, I'm very nervous the first minute. If I know it by heart, I can recite it while finding my flow and calming down.
It's known as the 'James Bond intro', where basically you invert the well worn intro, method, exciting results formula by putting the sexiest part first, just like how James Bond/many action films these days start with a thrilling intro. In my experience it can work well - the audience immediately grasp the point for sitting through any challenging content, safe in the knowledge the outcome is rewarding. Also if you return to it later there's a reinforcement element. Of course it relies either on having eye candy or results that are or can be competently portrayed as being amazing.
The effect is supposedly about lighting up the reptilian brain, and you can drop further limbic system boosts throughout your talk to raise arousal level (heart rate, adrenaline) of your audience, which supposedly keeps their interest high. I learnt this on a demo course, perhaps it's just obvious didactic technique.
I should add it's obviously high stakes but can really make your talk stand out, especially if your talk is within a series of conventionally structured talks.
The effect is supposedly about lighting up the reptilian brain, and you can drop further limbic system boosts throughout your talk to raise arousal level (heart rate, adrenaline) of your audience, which supposedly keeps their interest high. I learnt this on a demo course, perhaps it's just obvious didactic technique.
I should add it's obviously high stakes but can really make your talk stand out, especially if your talk is within a series of conventionally structured talks.
Are Lasers Killing Babies In Space? (pause for the remainder of the 10 seconds) Hi, I'm here to talk to you about LinkedIn's new social networking features!
Silence is incredibly powerful. This would grab my attention.
I learned how to speak in public by giving classes to auditoriums full of Marines. I absolutely attest to the "start with an attention grabber" method.
Somewhat off topic: I always wondered why people would bother showing up for a talk or conference if they're going to be on their phone or laptop during the entire thing.
Last time I went to a conference I was actually a little surprised by the number of people at the talks who where clearly working during the entire thing. Why bother, you most likely pay for the plane ticket, the hotel and the conference it self, and then not pay attention? If you're only interested in one talk, then just go to that one and then leave.
Given that people mostly show up to technical talks of their own free will, I don't think you need to trick them into paying attention. It's fair to assume that they are generally interested and focused on what you have to say.
Last time I went to a conference I was actually a little surprised by the number of people at the talks who where clearly working during the entire thing. Why bother, you most likely pay for the plane ticket, the hotel and the conference it self, and then not pay attention? If you're only interested in one talk, then just go to that one and then leave.
Given that people mostly show up to technical talks of their own free will, I don't think you need to trick them into paying attention. It's fair to assume that they are generally interested and focused on what you have to say.
Some people get paid to go to the conference and also for some its in their best interest to half pay attention while doing work.
On another level, sometimes I go to meetups in my area which are technically the same conference presentation as well. There are times when I regret going to the meetup (There's 10-20 people) because of how boring the speaker is or how overly technical it becomes, but I don't want to be rude and leave the area cause it'd reflect poorly. Its not like a convention where leaving is okay, everyone in the area knows each other.
On another level, sometimes I go to meetups in my area which are technically the same conference presentation as well. There are times when I regret going to the meetup (There's 10-20 people) because of how boring the speaker is or how overly technical it becomes, but I don't want to be rude and leave the area cause it'd reflect poorly. Its not like a convention where leaving is okay, everyone in the area knows each other.
For me anyway it's simple: I go to the talk because I think it's going to be interesting. If it turns out to be boring, but I feel like the speaker is making a real effort, I will stay and try to multitask my way through it, partly just in case something interesting comes up but mostly out of respect for the speaker... who after all is making a real effort.
If I feel like the speaker is just lazy then I'll get up and go somewhere else.
Note that this only works above a certain size: if it's happening in a conference room I will at least pretend to take notes on paper instead of reading email / HN / bugs / etc.
I'm not really sure whether this makes me more considerate, or more duplicitous, or maybe both.
If I feel like the speaker is just lazy then I'll get up and go somewhere else.
Note that this only works above a certain size: if it's happening in a conference room I will at least pretend to take notes on paper instead of reading email / HN / bugs / etc.
I'm not really sure whether this makes me more considerate, or more duplicitous, or maybe both.
I've done it. Sometimes you go to a 20 minute talk because the premise was interesting, but it's different from what you thought or too arcane, or the presenter has an accent you cannot understand, and it's too late to look up the program to attend another talk you might have attended instead. So you just pop up the laptop and check email. Why not?
>I always wondered why people would bother showing up for a talk or conference if they're going to be on their phone or laptop during the entire thing.
Nearly all of the interesting things at conferences happen between the talk sessions. Usually, at a bar. Usually, at about 11 o’clock at night. The reason is a lot of people go to conferences has everything to do with networking, and politics. Sometimes, they actually go to talks too.
Nearly all of the interesting things at conferences happen between the talk sessions. Usually, at a bar. Usually, at about 11 o’clock at night. The reason is a lot of people go to conferences has everything to do with networking, and politics. Sometimes, they actually go to talks too.
The conferences I pay attention to are the conferences that are in areas I'm pretty weak in because all of the concepts are ill-defined in my mind so I need to work to understand the overall point of the talk.
For topics I'm familiar with, however, I find most talks too simple so I might as well get work done while vaguely listening. Ideally the talk would get more complex, but it usually doesn't.
For topics I'm familiar with, however, I find most talks too simple so I might as well get work done while vaguely listening. Ideally the talk would get more complex, but it usually doesn't.
The real part of the conference is the bit in between the talks.
(Fun fact, the first conference I went to had like five coffee breaks per day, and I got a coffee at every break and complained to someone at dinner that there was too much coffee and not enough talking. They explained it to me quickly enough!)
(Fun fact, the first conference I went to had like five coffee breaks per day, and I got a coffee at every break and complained to someone at dinner that there was too much coffee and not enough talking. They explained it to me quickly enough!)
Lots of good advice here. I'd add:
- 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.
- 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.
From Richard Hamming:
When I first started, I got practically physically ill while giving a speech, and I was very, very nervous. I realized I either had to learn to give speeches smoothly or I would essentially partially cripple my whole career. The first time IBM asked me to give a speech in New York one evening, I decided I was going to give a really good speech, a speech that was wanted, not a technical one but a broad one, and at the end if they liked it, I'd quietly say, ``Any time you want one I'll come in and give you one.'' As a result, I got a great deal of practice giving speeches to a limited audience and I got over being afraid. Furthermore, I could also then study what methods were effective and what were ineffective.
While going to meetings I had already been studying why some papers are remembered and most are not. The technical person wants to give a highly limited technical talk. Most of the time the audience wants a broad general talk and wants much more survey and background than the speaker is willing to give. As a result, many talks are ineffective. The speaker names a topic and suddenly plunges into the details he's solved. Few people in the audience may follow. You should paint a general picture to say why it's important, and then slowly give a sketch of what was done. Then a larger number of people will say, ``Yes, Joe has done that,'' or ``Mary has done that; I really see where it is; yes, Mary really gave a good talk; I understand what Mary has done.'' The tendency is to give a highly restricted, safe talk; this is usually ineffective. Furthermore, many talks are filled with far too much information. So I say this idea of selling is obvious.
http://www.cs.virginia.edu/~robins/YouAndYourResearch.html
When I first started, I got practically physically ill while giving a speech, and I was very, very nervous. I realized I either had to learn to give speeches smoothly or I would essentially partially cripple my whole career. The first time IBM asked me to give a speech in New York one evening, I decided I was going to give a really good speech, a speech that was wanted, not a technical one but a broad one, and at the end if they liked it, I'd quietly say, ``Any time you want one I'll come in and give you one.'' As a result, I got a great deal of practice giving speeches to a limited audience and I got over being afraid. Furthermore, I could also then study what methods were effective and what were ineffective.
While going to meetings I had already been studying why some papers are remembered and most are not. The technical person wants to give a highly limited technical talk. Most of the time the audience wants a broad general talk and wants much more survey and background than the speaker is willing to give. As a result, many talks are ineffective. The speaker names a topic and suddenly plunges into the details he's solved. Few people in the audience may follow. You should paint a general picture to say why it's important, and then slowly give a sketch of what was done. Then a larger number of people will say, ``Yes, Joe has done that,'' or ``Mary has done that; I really see where it is; yes, Mary really gave a good talk; I understand what Mary has done.'' The tendency is to give a highly restricted, safe talk; this is usually ineffective. Furthermore, many talks are filled with far too much information. So I say this idea of selling is obvious.
http://www.cs.virginia.edu/~robins/YouAndYourResearch.html
I have given many, many talks -- from dense technical presentations to generalized keynote addresses -- and have been doing it for over twenty years. Here, in my opinion, is the deal:
1. Don't start your talk by apologizing. "Well, first I need to apologize. I'm insanely jet lagged, and so I'm not sure how coherent this is going to be." "First, I'd like to apologize. This is actually a revised version of a talk I gave in 2009." "Let me start with an apology. I have a terrible head cold."
Just stop. If the talk is incoherent, you'll just have to do your best on the spot. If you're tired, too bad. If you think people might have trouble hearing you, say so. But don't apologize. People do this because they're nervous, not because the audience has been insulted or aggrieved in some way, and while it might seem like a friendly gesture, it's more likely to communicate that you're unprepared. Or nervous. And it's a cliche.
2. Do not ever go over time. In fact, go under time. As Edward Tufte once said, "No one ever left a presentation wishing it had gone on for another 45 minutes" (or something like that; you get the point).
3. Do not read your goddamn slides to the audience. Please. That is not "giving a talk." You can maybe do that if it's a long quote, but don't read the bullet points that everyone can clearly see right in front of them. Expand on them, provide counterpoints to them, whatever, but do not read them. If you're thinking of your slides (when you're creating them) as "what I'm going say," you're probably doing it wrong.
4. Use a laser pointer sparingly or not at all. Use it only to make a precise gesture necessary to point something out very specifically on a chart or map, and then shut the thing off. Making dizzying circles around every bullet point is incredibly annoying.
5. "Never mind the mic. Can everyone here me? I'm just going to speak loud." Unless you're very experienced with this (professional teacher, actor, or something like that), you probably don't know how to project your voice for twenty minutes. Get the mic fixed and use it. If the mic can't be fixed, speak way louder than you think you have to (without shouting). This is a learned skill, and most people don't know how to do it (but think they do). If the venue is large enough to require amplification, it's there for a reason.
6. Speak at a moderate pace. People speak fast when they're nervous. The proper pace will feel a bit slow to you, but perfectly natural to the audience. Check yourself periodically. Write it down on your notes. Slow down.
7. If some parts of the information you're trying to communicate are very dense or there's some useful data that will help to contextualize your presentation, create a handout. Do not try to cram it all into a slide.
8. Take some time to try to imagine every conceivable question you might get in the Q&A. You won't hit them all, and things do come out of left field, but you don't want to be caught totally off guard. Just review any common misconceptions or objections to what you're saying, and give some thought to how you're going to respond. Some people just want to comment. Thank them, briefly offer a comment if appropriate, and move on.
9. If you feel the need to ask a question like, "Does everyone know what a frubazzle is?" don't. If the question is warranted, then you can be absolutely sure that someone in the audience doesn't know what that is. Just say, "Some of you may not be familiar with the term, 'frubazzle.' A frubazzle is a . . ."
10. Commit to getting better and better at it. When I gave my first talk (in grad school), I thought, "It's going to be really embarrassing when I faint dead away in front of all these people," and I made a lot of mistakes. Today, I have only the slightest pang of nerves when I step up, and it goes away immediately. When you hear a good talk, try to figure what made it good. How did the speaker behave? How were the slides set up? Did they do anything that you can incorporate into your own presentation "style?" Public speaking is an ancient art, and you need to treat it as you would the art of writing or the art of coding: with care and study.
1. Don't start your talk by apologizing. "Well, first I need to apologize. I'm insanely jet lagged, and so I'm not sure how coherent this is going to be." "First, I'd like to apologize. This is actually a revised version of a talk I gave in 2009." "Let me start with an apology. I have a terrible head cold."
Just stop. If the talk is incoherent, you'll just have to do your best on the spot. If you're tired, too bad. If you think people might have trouble hearing you, say so. But don't apologize. People do this because they're nervous, not because the audience has been insulted or aggrieved in some way, and while it might seem like a friendly gesture, it's more likely to communicate that you're unprepared. Or nervous. And it's a cliche.
2. Do not ever go over time. In fact, go under time. As Edward Tufte once said, "No one ever left a presentation wishing it had gone on for another 45 minutes" (or something like that; you get the point).
3. Do not read your goddamn slides to the audience. Please. That is not "giving a talk." You can maybe do that if it's a long quote, but don't read the bullet points that everyone can clearly see right in front of them. Expand on them, provide counterpoints to them, whatever, but do not read them. If you're thinking of your slides (when you're creating them) as "what I'm going say," you're probably doing it wrong.
4. Use a laser pointer sparingly or not at all. Use it only to make a precise gesture necessary to point something out very specifically on a chart or map, and then shut the thing off. Making dizzying circles around every bullet point is incredibly annoying.
5. "Never mind the mic. Can everyone here me? I'm just going to speak loud." Unless you're very experienced with this (professional teacher, actor, or something like that), you probably don't know how to project your voice for twenty minutes. Get the mic fixed and use it. If the mic can't be fixed, speak way louder than you think you have to (without shouting). This is a learned skill, and most people don't know how to do it (but think they do). If the venue is large enough to require amplification, it's there for a reason.
6. Speak at a moderate pace. People speak fast when they're nervous. The proper pace will feel a bit slow to you, but perfectly natural to the audience. Check yourself periodically. Write it down on your notes. Slow down.
7. If some parts of the information you're trying to communicate are very dense or there's some useful data that will help to contextualize your presentation, create a handout. Do not try to cram it all into a slide.
8. Take some time to try to imagine every conceivable question you might get in the Q&A. You won't hit them all, and things do come out of left field, but you don't want to be caught totally off guard. Just review any common misconceptions or objections to what you're saying, and give some thought to how you're going to respond. Some people just want to comment. Thank them, briefly offer a comment if appropriate, and move on.
9. If you feel the need to ask a question like, "Does everyone know what a frubazzle is?" don't. If the question is warranted, then you can be absolutely sure that someone in the audience doesn't know what that is. Just say, "Some of you may not be familiar with the term, 'frubazzle.' A frubazzle is a . . ."
10. Commit to getting better and better at it. When I gave my first talk (in grad school), I thought, "It's going to be really embarrassing when I faint dead away in front of all these people," and I made a lot of mistakes. Today, I have only the slightest pang of nerves when I step up, and it goes away immediately. When you hear a good talk, try to figure what made it good. How did the speaker behave? How were the slides set up? Did they do anything that you can incorporate into your own presentation "style?" Public speaking is an ancient art, and you need to treat it as you would the art of writing or the art of coding: with care and study.
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.
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.
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.
Remember you're telling a story. Think hard, before you start with slides, what that story actually is. Continuity and flow really matter.
Usually the first part of the story of a tech talk explains what the problem is. Many tech talks fail because the audience either doesn't understand the problem, or doesn't believe your problem needs solving. Think carefully who your audience are, and ensure you explain the problem in enough detail that you connect with your audience.
The middle part of a tech talk then is usually spent on explaining your solution to the problem. If you've explained the problem well, that the outline of the solution will basically work should be reasonably self-evident. Many tech talks fail here, because they dive too deep into the details too fast. Again, know your audience, so you know how deep to dive. You can never fit all the details you have in your head into a talk, so think carefully about what the most important features of your solution are, and focus on those. Keep less important details for backup slides you can turn to if asked.
The third part is usually evidence that your solution works. Often this involves graphs. Again, focus on only the most important results - more than about three graphs and your audience will switch off. Explain the experiment, and explain what the axes represent. Way too many people don't spend enough time on this, so no matter how good the data, no-one understood.
Finally, your conclusions. What did you learn? How complete is it? What are its limitations? You're not entirely doing a sales job, and your audience are wise enough to know that your system will have limitations. You should be the one to explain them, rather than have them come out in questions (when they'll start to doubt eveything else you told them). Finally, what future directions do you think should be taken?
Of course, different talks have different shapes. Find what works for you. Sometimes you need to iterate between problem - solution - new problem - revised solution, etc.
When you present, know your first few sentences by heart, because you'll be nervous. After that, it matters less, you'll have settled into the talk, and you'll appear less stilted if you're not reciting a script. Most importantly, turn your excitement dial to 11. If the audience feel you're not excited by the work, why would they be?
Usually the first part of the story of a tech talk explains what the problem is. Many tech talks fail because the audience either doesn't understand the problem, or doesn't believe your problem needs solving. Think carefully who your audience are, and ensure you explain the problem in enough detail that you connect with your audience.
The middle part of a tech talk then is usually spent on explaining your solution to the problem. If you've explained the problem well, that the outline of the solution will basically work should be reasonably self-evident. Many tech talks fail here, because they dive too deep into the details too fast. Again, know your audience, so you know how deep to dive. You can never fit all the details you have in your head into a talk, so think carefully about what the most important features of your solution are, and focus on those. Keep less important details for backup slides you can turn to if asked.
The third part is usually evidence that your solution works. Often this involves graphs. Again, focus on only the most important results - more than about three graphs and your audience will switch off. Explain the experiment, and explain what the axes represent. Way too many people don't spend enough time on this, so no matter how good the data, no-one understood.
Finally, your conclusions. What did you learn? How complete is it? What are its limitations? You're not entirely doing a sales job, and your audience are wise enough to know that your system will have limitations. You should be the one to explain them, rather than have them come out in questions (when they'll start to doubt eveything else you told them). Finally, what future directions do you think should be taken?
Of course, different talks have different shapes. Find what works for you. Sometimes you need to iterate between problem - solution - new problem - revised solution, etc.
When you present, know your first few sentences by heart, because you'll be nervous. After that, it matters less, you'll have settled into the talk, and you'll appear less stilted if you're not reciting a script. Most importantly, turn your excitement dial to 11. If the audience feel you're not excited by the work, why would they be?
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.
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 took to the habit of logging in with a "Presentation" user, so no weird things would pop up.
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.
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.
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.
Try framing your material in the assertion-evidence [0] style. Not only does this lead to more informative presentations, I find it helps me organize my story better.
Briefly, rather than using topic titles ("Experimental Setup", "Results"), use assertions ("Sampling occurred over 5 days", "Sunlight causes significant degradation") as titles. Then the bulk of the slide is some information, preferably graphical, that supports the assertion. Reading the titles in order should give you a strong sense of the presentation content.
I strongly recommend "The Craft of Scientific Presentations" by Michael Alley, which covers the assertion-evidence approach, and a host of other practical topics.
[0] https://www.assertion-evidence.com
Briefly, rather than using topic titles ("Experimental Setup", "Results"), use assertions ("Sampling occurred over 5 days", "Sunlight causes significant degradation") as titles. Then the bulk of the slide is some information, preferably graphical, that supports the assertion. Reading the titles in order should give you a strong sense of the presentation content.
I strongly recommend "The Craft of Scientific Presentations" by Michael Alley, which covers the assertion-evidence approach, and a host of other practical topics.
[0] https://www.assertion-evidence.com
I'm also a fan of the assertion-evidence style, though I've found over the years that it works better for some talks than others. Animating in an explanation over a series of slides, for example, sometimes doesn't fit that style very well.
Even if you don't go all the way to using the assertion-evidence style, titles are a great place to summarize the main point of the slide. So rather than "Results (3)", use the space for something more descriptive like "Velocity vs time during reentry".
Even if you don't go all the way to using the assertion-evidence style, titles are a great place to summarize the main point of the slide. So rather than "Results (3)", use the space for something more descriptive like "Velocity vs time during reentry".
If you're being recorded for it to go on youtube, and you're doing a Q&A at the end, please repeat any questions that are asked for the benefit of the mic and those watching on youtube. Thanks
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.
There are quite some people who are writing full scripts. That's also what I prefer. It goes like this:
Before creating a single slide, write down sentence by sentence, word by word, what story you want to tell. You can use tools to get a very rough metric of how long your written text will translate being spoken. Stop when you reach your talk length.
Once you are done, you can start creating slides. Choose what you like the best and what fits your story. Few slides, many slides (e.g. Pecha Kucha), no slides.
I would never do live coding but show small videos instead. I have seen live coding fail more often than being a great success. But if you want to do so, have a fallback video at hands.
Now your rehearsal: Not 1 full, not 2 full rehearsals, do as much as you can! For my last and very first talk for a conference I did like 20 full rehearsals, 5 of them in front of people, some in the living room, some in front of the mirror. I bet this can be less in the future but it got me super confident. Rehearsal matters! Don't be lazy and you will be amazed how confident you can go into your talk.
When you black out during your talk, don't panic because you have a full script which you could theoretically read word for word. That always calms me down.
Good luck and have fun.
Before creating a single slide, write down sentence by sentence, word by word, what story you want to tell. You can use tools to get a very rough metric of how long your written text will translate being spoken. Stop when you reach your talk length.
Once you are done, you can start creating slides. Choose what you like the best and what fits your story. Few slides, many slides (e.g. Pecha Kucha), no slides.
I would never do live coding but show small videos instead. I have seen live coding fail more often than being a great success. But if you want to do so, have a fallback video at hands.
Now your rehearsal: Not 1 full, not 2 full rehearsals, do as much as you can! For my last and very first talk for a conference I did like 20 full rehearsals, 5 of them in front of people, some in the living room, some in front of the mirror. I bet this can be less in the future but it got me super confident. Rehearsal matters! Don't be lazy and you will be amazed how confident you can go into your talk.
When you black out during your talk, don't panic because you have a full script which you could theoretically read word for word. That always calms me down.
Good luck and have fun.
+1 for live coding being really hard. I’ve done many talks and by far the hardest was a live coding talk I did recently.
It has all the same difficulties as a regular talk, but with some added handicaps:
- no ability to make eye contact with your audience and feel the room
- no way to talk over small errors, if you get stuck on a bug it can take you 10 minutes to find your way back out
- very difficult to keep the audience’s attention since all they see is a wall of text
- talking and typing at the same time is really hard, you get to enjoy stammering your way through fumble fingers
In short: only try a live coding talk after you have a lot of presentation experience.
It has all the same difficulties as a regular talk, but with some added handicaps:
- no ability to make eye contact with your audience and feel the room
- no way to talk over small errors, if you get stuck on a bug it can take you 10 minutes to find your way back out
- very difficult to keep the audience’s attention since all they see is a wall of text
- talking and typing at the same time is really hard, you get to enjoy stammering your way through fumble fingers
In short: only try a live coding talk after you have a lot of presentation experience.
Make sure that your talk fits the timeslot.
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.
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.
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.
If you write slides with bulletpoints and read them, then er, just, don't.
I came across https://speaking.io _after_ I presented for the first time at a larger conference [1]. In hindsight it's so obvious -- Zach Holman really talks about the things that matter. So if you still have time, please do your future-self a favour and have a look at it.
Another point I found out _after_ I presented is to better avoid any caffeinated drinks -- apparently it makes your mouth dryer. Adding a bit of nervousness makes matters worse and you end up having to drink a sip of water every few minutes.
[1] https://youtu.be/wNrTDEaDVwU
Another point I found out _after_ I presented is to better avoid any caffeinated drinks -- apparently it makes your mouth dryer. Adding a bit of nervousness makes matters worse and you end up having to drink a sip of water every few minutes.
[1] https://youtu.be/wNrTDEaDVwU
Came here to say the same - https://speaking.io/ is very valuable in preparing, creating and delivering a (tech) conference presentation. Recommended resource!
Tell a good story. Humans love stories. Even the most deeply technical talk should have a narrative with a beginning, middle, and end.
Start with a bang. Have a controversial opinion? Lead with it. The slide with your name probably shouldn't be the first one, unless the conference makes you start that way. This goes back to point one -- telling a good story. You know how most movies start with something really exciting in the first few minutes? This is called the "inciting event" and is what drives the narrative. Your talk should have that too.
Start with a bang. Have a controversial opinion? Lead with it. The slide with your name probably shouldn't be the first one, unless the conference makes you start that way. This goes back to point one -- telling a good story. You know how most movies start with something really exciting in the first few minutes? This is called the "inciting event" and is what drives the narrative. Your talk should have that too.
The audience wants you to succeed and are generally very forgiving.
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.
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."
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?
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?
Plan to give the same talk several times. You can give it to your team, then to some local dev meeting, then on a larger conference. You can improve it over time.
Talk clearly, look at your audience, if it's hard to hear what you're saying at all then there is no point.
Make it clear what the problem you're solving is, why solving it would be nice, why obvious solutions aren't good enough, then work towards a big payoff at the end. Show that your tech solves the problem, and does it very neatly!
When explaining stuff, use examples.
Talk clearly, look at your audience, if it's hard to hear what you're saying at all then there is no point.
Make it clear what the problem you're solving is, why solving it would be nice, why obvious solutions aren't good enough, then work towards a big payoff at the end. Show that your tech solves the problem, and does it very neatly!
When explaining stuff, use examples.
1) Do not attempt to live code. change your code via version control, build small videos, copy and paste... whatever you do... do not try and live code
2) Read "The presentation secrets of Steve Jobs" ... its not really about Steve Jobs so much as its about how to be a great presenter.
3) building or writing a talk is significantly less important than the delivery... which means that more of your time should be spent on how to deliver the speech (recording I find is the best way to practice)
4) Pick a single thing and do it well, do not attempt to put too much into a talk or tackle something massively complex.
5) Make sure that everyone is walking away with something they can actually use. This doesn't require it be a hard skill... "Soft" or philosophical utilities are just as good
6) Have Fun and be funny... Speakers have a tendency to want to show off the size of their intellect, and the level their competency- having a speech be entertaining is way way more important.
7) DO NOT READ FROM YOUR SLIDES. know your shit. slides are supplementary
Extra Credit. Here's a collection of some fantastic technical speeches:
* https://vimeo.com/9270320 * https://www.destroyallsoftware.com/talks/wat * https://youtu.be/o_TH-Y78tt4 * https://www.youtube.com/watch?v=csyL9EC0S0c * https://youtu.be/a-BOSpxYJ9M * https://youtu.be/kb-m2fasdDY
2) Read "The presentation secrets of Steve Jobs" ... its not really about Steve Jobs so much as its about how to be a great presenter.
3) building or writing a talk is significantly less important than the delivery... which means that more of your time should be spent on how to deliver the speech (recording I find is the best way to practice)
4) Pick a single thing and do it well, do not attempt to put too much into a talk or tackle something massively complex.
5) Make sure that everyone is walking away with something they can actually use. This doesn't require it be a hard skill... "Soft" or philosophical utilities are just as good
6) Have Fun and be funny... Speakers have a tendency to want to show off the size of their intellect, and the level their competency- having a speech be entertaining is way way more important.
7) DO NOT READ FROM YOUR SLIDES. know your shit. slides are supplementary
Extra Credit. Here's a collection of some fantastic technical speeches:
* https://vimeo.com/9270320 * https://www.destroyallsoftware.com/talks/wat * https://youtu.be/o_TH-Y78tt4 * https://www.youtube.com/watch?v=csyL9EC0S0c * https://youtu.be/a-BOSpxYJ9M * https://youtu.be/kb-m2fasdDY
As I moved into management I started to give more and more talks/presentations. A few very tech talks at summits and conventions with our peers, most were briefings directed at upper management, and while the content are different they function the same really.
I start by figuring out what I want my audience to take a way from the talk. Then I break it up in keywords and then I build my presentation.
Once that is done I practice once or twice, by my self, talking to the computer while I rearrange, add or delete from the presentation to make it what I want it to be.
Once this is done I practice, going through the entire presentation until I’m able to give it on the fly if I was woken up at 4am. I don’t practice it word for word though, but when you’ve talked about a subject enough times, you can do it again.
The practice but is really, really important. Especially if you’re not used to giving speeches. At first I thought that if I just practiced in my head, I’d be fine, because I knew what I wanted to say. Hah, not so. The first time I gave a presentation I was a stuttering incoherent mess, because I hadn’t practiced by saying the words out loud. I knew exactly what I wanted to say, I just couldn’t.
Now, many years later, I don’t have to practice as much because I’ve gotten better verbally. So yo can definitely be the type of person who doesn’t need to practice out loud. But I had to do more than a thousand presentations to get to a point where I could comfortably skip practicing on short presentations and only doing it once or twice on long ones.
As for questions afterwards, take your time to think about your answer, and if you don’t know the answer, then be honest and always, always be polite and affirmative. If you make people feel like they asked a good question, even when you think it wasn’t, then they and everyone around them will like you better. This too gets better with practice, but it’s obviously not something you can practice on your own.
Humor is typically a good thing, it relies a lot in timing and it sometimes falls flat. Just never do it at someone’s expense.
I start by figuring out what I want my audience to take a way from the talk. Then I break it up in keywords and then I build my presentation.
Once that is done I practice once or twice, by my self, talking to the computer while I rearrange, add or delete from the presentation to make it what I want it to be.
Once this is done I practice, going through the entire presentation until I’m able to give it on the fly if I was woken up at 4am. I don’t practice it word for word though, but when you’ve talked about a subject enough times, you can do it again.
The practice but is really, really important. Especially if you’re not used to giving speeches. At first I thought that if I just practiced in my head, I’d be fine, because I knew what I wanted to say. Hah, not so. The first time I gave a presentation I was a stuttering incoherent mess, because I hadn’t practiced by saying the words out loud. I knew exactly what I wanted to say, I just couldn’t.
Now, many years later, I don’t have to practice as much because I’ve gotten better verbally. So yo can definitely be the type of person who doesn’t need to practice out loud. But I had to do more than a thousand presentations to get to a point where I could comfortably skip practicing on short presentations and only doing it once or twice on long ones.
As for questions afterwards, take your time to think about your answer, and if you don’t know the answer, then be honest and always, always be polite and affirmative. If you make people feel like they asked a good question, even when you think it wasn’t, then they and everyone around them will like you better. This too gets better with practice, but it’s obviously not something you can practice on your own.
Humor is typically a good thing, it relies a lot in timing and it sometimes falls flat. Just never do it at someone’s expense.
If your slide has writting on it, people will read your slide instead of listening to you. Keep the writing to a bare minimum and fill in the missing parts. Even better, use a picture that helps tell your story for that slide.
For each slide, think about what the audience take-away is. They should learn something from what you say for each slide.
Mingle and introduce yourself to a few people before your talk but don't tell them you are a speaker. Before you get on stage see if you can find them in the audience and pretend you are talking to them and not a huge audience. If you can't find some known faces, pick one from the first few rows. Helps with the nerves.
Until you get good at speaking, you need a lot of rehearsal for each talk. Present once in front of a willing friend and then after making corrections, get a few volunteers at work to be an audience. As many rehearsals as possible.
Slow down. Pause. People need a little time to digest each idea. Your material is new to them.
Like everything in life, the only way to become good is to make mistakes. With speaking you do that in front of a lot of people. It helps if you can laugh at yourself and be forgiving. The audience will often treat you the way you treat yourself.
For each slide, think about what the audience take-away is. They should learn something from what you say for each slide.
Mingle and introduce yourself to a few people before your talk but don't tell them you are a speaker. Before you get on stage see if you can find them in the audience and pretend you are talking to them and not a huge audience. If you can't find some known faces, pick one from the first few rows. Helps with the nerves.
Until you get good at speaking, you need a lot of rehearsal for each talk. Present once in front of a willing friend and then after making corrections, get a few volunteers at work to be an audience. As many rehearsals as possible.
Slow down. Pause. People need a little time to digest each idea. Your material is new to them.
Like everything in life, the only way to become good is to make mistakes. With speaking you do that in front of a lot of people. It helps if you can laugh at yourself and be forgiving. The audience will often treat you the way you treat yourself.
The 'assertion-evidence' approach to creating slides focuses on for keeping text to a minimum and using pictures and other visual aids to support your message. They emphasized it in my engineering school, and I've been using it in workplace presentations for years.
https://www.assertion-evidence.com/
https://www.assertion-evidence.com/
My biggest suggestion is this:
1. Don't read the slides to your audience. Generally speaking, the audience can read.
So what are slides for then? Well, if it's a text only slide, I treat them as being there to be reminders of what I'm supposed to talk about now. And that's it. The content is what I say, not what's on the slide. So there doesn't actually need to be much on the slide at all. Just a couple of bullets to reflect the high points of the conversation. Now graphics are a different story.
There are exceptions, of course. I've been known to do a slide with a massive list of "things" in 10 point font, with like 30 items on it... but when I do that, it's to make a point - a point like "there are a fuck-ton of options for X" or whatever.
The other thing I try to do, is put links and pointers to other resources somewhere in the deck, so that sharing it with the audience actually provides some value. If you adopt the "very information sparse" slide format, then the slides don't really provide much value to the audience after the fact. Whether that's an issue or not is kinda up to you.
1. Don't read the slides to your audience. Generally speaking, the audience can read.
So what are slides for then? Well, if it's a text only slide, I treat them as being there to be reminders of what I'm supposed to talk about now. And that's it. The content is what I say, not what's on the slide. So there doesn't actually need to be much on the slide at all. Just a couple of bullets to reflect the high points of the conversation. Now graphics are a different story.
There are exceptions, of course. I've been known to do a slide with a massive list of "things" in 10 point font, with like 30 items on it... but when I do that, it's to make a point - a point like "there are a fuck-ton of options for X" or whatever.
The other thing I try to do, is put links and pointers to other resources somewhere in the deck, so that sharing it with the audience actually provides some value. If you adopt the "very information sparse" slide format, then the slides don't really provide much value to the audience after the fact. Whether that's an issue or not is kinda up to you.
Finish your slides at least a few weeks before the talk and dedicate a time slot equivalent to the talk (ex: 1-hour => 1-hour, 30-min => 30-min) per week doing a dry run. This is particularly important to get the timing correct. If you're repeatedly short or long then adjust accordingly.
Version control your slides. This is particularly useful if you end up giving the same talk more than once as you can tweak things and improve it.
It's a tech talk, not a stand-up comedy routine. Light jokes and colorful anecdotes help with connecting to the content but the substance should stand on it's own.
Depending on your alcohol tolerance 1-2 drinks can be remarkably effective at smoothing out your delivery.
I find a small intro on the format of the presentation to be helpful at setting expectations. The talk descriptions are often very short and it's hard to gauge what's actually going to be covered with a lot of "Deep dive into XYZ" barely getting your ankles wet with real code. It's appreciated (as an audience member) to know in advance what you'll be getting.
Version control your slides. This is particularly useful if you end up giving the same talk more than once as you can tweak things and improve it.
It's a tech talk, not a stand-up comedy routine. Light jokes and colorful anecdotes help with connecting to the content but the substance should stand on it's own.
Depending on your alcohol tolerance 1-2 drinks can be remarkably effective at smoothing out your delivery.
I find a small intro on the format of the presentation to be helpful at setting expectations. The talk descriptions are often very short and it's hard to gauge what's actually going to be covered with a lot of "Deep dive into XYZ" barely getting your ankles wet with real code. It's appreciated (as an audience member) to know in advance what you'll be getting.
I could not disagree more with your first line. For one it's utter fantasy. For tech talks where you need to present results, sometimes results dont arrive until the morning of. Secondly, there should be a measure of proaction - gauge the audience and adjust the talk accordingly. In fact, I'd go the complete opposite, keep adjusting your slides until you're comfortable. But yes, do time yourself. Generally IMO a minute per slide is a good ballpark. This means your slide is not too empty or too full, and you can talk about the material in the slide without reading the slide out.
> I could not disagree more with your first line. For one it's utter fantasy.
The lead up from call for papers to actual conferences is usually 4-6+ months. Assuming you submit a talk without any content prepared yet and spend the first two months procrastinating, that leads 2-3 months for put together your outline and slides.
> For tech talks where you need to present results, sometimes results dont arrive until the morning of.
That's a specific case and hardly the norm. Plus you likely know the direction of the results without know the final 7 decimal points. The latter you fill in as it comes.
> Secondly, there should be a measure of proaction - gauge the audience and adjust the talk accordingly. In fact, I'd go the complete opposite, keep adjusting your slides until you're comfortable. But yes, do time yourself.
Definitely play the audience but if you haven't practiced your content you have to spend more time coming up with phrasing rather than shifting over, or dedicating more time to, a section.
> Generally IMO a minute per slide is a good ballpark. This means your slide is not too empty or too full, and you can talk about the material in the slide without reading the slide out.
I vary widely from 20 seconds per slide for a quick succession of minor points to 3-4 minutes when there's a code sample to talk through.
This is also why practice is so important as you get a feeling for where you can spend more time if you have it and where you can cut out if you don't.
The lead up from call for papers to actual conferences is usually 4-6+ months. Assuming you submit a talk without any content prepared yet and spend the first two months procrastinating, that leads 2-3 months for put together your outline and slides.
> For tech talks where you need to present results, sometimes results dont arrive until the morning of.
That's a specific case and hardly the norm. Plus you likely know the direction of the results without know the final 7 decimal points. The latter you fill in as it comes.
> Secondly, there should be a measure of proaction - gauge the audience and adjust the talk accordingly. In fact, I'd go the complete opposite, keep adjusting your slides until you're comfortable. But yes, do time yourself.
Definitely play the audience but if you haven't practiced your content you have to spend more time coming up with phrasing rather than shifting over, or dedicating more time to, a section.
> Generally IMO a minute per slide is a good ballpark. This means your slide is not too empty or too full, and you can talk about the material in the slide without reading the slide out.
I vary widely from 20 seconds per slide for a quick succession of minor points to 3-4 minutes when there's a code sample to talk through.
This is also why practice is so important as you get a feeling for where you can spend more time if you have it and where you can cut out if you don't.
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. :)
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. :)
Do not assume everyone knows acronyms or initialisms that you use, particularly if the audience is unknown. Saying "test driven development" is more accessible to a wider audience than "TDD".
Also, if someone is hearing impaired, they might not know what TDT is.
If there is a Q&A section and it's being recorded... please please please repeat the question so your mic pics it up because the person asking it is miles away and it never makes it into the audio so the people watching at home later have to guess what the question is based off the answer you gave which can be tough sometimes. So just a "Ok, so the question is... blah blah blah - answer".
Also... nothing can quite prepare you for how shot your nerves can be. It definitely pays to run it through many times as you can with a timer so that you are at least confident in your pacing.
Other than that it's quite fun.
It can be pretty handy to you to include your twitter handle in the top right corner so you get some follows throughout the presentation from people who were interested. At the end link off to 'you can find the slides for this presentation here bit.ly/soloyolo' etc.
Also... nothing can quite prepare you for how shot your nerves can be. It definitely pays to run it through many times as you can with a timer so that you are at least confident in your pacing.
Other than that it's quite fun.
It can be pretty handy to you to include your twitter handle in the top right corner so you get some follows throughout the presentation from people who were interested. At the end link off to 'you can find the slides for this presentation here bit.ly/soloyolo' etc.
Understand your audience.
It's SO easy to assume knowledge. When I talk about python, I now give a quick intro to the command prompt. I started out assuming everyone knew how to use the command prompt. A lot of times, you forget that the stuff you "just use" may be new to the listeners.
It's SO easy to assume knowledge. When I talk about python, I now give a quick intro to the command prompt. I started out assuming everyone knew how to use the command prompt. A lot of times, you forget that the stuff you "just use" may be new to the listeners.
who is your audience? where are they starting from? know this before going in.
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.
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.
Former tech trainer and presenter here. In no particular order:
* start by telling everyone what you're going to tell them, then tell them, then tell them what you just told them;
* know your material well enough that when your computer stops working you can carry on seamlessly;
* rehearse in front of a mirror or record and watch yourself;
* if you're talking too quickly, take a quiet breath and make sure you pronounce the last letter of each word that you speak;
* switch your slide to black or white when you're making a very important point, and have them focus on you instead of the screen -- use `b` key for black and `w` key for white, works with most presentational software I've used;
* …and smile
* start by telling everyone what you're going to tell them, then tell them, then tell them what you just told them;
* know your material well enough that when your computer stops working you can carry on seamlessly;
* rehearse in front of a mirror or record and watch yourself;
* if you're talking too quickly, take a quiet breath and make sure you pronounce the last letter of each word that you speak;
* switch your slide to black or white when you're making a very important point, and have them focus on you instead of the screen -- use `b` key for black and `w` key for white, works with most presentational software I've used;
* …and smile
How do you prepare and how long do you ought to spend preparing the talk? I'll quote `techtalk-pse`[1][2]:
[quote]
First, most important rule: Before you start drawing any slides at all, write your talk as a short essay.
This is the number one mistake that presenters make, and it is partly a tool fault, because PowerPoint, OpenOffice, even Tech Talk PSE, all open up on an initial blank slide, inviting you to write a title and some bullet points. If you start that way, you will end up using the program as a kind of clumsy outlining tool, and then reading that outline to your audience. That's boring and a waste of time for you and your audience. (It would be quicker for them just to download the talk and read it at home).
A good talk, with a sound essay behind it, well thought out diagrams and figures, and interesting demonstrations, takes many hours to prepare. How many hours? I would suggest thinking about how many hours of effort your audience are putting in. Even just 20 people sitting there for half an hour is 10 man-hours of attention, and that is a very small talk, and doesn't include all the extra time and hassle that it took to get them all in one place.
[/quote]
[1] https://en.wikipedia.org/wiki/Tech_Talk_PSE
[2] http://git.annexia.org/?p=techtalk-pse.git;a=blob;f=techtalk...
[quote]
First, most important rule: Before you start drawing any slides at all, write your talk as a short essay.
This is the number one mistake that presenters make, and it is partly a tool fault, because PowerPoint, OpenOffice, even Tech Talk PSE, all open up on an initial blank slide, inviting you to write a title and some bullet points. If you start that way, you will end up using the program as a kind of clumsy outlining tool, and then reading that outline to your audience. That's boring and a waste of time for you and your audience. (It would be quicker for them just to download the talk and read it at home).
A good talk, with a sound essay behind it, well thought out diagrams and figures, and interesting demonstrations, takes many hours to prepare. How many hours? I would suggest thinking about how many hours of effort your audience are putting in. Even just 20 people sitting there for half an hour is 10 man-hours of attention, and that is a very small talk, and doesn't include all the extra time and hassle that it took to get them all in one place.
[/quote]
[1] https://en.wikipedia.org/wiki/Tech_Talk_PSE
[2] http://git.annexia.org/?p=techtalk-pse.git;a=blob;f=techtalk...
The best advice I can give to you is that if you're giving a talk on something that you're not an expert on, then tell people you're not an expert.
I gave a talk a year ago about Continuous Delivery, despite being a bog-standard developer that has had to do it on a couple of occasions. I had some general rules that I could carry across from one company to another, so my talk was around these general paths to happiness, and discussing the tools I have used, alongside a generous Q&A.
The questions were all fairly straightforward, and a number of people came up to me at the end to share the same sentiments - they were developers that had been roped into doing sysadmin stuff, and that they found the talk and answers to be very useful.
I have a theory that people often go to talks not to learn something new from an expert on the subject, but for a structured developer chat around an approach on a subject that seems to work for someone in a given context. If they've attended, they're interested in the subject, so as long as what you say is on-subject and clear it's difficult to give a bad talk. From there, it's mostly around delivery, which comes with practice and preparation.
I gave a talk a year ago about Continuous Delivery, despite being a bog-standard developer that has had to do it on a couple of occasions. I had some general rules that I could carry across from one company to another, so my talk was around these general paths to happiness, and discussing the tools I have used, alongside a generous Q&A.
The questions were all fairly straightforward, and a number of people came up to me at the end to share the same sentiments - they were developers that had been roped into doing sysadmin stuff, and that they found the talk and answers to be very useful.
I have a theory that people often go to talks not to learn something new from an expert on the subject, but for a structured developer chat around an approach on a subject that seems to work for someone in a given context. If they've attended, they're interested in the subject, so as long as what you say is on-subject and clear it's difficult to give a bad talk. From there, it's mostly around delivery, which comes with practice and preparation.
The first few minutes are when the audience is most attentive, so don't waste it but jump right in with a motivating example or whatever is the most interesting thing about your talk. Then when you have them on the hook you can give them the outline and overview for the rest of the presentation as usual. I got this advice from a presentation given by Simon Peyton-Jones and have always tried to follow it since then.
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.
Have something to say. Something that you WANT to say. If you don't have that, cancel the talk.
So you want to say something. Say it.
Don't start your 20 minute talk by spending two minutes going over an outline of it, saying that you'll first present the problem, then review past work, then blah, blah, blah. I HOPE that the thing you want to say isn't "I've spent a lot of time organizing my talk like this..."
Don't start your talk with a funny anecdote about the driver of the taxi you took from the airport. I hope that THAT isn't what you want to talk about either.
Do start by describing the problem you're solving (you are solving some sort of problem, I assume...?). But only to the point where the audience can grasp what you're trying to do. Review past work only if the focus of your work is something like "I fixed the problem that the XYZ algorithm unnecessarily recomputes A...". You can mention how past work relates to yours at the end of the talk. It will make more sense then.
Get as quickly as you can to WHAT YOU ACTUALLY ACCOMPLISHED. I hope that's what you want to talk about.
So you want to say something. Say it.
Don't start your 20 minute talk by spending two minutes going over an outline of it, saying that you'll first present the problem, then review past work, then blah, blah, blah. I HOPE that the thing you want to say isn't "I've spent a lot of time organizing my talk like this..."
Don't start your talk with a funny anecdote about the driver of the taxi you took from the airport. I hope that THAT isn't what you want to talk about either.
Do start by describing the problem you're solving (you are solving some sort of problem, I assume...?). But only to the point where the audience can grasp what you're trying to do. Review past work only if the focus of your work is something like "I fixed the problem that the XYZ algorithm unnecessarily recomputes A...". You can mention how past work relates to yours at the end of the talk. It will make more sense then.
Get as quickly as you can to WHAT YOU ACTUALLY ACCOMPLISHED. I hope that's what you want to talk about.
The number one thing I love to see when I'm watching a tech talk that is focused on teaching or advertising a particular tech is the Bad Parts. Obviously you don't want to just bash the tech you're there for, but I've seen way too many demos that portray the technology as the One True Technology that will Solve All Your Problems and I usually approach tech talks from a place of skepticism.
Alice Goldfuss' recent talk on containers[1] is a really good example of what I'm talking about - she spends a good amount of time talking about what containers are, and why and when it would appropriate to use them, but she spends an equal or greater amount of time preparing the audience for what challenges they will encounter when implementing containers and talks about when you're probably better off without.
[1] https://www.youtube.com/watch?v=sJx_emIiABk
Alice Goldfuss' recent talk on containers[1] is a really good example of what I'm talking about - she spends a good amount of time talking about what containers are, and why and when it would appropriate to use them, but she spends an equal or greater amount of time preparing the audience for what challenges they will encounter when implementing containers and talks about when you're probably better off without.
[1] https://www.youtube.com/watch?v=sJx_emIiABk
Never assume that your audience knows anything of real substance about your talk. You've spent many hours building up knowledge and context about the subject, and your audience is coming in cold. I've rarely been to a talk where the speaker "over explained" the material.
Make the objective of your talk clear. If you're giving an introduction to some technology, it is helpful to also point people to resources to learn more. If you need to explain or 'sell' your topic, do so, but don't overdo it. Also, be honest. Everyone appreciates enthusiasm, but it's better if you don't come across as a fanboy.
If you're having an interactive part, be aware that it is hard to estimate the time this part will take. If you have a hard deadline, be ready to skip some parts (this is a good idea in general as things may always
It's probably best if you are so familiar with the topic that you don't really need slides in the first place. On the other hand, take care to connect with your audience and take their background into consideration.
If you're having an interactive part, be aware that it is hard to estimate the time this part will take. If you have a hard deadline, be ready to skip some parts (this is a good idea in general as things may always
It's probably best if you are so familiar with the topic that you don't really need slides in the first place. On the other hand, take care to connect with your audience and take their background into consideration.
Stick to the topic, and don't go meta. Leave out things like "when I was preparing to submit this talk proposal" or "as I was creating the slides for this talk." Talk about the topic, don't talk about the talking.
Know the language and culture of your audience. If it's a mixture of people who don't speak English (or whatever language) as their first language, take care to avoid colourful metaphors that make sense to a native speaker but which confuse non-native speakers. I've confused people with expressions like "inside baseball" or reference to "Goldilocks values" (not too much, not too little). Good metaphors are valuable. Metaphors that depend on too much cultural context are unhelpful.
Know the language and culture of your audience. If it's a mixture of people who don't speak English (or whatever language) as their first language, take care to avoid colourful metaphors that make sense to a native speaker but which confuse non-native speakers. I've confused people with expressions like "inside baseball" or reference to "Goldilocks values" (not too much, not too little). Good metaphors are valuable. Metaphors that depend on too much cultural context are unhelpful.
https://www.deconstructconf.com/blog/how-to-prepare-a-talk
This is really good write up on similar topic by Gary Bernhardt.
Something practical I haven't seen mentioned yet: unless you know the venue, assume the screen is far away from the audience (so the text needs to be large) and that it's hanging low (so most people can't see the bottom of the slides).
Black background with white text helps too.
That depends (a lot) on the displaying and viewing conditions; are your slides projected in a dimly-lit room, or are the lights on? Readability of your slides is affected by that.
Although slides often don't contain much information that needs to be read in full detail, I find code examples to be better readable in a dark font on a lighter background.
Sometimes the conference gives some advice regarding the slides (dark text on light backgrounds or vice versa), since they'll know / set the room lighting conditions.
Although slides often don't contain much information that needs to be read in full detail, I find code examples to be better readable in a dark font on a lighter background.
Sometimes the conference gives some advice regarding the slides (dark text on light backgrounds or vice versa), since they'll know / set the room lighting conditions.
There is a lot of good content advice here. I'd like to add two technical points:
- Plan for the worst-case scenario, e.g. your computer dying. All my presentations are available on GitHub Pages[0] (using RevealJS), so all I need is a random laptop.
- Use a bright color theme on a beamer to improve readability (slides, console, editor/IDE). Dark schemes are nice, but they are inappropriate for most presentations. Bonus: when using HTML slides, you can design both a bright and dark theme and switch depending on the light conditions.
[0] https://github.com/darekkay/presentations/
- Plan for the worst-case scenario, e.g. your computer dying. All my presentations are available on GitHub Pages[0] (using RevealJS), so all I need is a random laptop.
- Use a bright color theme on a beamer to improve readability (slides, console, editor/IDE). Dark schemes are nice, but they are inappropriate for most presentations. Bonus: when using HTML slides, you can design both a bright and dark theme and switch depending on the light conditions.
[0] https://github.com/darekkay/presentations/
I'm a Toastmasters member, and one of the things I learned with presenting technical talks is that you should know your audience. If your audience understands the tech, then speak at a technical level, otherwise speak at a very high level
- Don't put too much on your slides.
- Don't put too much on your slides.
- Don't put too much on your slides
See if you can do without any bullet list. Now you are forced to talk from your experience in a natural form. You'll be fine.
More serious:
- don't go into the trap of too much introduction and theory before getting to the actual matter. E.g. when doing a talk on GPU image processing don't spend 30 minutes on how a GPU works.
- Know your audience experience with the matter if possible (see above)
- If possible, do demos. If have demos, consider if it makes sense to run them _before_ the tech slides. They tend to make more sense after seeing a live demo.
- If you have demos, rehearse them. Make sure you get the timing right.
- leave room for questions.
- Don't put too much on your slides.
- Don't put too much on your slides
See if you can do without any bullet list. Now you are forced to talk from your experience in a natural form. You'll be fine.
More serious:
- don't go into the trap of too much introduction and theory before getting to the actual matter. E.g. when doing a talk on GPU image processing don't spend 30 minutes on how a GPU works.
- Know your audience experience with the matter if possible (see above)
- If possible, do demos. If have demos, consider if it makes sense to run them _before_ the tech slides. They tend to make more sense after seeing a live demo.
- If you have demos, rehearse them. Make sure you get the timing right.
- leave room for questions.
Introduce yourself.
Way too many times I’m sitting in the audience, the person at the front is exchanging smiles with the programme committee who all know each other, but I have no idea who they are and what drives their viewpoint.
Way too many times I’m sitting in the audience, the person at the front is exchanging smiles with the programme committee who all know each other, but I have no idea who they are and what drives their viewpoint.
If you're showing code, use way less code than you initially want to.
Chances are you’re an expert in the field! Great! Rember not everyone in the audience is.
Keep in mind who you’re talking to and what they’ll bring home from your talk.
Will they use it on their job? Then it’ll need operational details. It’s just something cool you did? Make sure it’s a good story with villains (problems) henchmen (bugs) and it stays relatable all the way to the victory. Is somerhing that pushes the envelope of what’s known? Make sure to establish the state of the art and guide the audience through the wonder of the discovery process.
Keep in mind who you’re talking to and what they’ll bring home from your talk.
Will they use it on their job? Then it’ll need operational details. It’s just something cool you did? Make sure it’s a good story with villains (problems) henchmen (bugs) and it stays relatable all the way to the victory. Is somerhing that pushes the envelope of what’s known? Make sure to establish the state of the art and guide the audience through the wonder of the discovery process.
Don't start with powerpoint.
Get pen and paper.
DRAW what you want to tell.
If the result is good you can scan that drawing to make a slide.
This way I don't overspend time on tools, but on content.
Hope this helps
This way I don't overspend time on tools, but on content.
Hope this helps
Simple things that have helped me:
- Right before the talk: get to the room well ahead of time and make sure there are no setup issues with the laptop, audio, projector, etc. I've seen a number of speakers fail to do this basic thing and it dampens their flow, confidence, etc. The audience might even get distracted and the whole show goes awry.
- Prepare and practice the intro speech, don't wing it: if you have a good opening, you'll feel confident and the momentum will carry you through the rest of the talk.
- Right before the talk: get to the room well ahead of time and make sure there are no setup issues with the laptop, audio, projector, etc. I've seen a number of speakers fail to do this basic thing and it dampens their flow, confidence, etc. The audience might even get distracted and the whole show goes awry.
- Prepare and practice the intro speech, don't wing it: if you have a good opening, you'll feel confident and the momentum will carry you through the rest of the talk.
Don't do a Ubuntu update the day of the speech. I did then closed my laptop, headed to the venue to give a 30 minute workshop on best practices in resumes and the reasons for a LinkedIn Profile in front of 40 people, and bootloader was corrupted. Thankfully I had backup of folder (reveal.js presentation written with rmarkdown) on USB. I usually zip up and email a copy to the organizer, just in case.
Casually give an informal version of the talk to some friends or colleagues to see if they "get it".
I find that talking it through a few times with someone will help you figure out which parts of your explanation are unclear and need rephrasing.
Also, don't take it too seriously - technical talks are already often dry - don't be afraid to insert some memes and jokes to keep the audience engaged!
I find that talking it through a few times with someone will help you figure out which parts of your explanation are unclear and need rephrasing.
Also, don't take it too seriously - technical talks are already often dry - don't be afraid to insert some memes and jokes to keep the audience engaged!
Don't try and cover too much ground in the time - it is generally quicker than you think. Have a strong story arc however so that any questions can be asked at the end during the presentation or afterwards.
You can always put slides and examples online and refer to them, especially if in another country where people might not keep up with your native language.
Smile a lot!
You can always put slides and examples online and refer to them, especially if in another country where people might not keep up with your native language.
Smile a lot!
Two things I haven't seen ITT yet:
1. After you tell me what you're going to talk about, tell me why I should be listening to _you_. Why are you an authority on this topic? Unless you're famous, I don't know you.
2. The talk should contain 50% or less of your knowledge on the topic. You want to keep some info "in your back pocket" to ad lib with.
1. After you tell me what you're going to talk about, tell me why I should be listening to _you_. Why are you an authority on this topic? Unless you're famous, I don't know you.
2. The talk should contain 50% or less of your knowledge on the topic. You want to keep some info "in your back pocket" to ad lib with.
After you tell me what you're going to talk about, tell me why I should be listening to _you_.
Interesting. I never do this, and probably never will. My viewpoint is that you've already made the decision to attend the talk, so me spending time reciting my bio is just redundant and a waste of time.
Interesting. I never do this, and probably never will. My viewpoint is that you've already made the decision to attend the talk, so me spending time reciting my bio is just redundant and a waste of time.
I frequently see speakers end their talk with “Any questions? No questions?? I was really perfectly clear? OK. Bye!” That fast.
It takes at least ten seconds for people to formulate a question well enough to ask it in front of everybody. Have some patience. Bonus points for having something low-key to fill the awkward silence.
It takes at least ten seconds for people to formulate a question well enough to ask it in front of everybody. Have some patience. Bonus points for having something low-key to fill the awkward silence.
I write a weekly newsletter on this exact topic - you might find it useful :)
http://blog.voxgig.com/2018/07/13/welcome-voxgig-newsletter-...
http://blog.voxgig.com/2018/07/13/welcome-voxgig-newsletter-...
I had filed this one (1) away for next time I have to do a presentation. It sums up a list of bad titles for a presentation.
[1] https://gist.github.com/snare/7f0c4708bf4ea8133204c21e8ba64d...
[1] https://gist.github.com/snare/7f0c4708bf4ea8133204c21e8ba64d...
in my experience I would consider the following:
- Understand what are your takeaways for the audience. Remember it's about the content, keep in mind main areas/topics to cover.
- who's your audience ?, there are a few conferences where going very technical (low level) matters, most of them want to focus on how X works, how to solve Y, etc.
- "Start with why". Yeah, it should sound familiar, check this 5 minutes video: https://www.youtube.com/watch?v=IPYeCltXpxw .
- Note that likely in the first 3-5 minutes the audience will have a > 90% focus on what are you talking about, make sure to take advantage of that time with a good "why" (see above) for engagement.
- Share your presentation slides with a colleague and wait for "honest" feedback.
- Understand what are your takeaways for the audience. Remember it's about the content, keep in mind main areas/topics to cover.
- who's your audience ?, there are a few conferences where going very technical (low level) matters, most of them want to focus on how X works, how to solve Y, etc.
- "Start with why". Yeah, it should sound familiar, check this 5 minutes video: https://www.youtube.com/watch?v=IPYeCltXpxw .
- Note that likely in the first 3-5 minutes the audience will have a > 90% focus on what are you talking about, make sure to take advantage of that time with a good "why" (see above) for engagement.
- Share your presentation slides with a colleague and wait for "honest" feedback.
Here's a blogpost I wrote on dos/donts of giving tech talks - https://medium.com/@gauravgupta/make-a-powerful-point-the-ne...
[deleted]
No matter how small the room is, or how much you think you can project, use the microphone. I can't stand when people say, "I have a loud voice, I'm not gonna use the microphone." And then either scream for an hour, or fade in and out of intelligibility.
- What is your message? You do this talk for a reason, it must be extremely clear to you what it is, in a short sentence or two.
- Storytelling. Humans engage in stories. Prepare yours.
- Rehearse. Rehearse. Rehearse. And when you are done, rehearse again fixing everything that was not perfect.
- Storytelling. Humans engage in stories. Prepare yours.
- Rehearse. Rehearse. Rehearse. And when you are done, rehearse again fixing everything that was not perfect.
TLDR; Recognize impostor syndrome and include 'basics' even in presentations for highly skilled people.
I'm in the physical sciences and routinely give fairly math-heavy presentations.
It's easy to think that an audience of Phd's and professors know all prerequisites and just need the hard facts in a rapid succession.
On the contrary over time I found that my audience typically appreciates when I start from the very beginning (in my case meaning advanced undergraduate level or so), and working up to the actual problem setting.
Although my audience is very much expected to know that material they A) get primed for the topic and have a chance to feel good about 'I know this' and B) understand my view of the topic so that we have a common language.
With that I'm ready to frame the technical problem and explain my work.
The last time I did this I actually spent 10 out of 20 minutes on the first part, and the talk was very well received and generated an 'invited paper' request for a journal.
No one has ever complained that my talks are 'too basic'.
EDIT: Btw, the metric I use to measure success is amount of generated questions & engagements in and after the talk. If the moderator has to cut off Q&A for the next speaker you win. If people hunt you down to talk more you win.
I'm in the physical sciences and routinely give fairly math-heavy presentations.
It's easy to think that an audience of Phd's and professors know all prerequisites and just need the hard facts in a rapid succession.
On the contrary over time I found that my audience typically appreciates when I start from the very beginning (in my case meaning advanced undergraduate level or so), and working up to the actual problem setting.
Although my audience is very much expected to know that material they A) get primed for the topic and have a chance to feel good about 'I know this' and B) understand my view of the topic so that we have a common language.
With that I'm ready to frame the technical problem and explain my work.
The last time I did this I actually spent 10 out of 20 minutes on the first part, and the talk was very well received and generated an 'invited paper' request for a journal.
No one has ever complained that my talks are 'too basic'.
EDIT: Btw, the metric I use to measure success is amount of generated questions & engagements in and after the talk. If the moderator has to cut off Q&A for the next speaker you win. If people hunt you down to talk more you win.
The why is much more important than the how. The job of the talk is to convince people to read your paper. Focus on motivating your work, overview how the approach was done and the results but the setting for the problem is much more important.
Keep the needs of the audience in mind.
More: http://www.davidralbrecht.com/notes/tags/engcomm.html
More: http://www.davidralbrecht.com/notes/tags/engcomm.html
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.
I will sound like an @$$ but get to the point quickly so many times 1 hour talk could actually be condensed to like 5 minutes of actual information. I wish there was a service that actually did this :)
Kelsey Hightower had some insightful tips in this recent podcast: http://testandcode.com/43-bonus
Have a look at https://perl.plover.com/yak/presentation/
- Rehearse in front of a friend.
- Add as little text to your slides as you can
- Accept that you will get nervous. We all do, being nervous is not a problem, the fear of it is.
- Remember, the audience wants you to succeed
- Add as little text to your slides as you can
- Accept that you will get nervous. We all do, being nervous is not a problem, the fear of it is.
- Remember, the audience wants you to succeed
Who are your audience? What is their level of knowledge? What do they want to know? What DON'T they want to know? Why should they care what you've got to say?
I'll give you what I do. I assume that tech talk here means seminar and not class. For a class I do things differently. First, write down the goal of the talk. What should the audience know, be able to do, etc. after this talk? If it's more than three bullet points, it's time to start cutting. Remember, in a talk, everyone is at the mercy of your pacing. Any given audience member will probably space out for at least five minutes of an hour talk, and if you're at a conference or embedded in a workday, they're already overwhelmed with information.
Then sketch an outline of presenting that information, just a rough order of what to touch on. I find that I naturally outline so that each entry is about five minutes, but I don't know if that's just me or a common tendency.
Then I get a timer, stand up, and start talking to myself. I'll take an outline entry, and try to tell an imaginary audience about it. Typically I realize that I have some questions I need to answer for myself, or I run over five minutes. Think about how to drop stuff, look up what you need, note down what bits of verbiage came out that flowed well to reinforce them for yourself, and do it again. I often get frustrated after two or three times on one item, and go do another one, then come back to it and do it some more. During this whole process pretend the perfect slide to go with your text is up next to you so you can point.
After some cycles, this will converge. You will know what you want to say, and you will know what needs to be on the slides. Now set the timer for the full talk length and give the whole talk like this, still with pretend slides. You'll probably find places where you need transitional material, and it will probably run long despite the fact that the pieces add up to fit. Adjust. Do it again. This is also a good time to figure out and memorize the first couple sentences of each section, which will let you transition easily if you lose your place.
At this point you know your talk. Now go sketch your slides out on paper, and give your talk pointing to the paper. Once you think you have what you need figured out on paper, then go turn them into a PowerPoint, PDF, whatever.
Now practice it with the slides. Practice starting from a section using those memorized sentences. Memorize your sequence of outline items with those sentences attached.
Then do a run-through the day before. The day of, I spend five minutes thinking through my outline and section starting sentences, take a deep breath, and talk as inhumanly slow as you can. Even if you don't have stage fright (I don't), you will have adrenaline, and you need to slow down.
Then sketch an outline of presenting that information, just a rough order of what to touch on. I find that I naturally outline so that each entry is about five minutes, but I don't know if that's just me or a common tendency.
Then I get a timer, stand up, and start talking to myself. I'll take an outline entry, and try to tell an imaginary audience about it. Typically I realize that I have some questions I need to answer for myself, or I run over five minutes. Think about how to drop stuff, look up what you need, note down what bits of verbiage came out that flowed well to reinforce them for yourself, and do it again. I often get frustrated after two or three times on one item, and go do another one, then come back to it and do it some more. During this whole process pretend the perfect slide to go with your text is up next to you so you can point.
After some cycles, this will converge. You will know what you want to say, and you will know what needs to be on the slides. Now set the timer for the full talk length and give the whole talk like this, still with pretend slides. You'll probably find places where you need transitional material, and it will probably run long despite the fact that the pieces add up to fit. Adjust. Do it again. This is also a good time to figure out and memorize the first couple sentences of each section, which will let you transition easily if you lose your place.
At this point you know your talk. Now go sketch your slides out on paper, and give your talk pointing to the paper. Once you think you have what you need figured out on paper, then go turn them into a PowerPoint, PDF, whatever.
Now practice it with the slides. Practice starting from a section using those memorized sentences. Memorize your sequence of outline items with those sentences attached.
Then do a run-through the day before. The day of, I spend five minutes thinking through my outline and section starting sentences, take a deep breath, and talk as inhumanly slow as you can. Even if you don't have stage fright (I don't), you will have adrenaline, and you need to slow down.
You probably know more about the subject than the people you are speaking to. So, when appropriate, err on the side of giving more background info than less.
1. Describe the problem you're trying to solve.
2. Describe your approach to solving it.
In general, have something to say, know your stuff, and the rest will flow naturally.
2. Describe your approach to solving it.
In general, have something to say, know your stuff, and the rest will flow naturally.
When practicing and figuring timing, I find it helps to do it out loud. I go way too fast if I don’t properly vocalise it.
I find code in slides a bit distracting. It's better to have code in a separate editor (which can be run too!).
Proofread everything you plan to display, because spelling and grammar errors can negate your authority (hint ^^^).
can keep in mind transitions between slides, whether working your way through the current slide as intended or digressing. these transitions can contain a purpose for arriving at the end of the current slide + relevance to the upcoming ones
These are some things that I generally keep in mind whilst preparing or giving a talk. (These are just things I do, feel free to disagree.)
Preparing: 1) Give yourself enough time to write and practice the talk. If you can get ~1 month, that (for me atleast) is more than enough time.
2) Say the words out loud when practicing. You may use different words or slightly improvise during the talk, which is totally fine. Just let yourself hear some version of it a few times (out loud) before presenting. In my experience this helps to avoid stutters, and keeps you in your place.
3) Watch talks of people online that you enjoy or by people that inspire you. We all have our own "style" when it comes to public speaking. You will never be able to straight up copy someone. But watch and take mental notes as you do.
4) (If you are preparing slides), keep them simple! It is YOU who is presenting the talk. Not a wall with a projector. Treat your slides mostly as an accessory. They can help illustrate a point perhaps, or outline the key subjects. Short and simple.
Presenting: 1) If you can, make sure you have a bottle of water handy when you go up.
2) When I approach the stand, platform or stage, I like to do so with confidence. This really does depend on the setting. But for example, as I walk up, sometimes I'll take my jacket off. Or do something that otherwise makes me feel like I'm owning the space. This makes me feel much more comfortable and puts me off to a good start. Even if you're not a confident person, walk up as if you are or do something simply to make you feel more comfortable.
3) Don't be afraid to use the space you have been given. This goes both for actually walking around, and using your arms to assist your words. Hands out of pockets. Use them.
4) Pauses are a good thing! Whether it's just to take a sip of water, or just a pause for the sake of pausing. This both gives you a few moments to collect your thoughts and also a few moments for the audience to digest what you have just been saying.
5) Slowww it down. It's almost too easy sometimes to rush talks when it comes down to actually presenting one. Take your time. They came to see you! So make it worth their while.
6) This is slightly tricky in some cases, but try to calibrate yourself towards the audience. For example, in my case, I've found people seem to pay more attention if I've just said something slightly amusing. If you can get away with it, go for it! It's a hard one to explain, but the bottom line is, try to get the crowd on the same page. I'll perhaps think of a better way of explaining this one and reply to this comment.
Preparing: 1) Give yourself enough time to write and practice the talk. If you can get ~1 month, that (for me atleast) is more than enough time.
2) Say the words out loud when practicing. You may use different words or slightly improvise during the talk, which is totally fine. Just let yourself hear some version of it a few times (out loud) before presenting. In my experience this helps to avoid stutters, and keeps you in your place.
3) Watch talks of people online that you enjoy or by people that inspire you. We all have our own "style" when it comes to public speaking. You will never be able to straight up copy someone. But watch and take mental notes as you do.
4) (If you are preparing slides), keep them simple! It is YOU who is presenting the talk. Not a wall with a projector. Treat your slides mostly as an accessory. They can help illustrate a point perhaps, or outline the key subjects. Short and simple.
Presenting: 1) If you can, make sure you have a bottle of water handy when you go up.
2) When I approach the stand, platform or stage, I like to do so with confidence. This really does depend on the setting. But for example, as I walk up, sometimes I'll take my jacket off. Or do something that otherwise makes me feel like I'm owning the space. This makes me feel much more comfortable and puts me off to a good start. Even if you're not a confident person, walk up as if you are or do something simply to make you feel more comfortable.
3) Don't be afraid to use the space you have been given. This goes both for actually walking around, and using your arms to assist your words. Hands out of pockets. Use them.
4) Pauses are a good thing! Whether it's just to take a sip of water, or just a pause for the sake of pausing. This both gives you a few moments to collect your thoughts and also a few moments for the audience to digest what you have just been saying.
5) Slowww it down. It's almost too easy sometimes to rush talks when it comes down to actually presenting one. Take your time. They came to see you! So make it worth their while.
6) This is slightly tricky in some cases, but try to calibrate yourself towards the audience. For example, in my case, I've found people seem to pay more attention if I've just said something slightly amusing. If you can get away with it, go for it! It's a hard one to explain, but the bottom line is, try to get the crowd on the same page. I'll perhaps think of a better way of explaining this one and reply to this comment.
Ask yourself: “Who is my audience?” Everything else comes from that.
If you get butterflies or a racing heart, take three deep breaths.
As a tech conference audience member, one of my biggest pet peeves is people using roughly 70+ percent of their talk to introduce the background/rationale of their tool/library/use-case/workflow/whatnot without even showing precisely what the tool does or how to use it practically. Chances are, most people in the audience are in the room _because they are already on board with your rationale_.
A fake example: If you're giving a talk on your new Linux shell that 's way better than Bash, you don't need to spend the first two-thirds of your talk explaining what Bash is and what its weaknesses are. Your audience probably knows what Bash is and knows enough to be interested in an alternative. Don't bore them out of the room.
TL;DR: Show first, tell second.
A fake example: If you're giving a talk on your new Linux shell that 's way better than Bash, you don't need to spend the first two-thirds of your talk explaining what Bash is and what its weaknesses are. Your audience probably knows what Bash is and knows enough to be interested in an alternative. Don't bore them out of the room.
TL;DR: Show first, tell second.
Proofread the title. Pay attention to articles...
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.
A technique that works really well for me is to focus hard on the fact that my job is to be merely a conduit for information, and any anxiety I might feel is just another factor that might impact my ability to convey that information. My feelings then become secondary because my whole focus is on the message. Sometimes I still get an adrenaline rush at the start, but this dissipates as I focus on the content. Other times I am completely relaxed throughout.
[deleted]
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.