More generally, you should view presentations as stories. Obviously not stories presented solely for their drama as one might watch a movie, but the fundamental

More generally, you should view presentations as stories. Obviously not stories presented solely for their drama as one might watch a movie, but the fundamental "conflict -> tension raising -> resolution" cycle ought to be in your presentation, multiple times as needed just as they nest within a traditional story. It is tempting to the technical mind to present them as we see mathematical proofs, building from the fundamentals up to the final result in a completely-temporally-ordered manner, but the reasons that works in a math text don't apply to presentations. And a lot of people don't find it all that useful in math texts intended for learning either, if you read one of HN's periodic discussions of "how we learn math best". This post is basically to use the "start with a hook" approach to story telling, which is a good option. There are others, but there's a reason so many good stories-for-the-sake-of-stories use this approach. In general if people are showing up to your presentation voluntarily, you do have a couple of slides you can use to build some tension up before they'll zone out on you, but you do want to get to your first "conflict" fairly quickly. This is pretty abstract, so let me give a specific technical example to show what I mean. It's been a while now since pretty much everyone knows git, but for a while I was the de facto git trainer in my company. I had a prepared presentation I used for this, and I had the people in the presentation follow along, running commands in a local repo they create on the spot. I did not immediately start with a hook; I did start with general overview of git and how it works, but on what would be the fourth slide or so, rather than take them through nothing but the happy path, I start getting them into trouble, detaching the head. Everyone detaches head sooner or later without meaning to. This is the conflict & tension, and the resolution is, how do we solve this problem? The rest of the presentation does not just guide through the happy paths, but periodically either gets them into one of the common error states or walks them through a common pitfall by not just warning them about it, but taking them through the process of getting into various common troubles and then getting out of it. Each of these cycles is an implicit story, where the main character gets into trouble, as appropriate the trouble gets worse, then the trouble is resolved. Obviously no one would go to a movie theater to watch someone get stuck in git and then get unstuck; it is not that kind of story. Programming and hacking get dressed up the way they do by Hollywood for a reason; the real thing is unwatchably boring. But it still has the story cycle in it. You can also spice you presentations up by showing some of the wrong paths you encountered or the problems you had to solve instead of just presenting the bare results; in addition to being more compelling in the abstract, such presentations are more valuable anyhow in a lot of other ways. This is far more effective then a standard dead presentation that just shows "how to do this. how to do that. how to do the other thing. now you know things go forth and do" while the audience's eyes glaze over.