This is a summary of the practices I followed preparing my first public talk at a tech conference–I describe what motivated me to speak in public and how I focused on one sticky core idea with the help of a generative metaphor. This is a collection of ideas taken from books and personal experience that I hope will help others embarking on the same journey.

The motivation to speak

The very first time I spoke in public years ago was to not disappoint a person. It was a short 5 minute talk at a local user event but I still remember I didn’t want to do it at all. The talk was about the benefits of sharing knowledge in the tech industry–the same reason I submitted my first talk to an international conference with topic: Build and maintain large Ruby applications.

I’ve been passionate about large maintainable Ruby applications for several years and really wanted to share my insight to prevent others making my same mistakes.

Deliver an engaging core idea

I wanted to give the audience a memorable story–a metaphor that would act as a springboard to a solution–hopefully the one I suggested.

I wanted to deliver a clear message with a goal that was provoking, audacious but not parallelizing.

Speakers understimate how hard it is to be part of the audience–I was often there and felt overwhelmed by the amount of information the speaker dumped on me and only during my research I realized I wasn’t a bad audience member but rather the presenter was doing a very poor job.

I expected the audience to disagree, agree or have the desire to find out more about the message: build large maintainable Ruby applications is possible with the use of Gems/libraries.

I based the talk proposal on presentations I gave to local groups but realized in those presentation the core idea was opaque–I was describing a series of events with a level of technical detail that would create a cognitive backlog and high risk of disengaging the audience.

In October 2015 my talk was accepted and I started brainstorming and my bedroom wall became the repository for post-it notes with the flow of the presentation.

While brainstorming my past work experiences I realized the core build maintainable Ruby applications was the combination of three things. Three is also the ideal number of items a person can keep in their working memory without being overloaded and it perfectly matched my usecase:

you can build large maintainable application with Ruby with the use of Gems/libraries, automated tests and team diligence

and then I started working on a generative metaphor to make that idea stick with the audience after the conference.

The springboard story

I came up with the generative metaphor of piling recipes ingredients on a messy table top but I wasn’t sure if it would work so I presented it in November 2015 at a local meetup 3 months before the talk as the introduction to another talk. The audience was engaged and I got positive feedback so I decided to use it.

I used vivid details to help making the story memorable like a real cafe in Sydney and I always described it from the point of view of one individual: Stevo.

The metaphor took about 10 minutes of my 30 minutes presentation–three times I moved between the metaphor and more technical terrain until the start of the technical analysis of the problem and solutions.

When I wrapped up the presentation I referenced the metaphor one last time to close off the talk and as a reminder of its purpose.

Divide the presentation in bits to ensure your fit in the timeslot

A series of post-it notes to indicate the areas of the presentation helped me rehearse portions of the talk and also have a mental model of the points without having to memorize a script or read one.

Only once the presentation backbone was set I started working on the slides on my computer.

I was rehearsing the presentation in bits–then the whole ensuring it would fit in the 30 minutes time slot. I started with reading a basic text sketch as the backbone to check the rough time it would take.

I had to make sure I was reading it at a public speaking pace rather then reading pace. Public speaking is around 120 words per minute–more then that and you will make your audience job much harder–check out http://spritzinc.com to get an idea of what word per minute means or on OSX paste in a terminal say -r 120 "I had to make sure I was reading it at a public speaking pace rather then reading pace. Public speaking is around 120 words per minute"

I was initially planning to read the script at the conference but then I found research of how disengaging that is for the audience. When you look at your audience in the eyes rather then reading on a computer you will be more engaging.

In hindsight I wish I did a better job looking at the whole audience rather then just the first few rows. Next time.

Get feedback before the event

One month before going to the conference I scheduled four public rehearsals at local events.

One at a local Ruby meetup in Boulder, one in Denver, one at my office and one at our office in Sydney Australia where the conference was held. It was great to receive feedback and I adjusted things aware of contradicting feedback–some people wanted more technical details other less–some liked the section I dedicated to mindset others suggested to reduce it. Eventually you’re by yourself deciding what to do.

