Øredev 2013 or How I Learned to Stop Worrying and Love The Talk

by Thomas Brady in ,

I am an unduly blessed person. My talk, "Shakespeare in Dev" from Øredev this year was, in part, about just that: how fortunate I've been. I mentioned, for instance, that I got my really-real start in "computers" due to a mix-up in paperwork. I was intended to be working in a warehouse, at Compaq, unboxing returned computers and putting them on a conveyor belt, from 11 PM to 7 AM. I didn't escape the night-shift, but the paperwork mix-up did put me on the other end of that conveyor belt, in charge of refurbishing the returned computers. I had not seen the inside of a computer, but for a brief experiment in swapping the 5.25" floppy drive in my 486SX for a 3.5" floppy drive, about ten years earlier.

A similar opportunity came about six months ago. Co-worker Jesse Cravens asked me if I'd be interested in co-writing a book with him about Ember JS, a book we're hoping to have finished before year's end. That, and Jesse's extensive conference speaking experience (he's done 12 this year, and he's not done), led Øredev to invite him to speak at their conference this year. Jesse was kind enough to ask if they'd be interested in having the two of us co-present on our book, and the Øredev organizers were beyond kind in extending the invitation to include me.

They like to ask their speakers, many of whom they're flying into Sweden from all over the world, to do two talks, so as to get their money's worth. The theme of the conference this year was "The Arts," the corollaries between the programmer's craft and the artist's, as well as the pure inspiration that could be drawn from the arts.

I submitted a few ideas for talks that I could do, trying to stick to that theme, and the one they chose was "Shakespeare in Dev." It was pitched as a survey, a crash-course in the user of story-telling in user experience/interaction design.

The trouble was, right off the bat, I felt like a fraud. I have some experience. I have some knowledge. But I didn't feel like I would be able to talk for 50 minutes to a crowd of people who could easily be ten times as knowledgable and experienced in user experience design. I decided I would study up. I'd pick up all the books, and become an expert over the summer.

To start, this was a bad plan. This was a really bad plan. I have two children and a full-time job for Pete's sake. I barely had time to write a talk—I didn't, really, let alone read 15 books first and then write a talk. Not to mention that part-way into this time period, I decided to take on some freelance work. Goodbye free time.

This worked out for the best, though. If I had found or made the time to read all 15 books and synthesized them into a succinct overview of the topic of story-telling as a design tool, I would have succeeded in creating a painfully boring talk. It might have been insightful. It might have been well-informed. It would have been boring. I wouldn't have provided much, if anything, that the audience couldn't have had by reading the same books.

Thankfully, at the last minute (I finally finished up my freelance work just a couple weeks before the conference), inspiration struck. I realized that the aspect of story-telling that was most interesting to me was the fact that it's a discipline-agnostic tool. It's not a super-specialized tool that you have to spend years honing in order to be good at it. It's not like oil-painting, or using Photoshop, or mastering object-oriented programming. I believe it's a nearly universal skill to all humans. Some of us are better at it than others, and you certainly can hone it to become a skill like oil-painting. But at basic proficiency, the average person can tell a story that can have a profound impact on the world around them.

I was interested in how this could affect the dynamic among a team working on a software project. It's difficult for everyone on the project to have an impact, or to even participate in the same discussion, much of the time. Story, I thought, might be just the thing, just the tool—one that everyone on the team can implement with roughly equivalent skill—to be shared by the whole team, giving everyone equal impact on the work to be done.

While I was thinking about all of this, I reflected on my own career, on the saga of developer versus designer versus QA reviewer versus project manager. I remembered the day it all clicked, the day it all began to make sense to me, because of something a designer named Michael Chang said to me, a story he'd told me.

That was it!

I started over, after spending four or five nights on the talk, about half the time I had left. But I felt hopeful, now, finally, that I had something to say. If I'm telling my own story, there's no right or wrong. There's nobody with more expertise in the room on the topic. And, best of all, I was now telling a story, not just talking about telling stories.

This was my first time speaking at a conference. I was terrified. I've spoken publicly plenty of times, at company functions, at church. I've acted in plays and skits in front of large groups. I've played guitar and sung in front of relatively large crowds a couple times at least. Nonetheless, I was terrified. I barely slept the night before, and my stomach was upset the whole day of my talk. I barely ate.

And to put a little bow on it, my two talks—my personal talk and my joint presentation with Jesse—were back-to-back. Well, at least I'd be done afterward!

Oh, and they put me in the big conference hall—the same one they were using for the keynote presentations.

I'm told it went well. Watching the video, I'm pretty happy with what came out. It's not perfect, by any means, but I do think it's about the best I can do right now.

If you're reading this and considering talking at a conference, here's what I wish I'd known, or thought about:

  1. Have something to say. Figure out what someone attending your talk needs to know, or what you most want them to know, and figure out whether it really matters. If not, start over. While you're at it, have something unique to say. If the conference attendee could get your content somewhere else, why would they have paid likely thousands of dollars in conference admission and travel expenses to hear it? If your content isn't unique in some way, start over.
  2. Learn how to use a microphone, and be aware of it. Don't be shy. Make it easy for your audience to hear you. Don't blow your nose, scratch your beard, etc. into the mic. If you know you have a cold, work out with your sound guy how you're going to mute the mic when you need to blow your nose, use your hankerchief, etc.
  3. Don't compare yourself to other speakers. This should be an idea meritocracy, if there ever was one.
  4. Do entertain. Don't be boring. You don't have to tap-dance, but it doesn't hurt to relax a bit, share something personal, crack a joke (but don't force it) or generally demonstrate that you don't take yourself too seriously.
  5. Your slides matter. You may not be a designer. You may fancy yourself a designer. Either way, get some help. Ugly, confusing slides are going to distract your audience. NO CLIP ART. NO CHEESY STOCK PHOTOGRAPHY.
  6. Don't look at your own slides. Definitely don't read them. Look at your audience. Presenter's notes are okay, but don't read them. Practice your talk enough that you pretty much have the outline memorized. Put the outline in your presenter's notes. Use them to help you remember where you are, maybe even specific data points (any actual hard numbers you need to get exactly right, quotations, etc.), but do not read them out loud.
  7. Keep your slides simple. You don't need transitions, builds, and all that stuff. Once you're good at using slides without that stuff, you'll have a better idea of when to use them. Don't use sound or video unless you absolutely need them. The audience wants to hear you, not something canned that they could have heard without spending all that money to get here.
  8. Bring some water. If you're nervous, it can save your life.
  9. Consider the possibility that people are going to ask questions afterward, either while you're still on-stage or otherwise. If you can't answer a few questions well, you can squander whatever credibility you built up during your talk. You can end up discrediting yourself and your talk.
  10. Give yourself a break. It's harder these days. With Twitter and such, you can't fail in private anymore, but neither can anyone else. Your first talk might suck. That might be enough for you to figure out this isn't your deal. It might be motivation to practice. Either way, it won't end your life or career. And, you might not suck! You definitely might not suck as much as you think you did!

For reference, you can watch my talk, "Shakespeare in Dev," here.