Paired Presentations

May 15, 2011

Often when people talk about public speaking, they are typically referring to an individual speaker. You don’t see much advice for people who present in pairs. When it works out, it is a beautiful thing where the whole is greater than the sum of the parts. When it fails, usually one speaker or the other takes the brunt of the damage. Here are some things that I recommend doing to insure a paired speaking engagement is successful:

  1. Keep it simple and let each speaker own a portion of the presentation on his or her own. This avoids a situation where one person does all the talking and the other just chimes in from time to time. I feel that both speakers need to be perceived by the audience as experts in their own right. It doesn’t even have to be a large section of the presentation that you own – just some section that is all yours. I feel like this works well with people who are new to presenting – I can include them for whatever period they feel most comfortable. The anti-pattern here is where a second speaker in a pair only chimes in from time to time. This leaves them only offering the occasional comment. This can leave a perception of that second person as interrupting the first speaker.
  2. Rehearse together – I know it’s hard to do, but you will both find weak areas in each other’s material. When I’m working on speaking material, I tend to get these ideas that I think are totally brilliant. We’re talking about genius stuff here. I can’t tell you how often I have shared this brilliant material with my partner only to discover that it falls completely flat. It must be an echo chamber in my skull (it is empty anyhow). Better to have a lame idea shot down by my partner than some poor unsuspecting audience. Often, the idea just needs refinement.
  3. The 3 secrets to a good presentation with a partner? Support. Support. Support. Focus on the other person in your presentation. If they rock, then you both are very likely going to look brilliant. If they suck, you haven’t got a chance. Be there to encourage them when the practice doesn’t go well. Be there to provide ideas and alternatives. Be patient when they are struggling and time is running short. Make them feel welcome and like a key contributor.
  4. Have a victory celebration afterward! It’s not often that I get to share a presentation with someone. Two people qualify as a party in my book, so go for it! Celebrate the accomplishment! It’s a big deal when two people can collaborate together successfully to provide a rich experience for an audience. Not many people can do it well.

I’m sure there is a lot of good advice for people who are co-presenting and I’d love to hear it. These are just a few things that I’ve learned by trial and error (a lot of the latter).


Being There – Geek Style

July 2, 2010

I’m getting another lesson in “being present” with people. Specifically my 3 year old daughter. When I’m playing with her, she demands my absolute, complete and undivided attention. Any distraction on my part is a punishable offense – usually by a rather irritated, “HELLO Daddy!” As a part time geek and full time father, I find this requirement to be completely “present and in the moment” often hard to satisfy. You see I’m really the typical introvert – often imagining I’m somewhere else, ruminating on a problem, running some absurd internal monologue, or otherwise just drifting about with my head in the clouds. Apparently children don’t tolerate that sort of behavior particularly well, and in my opinion, neither do teams.

I don’t know much about kids in general, but from what I’ve seen from mine so far they are *extremely* highly interactive creatures. They are avidly absorbing everything in their environments like manic little sponges. They’re asking questions and gosh darn it, they expect the answers pronto! They’re looking for a good partner, someone who is going to attend to their every need. And as a good partner, they are watching you to see where you might be going next. They repay any attention you give them with vigor, enthusiasm and affection. Not a bad dividend really.

Teams are a tougher nut to crack. They are also highly interactive beasts to work with. They are doing a lot of learning, typically trying to understand a complicated domain or design challenge. They’re asking questions and gosh darn it, they expect the answers pronto! I hope you see where this is going by now…

Recently I attended the XP2010 conference. One of the sessions that I attended was on using improv theater techniques to learn to be a better team member (this was facilitated by Mike Sutton – a really fantastic guy). A lot of improv is about being “in the moment.” It was all about making yourself a good partner to interact with. I found it to be a very powerful experience and I felt like I got a lot out of it. For instance, like many geeks, I place a high value on cleverness. But it turns out that “clever” behavior is very hard to anticipate (and even harder to produce with any consistency). So being too clever can make you hard to work with when you are doing improv work – it’s hard to know what you are going to do next. Now, I imagine there are a lot of parallels between improvisation and collaborative, problem solving work. In fact that was really a theme of the conference.

The conference reception was kicked off with a presentation by two jazz musicians. They did a fantastic job of demonstrating improvisational musical technique for us in an entertaining and thought provoking way. Part of the message was about making yourself a good partner, but for them, an equally significant message was that in order to express ourselves truly, we need to learn how to be “in the present”. They ended their presentation with the  following quote:

Yesterday is history.  Tomorrow is a mystery.  And today?  Today is a gift.  That’s why we call it the present.  ~Babatunde Olatunji

So what does all of this have to do with teams? Look, let’s get one thing straight – so much of the “process” that we use on software development teams is all about planning or history. Very little of the process focuses on the work actually being done in the moment. I consider the work in the moment, the collaboration that takes place as we are writing code, as the hardest part of the development process. We have techniques that lead us toward this mode of collaboration like pair programming, but often I find teams resist them. Teams that aren’t able to work in the moment, in the present with each other, are going to be handicapped in the speed with which they can deliver innovative solutions. If you are looking for the place with the greatest opportunity for improvement for your team, try steering away from the process – the planning and the history – and try spending more time in the moment. Focus on the actual work you and the team are doing right now. Give your team a gift – the present.