• Print

Building conference programs: it’s about the attendee

The essential principles of conference development.

I’ve chaired computer industry conferences for ten years now. First for IDEAlliance (XML Europe, XTech), and recently with O’Reilly Media (OSCON, Strata). Over the years I have tried to balance three factors as I select talks: proposal quality, important new work, and practical value of the knowledge to the attendees.

As the competition for speaking slots at both Strata and OSCON reach intense levels, I wanted to articulate these factors, and the principles I use when compiling conference programs.

How the program is made

My guiding principle in putting a program together is value to the attendees. They’re why we do this. By putting out quality content and speakers, we attract thinking, interested attendees. In turn, our sponsors get a much better quality of conversation and customer contact through their presence at the event.

Here’s the process in a nutshell: proposals are invited through a public call for participation, and then reviewers, drawn from the industry community of experts, will grade and comment on each proposal. I and my co-chairs use this feedback, along with editorial judgement, to compile the final schedule. For keynotes, and a small number of breakout sessions, we will augment the review process by inviting talks we think are important for the program.

Sponsors and the schedule

No company’s industry position (sponsor or not) means they get an easy ride through the proposal vetting process. That would undermine the trust the attendees place in the chairs and program committee. In the past, I’ve been tough with even the very biggest companies, and it’s not been an easy process for me or them. It is however essential, and I am grateful to those companies and others who respect the process.

A conference schedule decided by sponsor-driven talk placement will soon fail to meet the needs of the attendees, because nobody will reliably have attendee interests at heart.

Sponsors have a vital part to play. Their support enables the event to exist in the first place, and they enable many aspects that make the conference experience great. Sponsor companies are a core part of the technical and business ecosystem on which the conferences are based, and many sponsor employees contribute great technical talks that are part of the editorial tracks.

Attendees make real buying decisions and want to hear from sponsors about their products. O’Reilly conferences have a place for product talks, and those talks are marked as sponsored. Because of our ethos of good content, and our practice of advising sponsors on their talks, most of these talks are also excellent, and on a par with the quality of the rest of the program.

We can always do better

Sometimes, we miss the mark. With hundreds of proposals and a fast-moving field, building a program is data-informed, but still an art. As conference chairs we decide an editorial strategy, which sometimes means great talks are left out because they don’t fit the story we think the attendees will value most.

I recognize and lament that it’s not always a pleasant process. Rejection stings, and with over 1,000 proposals it’s an unfortunate fact that something like 850 talks won’t get through.

Recently, with so much competition in the big data industry, I’ve received more heat than usual about program choices. Some proposers know how to create great presentations, and others don’t. If we select more from those that offer great presentations, it’s with the audience in mind, not bias. I’m always willing to offer advice to help people do better the next time around.

Tips for success

With the call for papers for Strata 2013 coming out, I’d like to ensure we do a good job and have the best options for our attendees. Somewhat masochistically, I want my job in deciding the program to be harder than ever because of the quality of incoming proposals.

I think it’s worth spelling out a few guidelines that will help proposers, especially those from industry vendors:

  • Read the submission guidelines three times over, and take them to heart
  • Think about the audience and the problems they’re trying to solve
  • Talk to us. The chairs and program committee are listed on the web site and we can offer guidance (though no guarantees) before you submit your proposal

Submit your proposal on time

I’ll close by reiterating my recommendation to communicate. We have a process designed to maximize the quality of the conference. That process isn’t perfect, and we can and do make mistakes. To minimize mistakes, you can help. As a chair, I prefer to cultivate ongoing relationships with people in the field. Talk to me and brief me about your technology before the conference program is set, not afterwards. It would be unfair for me to do anything to disadvantage those proposers who followed the guidelines and submitted on time.

Finally, thank you. For reading this far, and helping me, my co-chairs, and the program committee in creating the best program possible. We value each and every submission, whether it makes the schedule or not.

I am always happy to offer advice. You can reach me at edd@oreilly.com.

tags: , , ,
  • Kathysierra

    “value to the attendees… That’s why we do this.”

    So simple, so often forgotten. Thanks for writing this.

    A tech conference — especially one on software dev topics — has an advantage over many other domains, though: we understand and appreciate the value of UI/UX.

    We KNOW that products, services, apps, books, etc. are tools to be *used* in service of a result for the user. If a conference attendee is a “user”, then the entire conference including the speakers are simply a UI into an experience for the user. The best way I know of to reduce stage fright (for a tech geek) is to keep reminding yourself that you are nothing more than a UI, and that like all GREAT UI’s, you’re best when you vanish into the background and enable the user to have an experience that produces a result. But as a presenter, we’re bombarded with a million messages about how to make US (the presenter) look, sound, be perceived as AWESOME/SMART when we’d be trashing most UI’s for drawing attention to their flashiness.

    If I were putting on a conference, I think I’d be asking at every turn the same question I ask as a developer and author: how does this help the user kick ass? What *result* does this produce for the user? Anything else is just ego… Making it about the event and the speakers and the sponsors instead of the only people who make it all possible: the paying attendees/users.

    Again, thanks. I was a die-hard conference attendee junkie for more than a decade before I ever spoke at one. I was a novice and later a power-user attendee, and I believe my experience as a user was deeply valuable when I eventually became willing to present. It is the reason I do not allow anyone to introduce me, and I do not introduce myself. If I am to be a UI, the quicker I can get the hell out of the way in support of the experience I am charged with supporting, the quicker I am doing what people paid to experience.

    • http://eddology.com/ Edd Dumbill

      Thanks Kathy, that’s a wonderful exposition of the role of the speaker. I like how it simultaneously reduces the pressure on the presenter as well as putting the focus back on where it belongs.