By Ning Yap
(Watch the official livestream of our meetup presentation at nytm.org or on YouTube)
Being the Expert
I’ve never had to present in front of such a large group before. Generally, the larger the group, the more you might feel impostor syndrome, thinking “among these peers, I can’t possibly claim to be the expert.” But this time, I didn’t feel that at all.
Here was a unique situation where I was presenting on something my team and I had created. Only we knew of the intricate workings of the app, the genesis of the idea, the struggle and breakthroughs, and (at times) even the doubt of its success and viability. We are the experts on all of that. No one knows more about that than us. We were telling our own story from our point of view. We had lived it and it was ours.
Ownership and Being Brave
Sandi Metz gave a brilliant talk at The Flatiron School two months ago where she shared some of her experiences speaking and consulting in the tech field. She bravely acknowledged that even she had felt like an impostor at times, wondering if she was qualified to author a Ruby guide (Principles of Object Oriented Programing in Ruby) or to consult on a project and claim that things should be done as she recommended. For years, she even avoided giving talks altogether!
Eventually, she realized that sometimes you just have to forget about your anxiety. You have to forget about your ego, and be brave. She told us (and I’m paraphrasing)
You have to own your words and take ownership of your ideas. You have to know that you have a valuable point of view that not only is important for you to share, you must also share it bravely. Don’t step back on your own words. Inspect them, think deeply about them, and then present them like you are the expert. You owe that to your ideas. And it will be far more convincing.
Rehearse, Reduce, Rehearse, Simplify, Rehearse! And Script!
At NYTM, we would be given 5 minutes to talk about Bike With Friends. Our task would be to explain our app — all 4 of us on stage — in a way that was not only clear, concise, and simple, but also conveyed our excitement about the app. The real challenge was not that we were speaking to a large audience, it would be getting our message across in that condensed format. I knew there was a real possibility of us not meeting that mark.
I don’t have to say how poorly our first run-through went the Sunday prior. Each trying to say too much in our individual minute, we reiterated each other’s points, choked on the things we wanted to say, and overall, made an oratorical mess. In a way it was good how bad it was. It was clear we wouldn’t be able to “wing” the presentation the same way we had at our NYC on Rails Meetup at school or at Civic Hack Night/#BetaNYC. By “wing”, I mean “loosely organized” with “things we want to talk about”. We would have to script.
You can read my teammate Anisha’s blog entry on scripting our talk for NYTM (she wrote it before the talk took place). In it she notes how scripting was a challenge for her. She felt it prevented her from expressing her spontaneity and fun personality, limiting her ability to feel out her audience. I agree how scripting limits you. But the limiting is entirely appropriate for this kind of talk. When you have 4 people on stage trying to each get their ideas in, and you only have 5 minutes, you must script!
There are perhaps many reasons to script, but the most important reason by far is so you condense your thoughts into real words and sentences. Yes, you do want to have the freedom to phrase things how you wish on presentation day. But no matter what, you have to say it some way, and better to hash those options out on the page first.
To clarify: By script I don’t mean just an outline with bullet points. I mean actual, fully-worded sentences like the ones you might see on a teleprompter for a stump speech. Yes, there is an off chance that you may come up with that brilliant line that most expresses what you want to convey on the spot that day. But there is just as likely a chance you try to go off the cuff and say the exact wrong thing (or just confuse the hell out of your audience).
My team quickly saw the value of a script each time we rehearsed. It became very clear that there were certain versions of our explanation that were more — to borrow a Ruby programmer’s phrase — expressive, meaning concise, what you actually want to say, and anyone seeing it knows exactly what it is.
Numbering our points, grouping and condensing related examples (such as the badges we wanted to cover), transitioning to the next speaker or even to a new segment of the talk with that perfect phrase, these were choices that having a script allowed us to make and keep track of. *Special thanks to Google Docs for allowing group collaboration on a single document which is absolutely critical when you try to hammer out something like this in this sort of timeframe :)
Through this slow process of making these decisions jointly, our talk was distilled into a better version of itself after every rehearsal. And since we all knew what each person wanted to say, we could help them with that process and let them do it in their own words.
Getting the Flow Down Pat
What about the downsides of scripting and, subsequently, rehearsing? That our personalities would die through the process, our jokes would be canned, and we would seem totally fake? I’ll hold off on answering that for a minute.
Our next issue in rehearsing the script was that we were still way over. Even with a revised script, it was too long (7+ minutes), and we were still stumbling over certain sections. Some badges were just too difficult to explain (like the Biker Gang badge) and some transitions (“I’ll hand the baton over to Josh now to explain further steps…”) were flow-killing.
Here’s where having a script is a major benefit. You not only can make decisions on what to cut as a group, you visually have a map of how to cut and condense certain sections. I took over some of my teammate Josh’s lines. My transition sentence became Katie’s first line. I could cue Anisha’s line about social media and tweeting the badges you’ve just earned by ending my segment with “and you get a Bridge Crossing badge for that.”
With the script, we achieved last minute efficiencies up till even 30 minutes before the event started because we had something we could all look at and edit. We were never without a roadmap, even as the enormity of the task at hand loomed ever closer.
Rehearsed (to Death), and Ready to Crush It!
By the time of the event, we were all sick of our script. None of it seemed funny to any of us. Our rehearsals had been earnest, but definitely lacking in personality. Each of us could mouth the words of the other teammates as they were saying their lines since it was mostly verbatim out of the script. Had we drilled enough, or too much? Would we be understood? Would we be able the convey the fun experience that is BikeWithFriends and the passion we put into building it?
Maybe the title of this section is too negative. Because the talk actually went over better than any of us could have dreamed. All of us on the team were more than just a little surprised, we were genuinely shocked we got so many laughs and such a warm response from the NYTM crowd. They are an awesome bunch, by the way!
We felt very comfortable on stage. The script was on the podium, flanked by the presentation laptop, but we didn’t even need it there. The amount of work that went into the script paid off completely. None of us were lost at all during the presentation. We were easily able to keep the flow of the talk going, hand off the mics to each other, and navigate through the app with complete ease.
Though nothing happening on the stage was extemporaneous, with the energy in the room — and our own adrenaline and hearts racing — we could feel our words connecting with the crowd as if they were spontaneous. After the first laughs, right after Josh said “our app does none of these” and waved his hand horizontally, we knew we were going to be fine.
The Code to Crack The Nerves
I know this blog entry has said nothing about our app, BikeWithFriends. Yes, the topic which you choose to speak about needs to be exciting on its own merit. But actually presenting something provides its own specific challenges.
Just like how you might approach a coding problem, breaking down and controlling for as many variables as you can, we approached this presentation in the same manner. The most obvious unknown was probably “how do we handle our nerves?” Would we break down in front of the massive audience at Skirball, unable to form even one coherent sentence? We couldn’t let that be a possibility.
Instead, we wrote a code: the script. The rehearsals amounted to refactoring that code to guarantee that it ran smoothly and efficiently. Even if we couldn’t control for the nerves, we prepared and “coded” for all the parts we could control: what we would say and how we would say it. Once we were on stage, I remember stumbling on some words here and there. But that didn’t matter too much. The nerves didn’t knock me off my game because — channeling Sandi Metz — I was the expert on the topic, I had prepared and rehearsed exactly what I was going to say and knew exactly why I wanted to say it.
The event really flew by for us. We had less than a week to prepare for the talk, but all the pieces somehow managed to fall into place. It certainly helped that we had already presented our project twice before the event. I’m sure I’ll have more thoughts about how to structure a talk when I have to do it again, but I am glad that it’s over.
Perhaps the final side note I have is that once you are onstage, near the mics, be careful what you say. Especially if there is a livestream being captured for the event. In our excitement, one of my teammates may have used some colorful language, exclaiming “We’re going to #$%@ crush this!” Oops. But, in the end, I’m so glad we did.