25 minutes is a bitch

Saturday 6 February 2010

This is the season for preparing talks for PyCon, which is less than two weeks away. I've not only been working on mine, but I organized rehearsals for the other Boston-area speakers, so I've been immersed in the process.

PyCon talks generally have half-hour slots, with five minutes at the end intended for questions from the audience, leaving only 25 minutes in which to get your message across. In some ways, 25 minutes is a long time to stand in front of a crowd of distracted strangers and try to explain something. If you've never done it before, you'll probably feel like you don't have enough to say.

But that isn't true, because if you've chosen a topic to propose for PyCon, and written a good enough proposal to get it accepted, you have identified a topic about which you are passionate. And expecting someone to talk about their passion in only 25 minutes is expecting a lot.

Thinking back over the eight talks I've seen in draft form this past month, they all have something in common: they aren't going to fit in their time slot. The speaker has over-stuffed the talk with all of the things that fascinate them about their chosen topic, and there just isn't enough time.

You have to make harsh cuts to the topic, you have to choose the one point you really need to make, and you need to avoid all the fascinating side alleys and back stories and witty asides you can. You need to make sure that you have a clear arc of a story to tell, and that arc has to fit in 25 minutes.

I use the word "story" intentionally, and it may seem out of place in a description of a programming talk. But no matter how dry you think your material is ("Here's how the __frabbitz__ methods work"), you need to give the listener a reason to care, and that reason will involve a story about a person like them. So you'll want the talk to include at least a little something like, "You're trying to write a program, your job will be much easier if you use __frabbitz__ like this...".