Thanks to the feedback I removed jokes about public figures seen as villains because that might not relate with or upset the audience–I instead used popular movies villains.

A few weeks before the conference I was thinking to ask the audience to fill an anonymous poll with their background related to the topic of my talk to hone the presentation for their needs but I couldn’t mail out all the whole attendees. Using twitter and the local mailing list would have left some people out and instead of getting misleading information I didn’t do it. In hindsight I wish I sent the poll out just for the sake of general information.

Reharse reharse reharse

After the talk people asked me if I memorized a script but the answer is no. I just rehearsed so much the presentation backbone was second nature and exposing the bits was pretty natural. The initial set of presenter notes quickly became outdated and they where more like indicators of what I intended to say rather then what I wanted to say. I often used different wording but when some key sentences sounded off I wrote them down on a piece of paper, strike them with a black pen and wrote the better sentence that I wanted to use. I’d say I ended up memorizing some key sentences to make the most out of them and get to the point.

A month before the conference I started rehearsing twice a week. At first I was recording my voice only and listening back to it while preparing dinner. Then I started using the laptop camera to see myself–this helped a lot–I noticed a few disengaging movements like hands in my pockets or touching my face or in front of my mouth.

I wrote those “bad behaviours” down on a piece of paper to remind me to stop. It worked.

When I rehearsed the full presentation I timed the bits to help measure each section appropriately. In hindsight I didn’t do a very good job since I wrapped up 5 minutes earlier. Looking at the conference video I found out I was speaking fast in some sections so I’d focus on a more balanced pace next time.

I’ve heard conference organizers are happier if you finish early rather then late–obviously not too early. I had a couple of bits sections that I was ready to ditch in case I was running late rather then going faster which usually just makes things worst. I had a remote with a timer that was of great help in finding out how I was doing with time.

Rehearsing by myself helped a lot but doing it in front of people… seeing their facial expressions and hearing their noise, laughter or silence was of great help. At a point I was thinking to print out faces to look at while rehearsing but it turned out to be unnecessary.

I used OSX Keynote and at first I used my iPhone 6 as the remote. While rehearsing the iPhone always felt bulky and one time I almost dropped it off my hands–I caught it while it was floating in the air but I didn’t wanna test my luck on stage and bought a remote.

Get used to the stage

I knew the resolution was 16:9 so I optimized for that.

The day before the conference the excellent organizers gave us time to check the connection and slides on the stage. I was able to ensure the font and images where ok–they scaled bad on a projector in one of my rehearsals. The remote had a green pointer that didn’t have good contrast but I wasn’t planning to use it too much anyway.

I found out there was going to be one track and around 300/350 people listening to my talk… that felt pretty overwhelming. I never spoke to an audience of 300 people before. I knew people coming to this conference were paying between 200$ to 500$ and I thought it would have been disrespectful to be unprepared–but felt good about the amount of rehearsals I did so the overwhelm feeling didn’t last long.

The morning before my talk I did one last run–I felt like I wanted to change a ton of stuff but I didn’t–I decided to stick with what I worked on.

The overwhelming feeling was there before starting the talk but as I moved between the bits of my presentation backbone I was confident what would come next.

During the talk the projector screens went black 3 or 4 times for some A/V problem–I stopped because I was worried the audience would get lost without visual cues but I was able to recover pretty quickly thanks to not memorizing or reading a script. If I did I would have to rewind the mental disk or find the line I was at.

Conclusion

I forgot to say things that I wanted to say and I think I could have been more engaging and speak at a slower pace at times but I loved the whole experience. It was really hard work. I estimate I’ve spent between 60 to 80 hours including reading books to improve my presentation skills.

If you’re curious you can watch my talk here.

Recommended books

• The Quick and Easy Way to Effective Speaking
• Talk like Ted
• The Springboard: How Storytelling Ignites Action in Knowledge-Era Organizations
• Made to Stick: Why Some Ideas Survive and Others Die
• Mindset: The New Psychology of Success