dotConferences differ from most tech events in many ways, some of them inspired by TED, some others learned the hard way. Today I want to explain how our curation process works and what we look for in speakers.

In no way is this an attempt to argue we do it in a better way than others. Each conference is unique and has a different set of goals and requirements.

Ours are: being single-day & single-track (which means we can only have ~10 speakers), having short TED-like talks, gathering large audiences and optimizing for impact.

With that in mind, here are the main points we do look for in speakers. You could also call them biases, which is fine because they are transparent:

• Open source contributions. Definitely the #1 criteria, for two reasons. First, it aligns with our own values: we are strong Free Software supporters and love to give back to the community. But more importantly, being the maintainer of a popular open source project or being involved in a standards committee is actually a very good proxy for a number of other qualities! Among them: technical expertise, peer validation, can-do attitude, communication skills, …
• Speaking experience. Delivering an impactful talk in front of 500+ developers is better done with some previous experience in smaller events. In addition to boosting one’s self-confidence, the direct feedback coming from smaller audiences is invaluable to improve speaking skills. Being able to watch previous talks in video also helps us a lot!
• Independence. We have a firm, outspoken stance against paid speaking slots. This is ultimately a matter of trust with our audience, and even if they are not on any company’s payroll, we want our speakers to be on stage because they genuinely want to share their ideas, not because they have something to sell or any kind of vested interest. This also means we try to avoid have multiple speakers from the same company on stage.
• Recommendations. As our community of previous speakers grows, we receive more and more ideas and feedbacks on new speakers. Having experienced our stage and format once, they are the best source of new contacts and helpful feedback we can think of. To make this process more transparent, we have announced co-curators for 4 conferences so far: Thomas Bassetto (dotJS), Maurice Svay (dotCSS), Dave Cheney (dotGo) and Daniel Steinberg (dotSwift).
• Exceptions. All of these rules are obviously meant to be broken at some point. We did feature first-time speakers in the past, and will continue to do so. Some didn’t even have a GitHub profile. The criteria above are only indicators and one minute of insightful discussion together is worth a thousand GitHub stars.

To make this even clearer, here are a few things we don’t explicitly look for:

• Specific topics. We almost never ask speakers to talk about something specific. Our recommendation is to choose a topic that makes them passionate, while obviously being relevant to the audience. Feeling excited and “fresh” about a topic is the best way to deliver a great talk. Our job is to help speakers find that topic, not pick it for them!
• Gender & background. We deeply care about diversity and we feel that as curators we have a duty of representation. Conferences where speakers have diverse backgrounds and profiles are that much richer and interesting. However, we refuse to have any kind of quota involved in selecting speakers. Doing so would clearly be easier and avoid some misinformed tweets, but it would ultimately be harmful & disrespectful to the speakers we invite.
• Neutrality. Also known as “we are not Wikipedia” ;-) We welcome and actually encourage independent, strong, and sometimes unconventional technical opinions on our stage. We, on the other side, must remain as neutral as possible in order to be an effective platform for informed arguments and hopefully, progress.
• Resources & location. We are usually able to cover travel & hotel expenses for speakers when their companies can’t. This allows us to even out differences in locations & employers that may have prevented us from inviting some speakers, resulting in greater diversity!

Finally, a few things we try to avoid:

• Product pitches. 90% of the talk proposals we receive have good intentions, but would turn out to be direct or indirect product pitches on stage. Our rule of thumb is “would someone who will never, ever use this product find this talk as interesting?”. This unfortunately rules out almost all submissions, but makes the conference much better in the end.
• Talks already published. As we want to contribute new ideas to the community and keep the conference interesting for our attendees, we prefer having talks that have never been filmed before in a short format.

You may now understand why we don’t have a formal Call For Paper. We tried it in the past and ended up turning down almost everyone, which made us feel bad for the time involved in submitting their proposals.

However, if after reading this you think you would make a great speaker, please send us an email!