Every story has a beginning but we need to find a way to take the audience from where they currently are to the beginning of the story and the amount of work that we need to get there can vary.

If it’s an audience that know the topic very well and are of a similar background to us then a quick explanation will do but we need to judge what our audience will be before working out how much context needs to be provided.

Most of the time I think people don’t get enough context and the talk becomes quite difficult to follow but I did give a presentation a couple of years ago where I ended up giving unnecessary context and watched people’s eyes glaze over!

In stand up comedy the key to a good joke is that you give just enough context so that the punch line of the joke makes sense. If you give a lot of context then there’s an assumption that the punch line is going to be stunning.

When writing jokes you therefore spend a lot of time refining the context until it’s just right. I think we should apply the same thinking in normal talks.

After we’ve got our hook sorted out and brought the audience to the beginning of our story the next thing to focus on is writing a coherent story which moves along at an appropriate pace.

The main thing to focus on here is to tell a story which is appropriate for the audience.

For example I recently gave two talks on a neo4j graph I’ve been working on with ThoughtWorks data - one to a ThoughtWorks audience and one to the neo4j user group.

In the first talk my story was an inward looking reflection on a bunch of data about ourselves and the tools I’d used to do that played a backseat role.

In the second talk I focused on the way that I’d iterated the model to answer questions that I had about the data over time.

In both cases I was able to identify a skeleton to hang the details of the story onto.

After we have a rough outline of an interesting story we need to fill in the details and make sure that the story actually makes sense and will be interesting to tell.

Sometimes this means switching the order that things would normally come in. I think this is ok - our goal isn’t to tell the exact chronological order in which we learnt things but to explain them in a way that’s easy to understand.

For example in my neo4j talk the order that I presented the questions I asked about the data wasn’t exactly the same as in real life. The points I wanted to make about modelling your data fitted better with a revised order so that’s what I did!

My way of preparing the story I want to tell is to sketch out some slides and then imagine presenting it to see if it makes sense - I often end up reworking it over a period of weeks until I’m happy.

It’s also useful to run through the story with someone else before hand to see if it makes any sense.

As with almost everything one idea isn’t applicable everywhere and there are other ways to present a topic other than giving your own perspective on it.

If you’re the expert on a particular topic and you’re presenting some new information about a language/tool then you don’t necessarily need to tell a story.

Having said that, a lot of good presentations I’ve watched tend to first describe the problem they’re trying to solve followed by their solution, which is effectively telling a story!

Another presentation technique is the '10 things I learnt about…​' approach which makes sense if there doesn’t seem to be a coherent story line to weave.

Overall though I think the story telling approach is my preferred one and it pretty much mirrors what people do in normal conversations so we may as well take that familiarity with us when doing a presentation!