How to succeed with Tech Talks
Giving a talk at a meetup or conference is a great way to boost your confidence and showcase the technical skills within your organisation. But public speaking can be daunting at first, and many people are skeptical of the value of their experience.
Since 2012 I have been helping people working in technology to devise and give tech talks (through training, mentoring and via various meetups and conferences that I run); based on that experience, plus my own experience of speaking at meetups and conferences, here is my advice for how to succeed with tech talks.
I have captured this advice in a free downloadable PDF, too:
Discover your story
Everyone has a tech talk in them! Many folks think that their experience is not interesting or not worthy of sharing but in my experience (based on over 100 people I have mentored through tech talks) everyone has a good story to tell. The key thing is to find the right narrative to make the talk compelling.
Consider the work you have done recently. Some aspect of that work is new or unusual, or perhaps you overcame a challenge within your organisation.
There are many aspects to the work you’ve done that can make it interesting:
- New use of tech
- Collaboration
- Team changes
- Learning from failure
- Size / Longevity
- Risk and Impact
How could you show your organisation in a good light? What really fires you up?
Prepare your narrative
As any school teacher for literature will tell you, the key to preparing a good narrative is PAF: Purpose, Audience, Form.
- Purpose: What is the purpose of the talk? What are you trying to achieve?
- Audience: Who is the audience? What is their background and level of knowledge? What will they expect?
- Form: What form will your talk take? A demo? A single thread of narrative? Several examples? A song?!
This is really the most important part of preparing a tech talk (an indeed, any talk) because if the narrative arc of your talk is compelling, you will much more likely convince your audience than if you simply run through a list of new technologies you have used recently. Narrative is at least 50% of the “magic” in a talk.
It’s also really a useful discipline to summarise your talk outline in a single slide of 3 or 4 bullet points. Once you can summarise your talk in just a few bullet points, you know that you have yourself understood the essence of the talk well enough to be able to convince other people.
Write your proposal
Over the past few years, for meetups and for conferences such as PIPELINE Conference, I have reviewed over 700 talk proposals. What’s clear from looking at talks that were accepted and those that were rejected is that the people who submitted successful talks are generally those who have clearly read the talk criteria carefully. Talk proposals that seem to be just copy-paste from another proposal often stand out as not relevant and are often rejected.
So, read and re-read the talk proposal criteria.
Also, take care to explain exactly what attendees will learn from your talk. Make it clear in 3 or 4 bullet points what people will get out of your talk. If you cannot characterise that, then why should anyone bother to come? If you like, treat this as the “acceptance criteria” of your talk: people can then judge if your talk met the criteria!
Practise your talk
You need to practise your talk in a real setting, preferably several times, before you give the talk in public for the first time. It’s simply rude to use a public event to try out your talk. Things that I do (and you should) before giving a talk include:
- Run through the talk in real time in front of a webcam/Skype - just myself. This is to ensure the timing is about right; do I need to cut out some material?
- Run through the talk in real time with a colleague or critical friend. This is the opportunity to ask if any part of the talk does not “flow” or does not make sense.
- Give the talk at a local meetup group or at one of your company’s Lunch & Learn sessions.
When giving the talk, focus on one pair of eyes at a time in the audience. Speak slowly enough for a non-native speaker to understand you, because if the amplification system is faulty or there is noise from a fan or traffic, people will effectively be like a non-native speaker (even if they are not usually).