Once you have the arc of the story established, then you can add in asides and jokes and so on. It's important to be engaging and entertaining, but it can't be at the expense of your main points. You have to establish the skeleton of the talk (the main points and how you'll explain them) before you can embellish it with the extra stuff.

Unfortunately, 25 minutes means you have to abandon a lot of your cherished ideas on the cutting room floor. There will be fascinating points about which you are passionate, and you will not have time to mention them.

One important thing to remember: your listeners don't have to leave the room as expert as you are. It may be enough simply to convince them that this is a topic they care about, even if it means they have to go back later and really learn the details. If they go home knowing that __frabbitz__ is important, why it's important to them in particular and have some vague memory of some milestones along the journey, then they can fill in the details on their own, in their own learning style, later. You've done your job by planting those seeds.

For more on presentations in general, take a look at these presentation tips I wrote a few years back.

Comments

[gravatar]
Jack Diederich 1:38 PM on 6 Feb 2010

As I said in a recent post: when you gave your "Whirlwind tour of C-Python" (a topic I had done as a PyCon talk before) I was left thinking "why didn't Ned include X?" immediately followed by "S**t, why didn't I think to leave that out too?" All the best talks could be subtitled "Watch as *name* tries to stuff 10 lbs of fertilizer in a 5 lb bag."

And as far as "story" goes the feedback I gave other Boston presenters was narrative, narrative, narrative. Hettinger, a conference warrior (he gives as many talks in a year as I've given in my life) gave me the cliched advice "tell em what you are going to tell em, tell em, and then tell em that you told em." A talk is in no small part a performance so you have to give the audience what they expect. The same slides and content presented two different ways will be received differently.

[gravatar]
Doug Napoleone 2:57 PM on 6 Feb 2010

I desperately wanted to make it to the PyCon on the Charles events. In the end I was stuck at work. Insane levels of stuck at work, but that is another story.

Every year the program committee struggles with the tome slots. Most professional conferences have 1, 1.5, or 2 hour slots. The problem is that not all talks are created equal to all people. If even if a slight majority of your audience is as passionate about the topic as you are, in an hour long talk, it will be a failure; especially at a conference where it is not kosher to leave in the middle. Even a fantastic talk by a fantastic presenter can fall flat to people.

Example: in 2008 there were complaints that the talks were sub-par, even as the conference was occurring. Being hyper aware of the complaints I was asking people who were walking out of talks what they thought. One person was very upset about a talk he was told would be different, but felt that it just was not interesting, and rather boring. It was too dry, and too much code. It was Alex Martelli's talk, and most people were riveted.

With python, there is such a range and breadth of topics, it is rare that a single talk will have 50% of the audience very passionate about the subject, let alone 70%. A fantastic speaker can make up for that, but those are rare as well, and need a place where they can become fantastic.

PyCon tries to resolve all of this with a number of novel approaches which have worked in the past (but are reviewed and rehashed every year.. ad nauseum...)

1. foster a culture where it is not only ok to walk out of a talk, it is encouraged.

2. foster a culture where even novice presenters feel welcome. You never know where the next great speaker or talent will come from, but we need to give them a chance. This one has come under fire as PyCon has become larger and viewed as very 'professional'. If you only have talks by those whom are already experienced well known speakers on safe subjects, you get... well articulated talking points. Invited speakers seems to have struck a good balance here.

3. Keep the talks short and focused. Explain to the audience why they should also be passionate about the subject. GET THEM HUNGRY.

4. Open Space, BoF, and Followup. Don;t forget to invite your audiance to a BoF or Open Space followup! The part of your audience which is passionate (or has become passionate due to your presentation) are encouraged to continue the conversation, and you the presenter are a key part of that. The session staff will help everyone find space and continue the discussion. Only instead of it being a unidirectional espousing to those who may or may not care, it is a focused discussion by only those whom do care.

5. Lightning talks. There is a reason why the most popular sessions of the entire conference are the lightning talks. Less is More.

In the end the model which I love the most is the TED talks. Look at those talks. How many of them run over 30min? Less than 25%. The majority clock in at 15-25min. Sure there are some rockstar presentations, especially the panels, but the rank and file talks, the ones which people talk about and tweet and go viral, are bite sides, amaze you, and leave you hungry for more.

We are no TED, but it is always good to have aspirations ;-)

[gravatar]
Ed Leafe 3:21 PM on 6 Feb 2010

A few years ago I wrote up one of my first PyCon talks, being careful to leave out all the fluff and just stick to the main points. I then did a dry run, and it ended up being almost twice as long as the available time. I spent the next two weeks slashing out material and honing the presentation until it just barely fit.

Coming up with material is easy. Cutting away all but the essential is hard!

[gravatar]
Jarno Virtanen 12:11 AM on 7 Feb 2010

The 25 minute restriction should be considered a good thing. I've seen too many 45 minute talks that were incoherent, unstructured and just generally boring. Cutting the presentation down to 25 minutes doesn't necessarily make it more interesting, but at least it makes it shorter.

I think it's useful for the presenter to realize that he/she is using the time of the listeners. The presenter better not waste their time. Cutting down the time and the material makes the presentation more efficient.

Furthermore, I think stuffing as much material as possible into the presentation is a bad idea. Have few key points and pound on them. Nobody's going to remember more than that anyhow.

Like MJD put it:

Get to the point as quickly as possible.

Stay there.

Don't repeat; embellish.


http://perl.plover.com/yak/presentation/samples/slide017.html

[gravatar]
Ned Batchelder 6:44 PM on 7 Feb 2010

I never meant to open up a debate about how long the talks should be. 25 minutes may well be the perfect length. I'm just talking about the difficulty speakers face squeezing into it. Maybe that's a good indication: making the speakers do hard work up front could be raising the level of quality in the talks.

[gravatar]
Tim Ottinger 10:47 PM on 7 Feb 2010

I feel your pain, but I think it is right to force brevity. The threshold should not be your passion for talking about a subject, but the audience's passion for listening.

I wrote Chapter 2 of Clean Code (on naming). It actually is the well-edited result of a paper I had written years ago and revised over time. I had a lot of things to say because I'm passionate about good naming. Because I am also involved in an effort to reduce useful topics down 15 minutes + an index card I had to reduce the whole paper/chapter to an index card. I had to think about which principles were both basic and actionable. I had to choose which things to leave out. It was hard, but it crystallized my thinking. My result is http://agileinaflash.blogspot.com/2009/02/meaningful-names.html where it is still too long. I think I could do it better now. Maybe I will.

Add a comment:

name
email
Ignore this:
not displayed and no spam.
Leave this empty:
www
not searched.
 
Name and either email or www are required.
Don't put anything here:
Leave this empty:
URLs auto-link and some tags are allowed: <a><b><i><p><br><pre>.