November 11, 2017

Lessons learned from six months of refining a presentation

I've just completed my biggest conference talk to date, to a packed house at TestBash Philadelphia. It was my first time speaking at a single-track conference: I'd never previously been responsible for entertaining an entire crowd, and to make things slightly scarier, I was the closing speaker - it was my job to stop everybody from falling asleep (while also trying not to collapse from exhaustion myself).

I feel like it went really well. I've had some great feedback too, and a couple of requests to take this talk into peoples' organisations. There was a minor technical mishap, but I'd prepared so that it wasn't going to be a problem, and the Ministry of Testing team pulled-together to make sure the audience didn't know that anything weird was happening.

Given the prestige slot at a popular conference, I really wanted to make sure that I got this one right. For that reason, I did two public rehearsals (at a MoT Brighton meetup in May and a MoT Cambridge meetup in September) and an internal presentation to the Medidata team in August. Along the way, I received some really useful, actionable feedback from attendees, so the final version that I gave in Philadelphia was very different to the first version that I showcased six months ago in Brighton.

I thought it might be interesting to compare some of the differences, to show what I learned/adapted along the way, in the hope that this might give you some pointers for how to refine your own presentations.

Snapshot of the first version from Brighton, May 2017:

Snapshot of the final version from Philadelphia, November 2017:

Both decks are also available to view/download on SlideShare:

So what sort of things did I change, and why?

  • Fewer slides. Every previous runthrough had run very long - often about an hour, when my conference slot was only 45 minutes. As an experiment, I tried cramming the existing slides into a 45-minute slot when I spoke in Cambridge, but all that happened was I ended up speaking too fast, tripping over my words, and generally being hard to follow. The easiest way to resolve this was by reducing the amount of slide material; in the end, I removed about 25% of the slides from the first deck. (Note the final version has eight fewer slides than the first draft, but the final version also contains four new slides - ergo I chopped 12 out of the deck.)
  • Fewer distractions. The first slides contained a LOT of code snippets, which were ultimately not relevant - the issues could be discussed without the code, and removing/reducing the amount of code meant that there were less things to potentially bamboozle those who couldn't read it. There were a couple of places where I thought there was value in keeping the code, but I audibly guided the crowd to not be concerned about it. (Example: compare 24-25 on the old deck, to 20 on the new deck.)
  • Improved resource references. Something that completely slipped my mind in the planning stages was that there was no easy way to find the resources that I was talking about, and I didn't want to start putting URLs all over the slides. So I had the idea to create a webpage containing the slides and all of the links, and advertised this webpage at the start/end of the talk. This allowed listeners the freedom to not worry about trying to source the links during the talk, and to be less concerned with trying to scrawl-down information from the slides, which I think massively helped with audience engagement.
  • Visual anchoring. When you're giving a talk which is split into multiple sections, it can be hard for the audience to keep track of where you are, particularly if they're also note-taking. I took the blisteringly simple (and unoriginal) idea of adding a "what is this talk about" slide at the start. Plus, when discussing each of the Continuous Quality activities, I kept a watermark of the section header on the subsequent slide, to help anchor the current section of the talk. I want to give a big thanks to Vera Gehlen-Baum, as I was inspired by her slides from TestBash Manchester which employed this technique. (Example: compare 21-22 on the old deck, to 17-18 on the new deck.)
  • Managing expectations. My talk attempted to convey a variety of activities which would typically be seen as falling outside of a tester's remit, as potential ideas of ways that we can adapt to better fit our team's needs. Attempting to implement all of them at once would be crazy, and they won't all be applicable to every organisation. So I spoke a very brief caveat, suggesting that listeners try to find the one or two which might suit them best. In this way, I allowed each audience member to focus on finding their own small piece of value, and mitigated some of the potential disconnect that might occur if somebody were to think that I was trying to overhaul their career.
  • Bringing back the fun. Given the amount of material I was attempting to cover, I was wary that the talk had the potential to come across as quite dry, or something of an ideas-dump. One way I adapted was by cranking-up the level of GIFs and memes throughout the slide deck, to keep a low level of chuckles throughout (again aiding engagement). But I realised that I could do a lot myself without even touching the slides - small touches, such as opening with a reference to the Fresh Prince of Bel-Air theme tune, falling to my knees in the "confession" section of the talk, and re-introducing a sanitised version of the "F**k Metrics" slide that I'd previously joked about including.

I want to give a HUGE thank-you to a couple of testers who emailed me detailed notes after my Cambridge presentation, and particularly to highlight the constructive nature of their feedback - these are great examples of how to effectively communicate ideas for change. Here are just a few of their suggestions which made it directly into the final talk:

Hero #1: James Thomas:

  • "The talk felt front-heavy. I think you could save some time from the 'who I am' part without much impact on the value of the content."
  • "I would have liked to have seen some kind of map of the structure of the talk near the beginning to help me navigate it and relate the parts to one another."
  • "For a while I thought that the talk was going to be largely about bug reports - because you seemed to have a lot of material on them - but you had a wider agenda. It'd be good to know that earlier."
  • "I wonder whether you could tie the talk structure to a career timeline."
  • "You didn't say much about what skills carry over from the 'old' way of working to the 'new'. That might be interesting to those people who are still in the old and perhaps worried about any kind of move."
  • "I would have liked to see your definition of Continuous Quality on a slide."

Hero #2: Shey Crompton:

  • "Slow down. Particularly when explaining YAGNI so it sinks in better."
  • "Highlight final point on 'Fix it yourself' slide (keep the feedback loop) as it's the most important one"
  • "On the Back to the Future slide, photoshop the 1984 field to say 'Shift Left'"
  • "Add links to the slides you mention specific sites - XKCD slide for example"
  • "Reinstate Fuck Metrics with F*&@ Metrics or something similar"
  • "Change 'Don't over manage' to a positive statement that tells people to 'Do XYZ'"
  • "Reference Grace Hopper 'Easier to ask forgiveness than permission' when talking about making changes to code? (about 2/3 through)"
  • "What you are talking about a lot is being pragmatic. Maybe have the word appear somewhere"

Practice, practice, practice... practice!

I really can't over-emphasise the importance and benefits of doing multiple run-throughs, ideally in as close to real-world situations as possible (performing the talk out loud, preferably to an audience). This was the most confident I'd ever been when going into a talk, and I could literally recite it in my head (something which my jetlagged brain annoyingly decided it wanted to do at 2.30am on the day of the talk). That proved especially useful when the speaker's monitor (which showed me what slide was on-screen, and which one was coming next) decided it didn't feel like working. Allow yourself the time to reflect, refine and repeat, and hopefully your next presentation will be just as rewarding to you.

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket
Comments powered by Disqus