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?