The Toggle Talk
As a speaker, there are three things I count on to give a talk:
- Narrative flow
- Speaker notes
My dependence on these elements decreases as I give a talk multiple times, but I use the slides to help me remember where I am in the narrative even if I don’t refer to the speaker notes often.
This fall, I designed a new talk and built it in Twine, a game engine for choose-your-own-adventure games. Each slide was actually an HTML page rendered by the game engine, and the narrative was supplied by the audience choosing from several options. This was a radical departure from my usual method, but I’d practiced it, and tuned it, and wrestled with the CSS and I felt pretty confident I could make it work, even though I wouldn’t have speaker notes or a unified narrative through-line.
Because I hadn’t solved the hosting problem yet, I needed to “play” it from my laptop, but that was no problem – I had a USB-C to HDMI adapter. The talk before mine ran long, but I only have technical problems a tiny handful of times in my talks, so I didn’t think I’d need much time to get set up.
I had reckoned without the USB-C/USB-3/HDMI problem, because it had never happened before. I always present from my ipad, and it’s usually a rock-solid toolchain. So I get up there, I’m rushed for time because of the talk before, I’m nervous because it’s the first time I’m giving this talk, and because it’s so “weird”, and…. it failed. The combination of cable/laptop/projector failed so hard that my computer rebooted and came back looking weird, and I had to accept that I might have just bricked my brand-new work laptop, in front of an audience, in a talk that had already technically started.
I had no slides.
I had no notes.
I had no narrative.
I had practiced, but I had not practiced the complete failure scenario, because it had never occurred to me that it could fail this hard.
I still managed to pull a coherent technical talk out and I only ran 10 minutes short, and honestly, it’s one of the accomplishments I’m proudest of in the last year. Literally everything went wrong and I still delivered value.
Afterwards, when I was trying to quietly dump adrenaline, I could only think about how I had failed to achieve any part of my goals. My hands were shaking, my throat was tight, and I felt a little like crying.
That wasn’t how it was supposed to go!
Later, I got to talk to people who had been in the audience, and they asked questions that they could have had if they’d gotten the real talk. That was cheering. I joked that this was the worst this talk could possibly go, because there wasn’t anything left to fail!
Then I got the speaker evaluation cards, and people were universally complimentary about my poise under tough circumstances. It hadn’t felt like poise, it felt like literal flop-sweat, like a drip from my shoulderblades to my waist. But they couldn’t feel my sweat, they could only experience my description of a brand-new talk focused on something that they had to imagine.
One of LaunchDarkly’s goals for the year is to nurture and encourage customers to feel comfortable telling their stories, whether on stage or in a blog post. To that end, we are offering some people speaker training. Remembering my fall experiences, I solicited nice people on Twitter to come to a beta of my talk. That would give me a chance to try out the tool, the content, the process, before we offered it as a finished product.
I learned so much! Almost all of it was a little painful.
- I need to log in early because I’m a panelist, not a host, so we need to coordinate that so I can show my slides to the webinar.
- I did test my A/V setup!
- I didn’t realize how unnerving it would be for me to talk to dead air. For all of my teaching/preaching/tech talks, I’ve had an audience. I can make eye contact with them, hear them start to fidget if they are checking out, notice their grins and twinkles and coughs to stay connected to them. But obviously, none of that happens when I’m talking into a headset with the audience on mute.
- I need to do some work on the content. Not too bad, but I always have to give a talk at least once to live humans to get the suck out.
- The lack of response makes me so nervous I talk even faster than usual. SLOW DOWN, ME.
- I have to figure out a better way to wrap up/end the webinar. I didn’t think about how to tie it up neatly, because talks work differently.
So this is all great. When I do the webinar “for reals”, those are all mistakes that I’m not going to need to make because I know where they are.
- It is hard to predict how you’re going to fail, but it is possible to build in a reasonable degree of redundancy.
- Tests in isolation are not going to catch systemic problems.
- It is better to degrade what you provide rather than failing entirely.
- Test with a subset of users so you can predict how your solution will scale.
- Don’t get so distracted by your failures that you fail to notice surprising data or silver linings.*
* One of the most beautiful night skies I’ve ever seen was on a winter night in the middle of a widespread blackout. I was stomping across the yard to get firewood, and I happened to look up and see the stars without light pollution. A lot of things had gone wrong, but if they hadn’t, I would not have had that moment of starlight bright enough to reflect off the snow, and the milky way like a second snowy stripe in the sky.
Minneapolis DevOps Meetup