Writing a Tech Talk Using Storytelling Techniques

Written by virtualgill | Published 2018/04/05
Tech Story Tags: writing | storytelling | software-development | write-a-tech-talk | storytelling-techniques

TLDRvia the TL;DR App

Giving a Technical Talk isn’t so different from telling a story.

Some of you who read my blogs will already know that storytelling is very close to my heart. To me all of life is just a series of stories, from our interactions with other people, to the software I write. I was recently asked about how I write a technical talk. When I thought about it I realised I approach it as if I was writing a story. I had never laid out the steps I follow (and honestly I don’t do them in any sort of structured fashion), but once it was in my head I thought it might be worth sharing in case it helped anyone else.

Write down your Purpose

First things first. You need to know the purpose of your talk. This is the most critical piece. If you don’t know why you are telling the story then nothing else is going to make sense. Everything else that comes after this must always serve the purpose.

Why am I telling this story?What do I want people to know / have learnt?

This is worth spending a bit of time on. I know that sometimes I have started out thinking that my purpose was one thing, and realised at 3am one night it wasn’t at all. Other times I have been very clear on what my purpose is right from the start. Once you know why you are telling the story, then what the story is will fall into place.

Work out your Story Arc

Each story follows a very basic pattern:

What the problem wasWhat you did or did not do to solve itWhat the outcome was

Don’t get hung up on the word “problem”. The “problem” can be that you needed to solve a business problem, so you are telling the story of an application you built. But it may be that you started to use a new technology, and now you are sharing tutorial on how to get started.

The story you tell needs to be focussed. The best way to do this is to first work out where you want to end. Then based on that, work out how close to that you can start so that the story still makes sense. That may seem like the wrong way round, but it will stop you starting back when computers were first invented and never really finishing anywhere at all.

You can give some backstory in the scene setting, but the core of the story should be rich and detailed, so you want to make sure you aren’t trying to fit in too much! You will have to leave things out — and it’s ok to specially point out that there are things you aren’t covering. If you are finding it hard at this point look back to your purpose, and let it guide you!

Who is my Audience and what Assumptions can I make?

With a talk you should be able to know something about your audience. It’s worth thinking about what part of the story will be most important to them — review your story arc, is it covering what they would want to know?

What do they care about?What do they expect to learn?What assumptions can I make about what they already know?

Being able to make assumptions about what the audience will know is important. You can’t cover everything, but you do need to make sure that your audience knows enough to keep up with your story. At a Javascript conference you should assume that people already know what javascript is, but you can also assume that they know things like what an IDE is, or what the command line is. If you are giving a talk to school children there isn’t any reason to assume they would know any of that.

Who are the Characters?

I find it very useful to consider all the technologies, applications and people as characters in my story. Just like an author would, I make some notes about them for myself to help me shape my story. This bit is for you, and you should be generous with information for yourself, but only give the audience what they need for the story and no more or less.

Each character should have the following:

NameDescription in one sentenceBackstory

You can find that they are lots of things you work with everyday that if asked to describe you would struggle to concisely explain, for the exact reason that you are so familiar that you never even think about it. Making sure you can describe anything you are talking about in one sentence (whether or not you actually do share those in the talk) can make it much clearer in your mind.

The backstory is also important. Again, this is for you. You will decide which bits to share based on its importance, the audience, and most importantly your purpose. Write as much as you want — what version of that library did you use, did you have any trouble with it, what did it replace. This helps you think about how it fits into the story.

Some of the characters will never be mentioned in the talk, others only in passing. Some will feature in scene setting to help the audience understand the story, others will be introduced organically as the story progresses.

Remember that you are a character in this story! People will want to know a little about you as well. Make sure you are giving yourself an introduction too.

Set the Scene

You should keep the core story as focussed as possible, but it’s likely you will have to do a little scene-setting depending on the audience. Go back to your assumptions and your character descriptions and work out what needs to be understood before your story would make sense.

Do not give the audience more information than they need. They want to hear the good stuff — get to the core story as quickly as is possible.

Edit Ruthlessly

No first draft is perfect. Sometimes even the 50th draft still hasn’t made the cut. Don’t be afraid to completely rework things if you find that they just aren’t coming together like you thought they would. Don’t be afraid to throw it away and start over.

Be aware that if you aren’t cutting things out from your first draft, then you likely aren’t being ruthless enough. Practice it out loud — how’s your timing, maybe running a little long? Go back to the purpose. Cut out everything that isn’t needed — it will hurt. Maybe those pieces will get to feature in another story.

Add an Epilogue

All talks need to have an epilogue. It should remind people who you are and how they can get in contact with you — and maybe even details of a sequel! Make sure whatever contact details you share are ones you are comfortable with anyone knowing.

Be you!

None of these are rules, there is no perfect way to prepare or give a talk. Be you, and you’ll be awesome.

If you do want to use this to think through a talk, you can find a worksheet to help you here: https://speakerdeck.com/virtualgill/planning-a-technical-talk

If you found this article useful or interesting, please 👏 below or share it with others. You can also follow me here, or on twitter @virtualgill.


Published by HackerNoon on 2018/04/05