2. Describe your approach to solving it.
In general, have something to say, know your stuff, and the rest will flow naturally.
21–30 of 174 posts
2. Describe your approach to solving it.
In general, have something to say, know your stuff, and the rest will flow naturally.
http://blog.voxgig.com/2018/07/13/welcome-voxgig-newsletter-...
Don't spent 10 minutes on the introduction. A very common mistake is people step too slowly through the setup material. Just lay out the problem and GO. In fact, even throughout the talk, assume the audience is smart and can fill in the obvious blanks.
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.
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.
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.
If you write slides with bulletpoints and read them, then er, just, don't.
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!