As in many other startups, sometimes you fuse several roles together. In my case, it they are a machine learning engineer (official) and a developer relations grunt (unofficial). source{d}'s policy for public speaking and otherwise advocacy has always been very encouraging, and our employees stand at the front side of the IT stage quite often. I've personally spoken more than 30 times since I joined in mid-2016. I enjoyed some of those talks, and I went through some bizarre ones. This post reflects my excitements and hiccups, and gives advice to future software conference organizers how to improve their speaker's experience.

Speakers typically go through the following stages:

  1. Discovering the conference, deciding to to submit a talk proposal.
  2. Submitting a talk proposal.
  3. Preparing to speak and negotiating with the organizers.
  4. Transferring to the conference place.
  5. Attending the conference: give the talk, listen to other people's talks, chat informally.
  6. Transferring back home.

Hence my advice is split into six sections which correspond to those time periods.
Please note that, like many other software engineers, I am genuinely an introvert, although I've aggressively battled with myself to not demonstrate it. Yet still some of the points may be severely biased.
Besides, I cover various conference sizes, from meetups to summits, and what works for small scale may not work for large scale and vice versa.

Discovery

Disregarding the way one finds out about a conference, one is going to visit its website. They want to check whether the conference is worth their efforts. So the design should be good, and the displayed information should be rich. These bits help to engage trust and resolve doubts:

  • History of the previous years: blog posts, photos, videos. Especially the videos, since they clearly indicate the conference grade.
  • Statistics about the expected audience: how many attendees are planned, what's their age and professional level distribution. Speakers may have different preferences: some like to give introductory gags, and some are interested in hardcore case studies. Some are afraid of big crowds and love meetups, and some work in developer relations full time and desire hundreds of listeners.
  • List of the topics which are of high relevance. Many beginning speakers hesitate to submit a proposal as they are not sure if they align.
  • Explicitly write about the travel assistance, including the visas and any compensated costs. Who needs a visa to visit your country? Will you pay for anything? That's important for indie speakers.
  • English-ness of the conference. I know two types: fully English and bilingual. Not everybody is fond of bilingual events because, quite often, the local language dominates.
  • Code of conduct. I know a few excellent speakers who don't even consider participating if there is no code of conduct.
  • Easily accessible venue address. It should not be just a point on the map, but additionally in copyable plain text. Annoyingly many conference websites miss this.

You should show that the conference welcomes everybody by putting stress on the diversity of your speakers. For example, invite members of the local female IT communities. I witnessed some of the greatest talks by non-mainstream speakers, and often the key was looking at a problem from a different angle or touching unusual issues. Let's try to burst the bubble.

Call for Proposal

Let's suppose that somebody decides to submit a talk proposal. They would go to the special "CFP" page on your website. What should they see? First of all, your CFP should have two dates: when it ends and when the acceptance decision is made. So far, only a minor part of the conferences have had the second date, and it is really disappointing. Nobody likes to stay undetermined for an undetermined time :) There can be several decision waves, e.g. you plan to accept the best talks first and triage the other second; in this case, put the final deadline.

Second, explain the available talk types. That is, what you mean by "workshop", "lecture", "lightning", or "keynote". That information is invaluable for beginners. Besides, stating the duration of each type is a must.

Third, elaborate on the talk structure. Will there be questions? What is an ideal duration of the questions session? Are you going to award for the best questions? The latter may be a nasty surprise at performance time: imagine the big stress a speaker has just gone through (the talk) and it suddenly appears that they have to remember the asked questions (of course they don't).

Finally, this the list of things you should ask in the CFP form:

  • Title.
  • Short abstract.
  • Long abstract. Give a chance to people to describe their proposals in fine detail.
  • Link to the slides - if they exist. These augment the long abstract.
  • Were there talks on exactly the same topic in the past? Depending on your conference level, they can be either good or bad to have.
  • Bio. Many speakers have no idea how to write a good bio, so it is better to suggest a certain template.
  • Photo.
  • Company: name and URL.
  • Previous speaking experience, in free form.
  • Contact email.
  • Availability if there is more than one conference day.
  • Nobody has a talk picture so useless to ask that.

You should confirm that a human saw the submitted proposal and it went under consideration. An automatic answer is not so nice, although certainly better than nothing. Do not miss your own deadlines. If you reject, try to explain the reasons why. Receiving too many submissions is a cheap shot which experienced speakers do not buy. Be polite, but straight to the point.

Negotiations and preparations

If you accept the proposal, you enter the next phase. You should inform your speaker about:

  • When you plan to announce the schedule. It is annoying to be accepted but not see yourself on the website.
  • Desired arrival and departure times, and hotels, if you buy tickets and accommodation.
  • Recommended arrival and departure times, and hotels, if you don't. Is there AirBnB in your city? It is a good way to cut costs.
  • Emergency contacts. These are important! I forgot my laptop in Schiphol airport once (I got it back in a few days) and I had to finish my presentation in the evening before the conference. The emergency contacts really helped then and everything turned alright.
  • Casual communication channels, e.g. a Telegram/Whatsapp/etc. chat for speakers. Such chats proved very useful.
  • Whether you are going to record video of the talk. GDPR requires a consent.
  • Will you offer free lunch? Breakfast? Coffee-breaks? After-party? Speaker dinner?
  • Should the slides be 4:3 or 16:9? Will you have a projector or a huge TV)? Will there be dark or light in the room? The answers to the latter questions define the theme (black-on-white or white-on-black).
  • You should only allow slides in PDF or web browser. Mark it, emphasize it, stress it. There were problems with PowerPoint so many times.
  • Are you going to show the slides from your own laptop or allow the speakers to use theirs? In case of the latter, schedule at least 5 minutes between the talks for setup, and organize a "sound-check" before the conference starts.
  • How will you watch the time? Will there be a display in the floor, people showing printed A4 messages, etc. <image of Google IO'2018>
  • Does the venue have gender-neutral toilets?

Basic empathy skills may dramatically raise you in a beginner's eyes: trivial phrases that you are excited to host such a great talk and that everything is going to run awesome are helpful. Imagine that the person on the other end is not very confident, and does not know what to expect. You should try to chill them down a little.
Remote rehearsals guarantee better quality of the talk at the price of additional effort by the speaker. They should be optional in my opinion, unless your conference is commercial, and you pay for the trip.
When the schedule is settled, please send the talk time individually.
You should accept bio/abstract/description updates at any time. Speakers should be informed about this feature. Rationale: the final presentation diverges from the initial concept sometimes.
Run a spell checker against the bio and the abstracts and offer your edits. Stupid spelling mistakes damage the conference's image much, at least for me.
You should recommend uploading the slides to a cloud: speakers lose flash sticks or even laptops from time to time.
It is a good idea to advertise talks on Twitter, since you are likely to get free retweets from the engaged speakers.

Trip

Your preparations stay behind, and it gets hotter.
It is important to follow-up the speakers few days before the conference starts. Everything happens: the busiest of us may forget, some may fall ill and don't notify.
Write how the speakers are supposed to get to the hotel. Numerous times I struggled to find the best route in unknown cities, and sometimes I regret my choices. For example, it was a bad decision to take a train from Paris' Charles de Gaulle while the workers were on strike. You should arrange a taxi at night time, even if you don't buy anything else. Some cities have a terrible taxi service: no Uber, cards are not accepted, one needs local currency, no English-speaking drivers, a language that many cannot read and write. Do inform the speakers about it!
It is better to organize the speakers' dinner before the event. That way the speakers may have a chance to relax, to exchange experience and to ask questions. Bonus value: you ensure that your speakers have safely transferred.

Talk

The conference day is the culmination of your affairs and efforts. You shouldn't relax.

Schedule

  • If you run parallel tracks, do not put your only two ML (backend, frontend, etc.) talks in parallel. This makes your speakers compete and demotivates.
  • Do not make attendees go from room to room. This brings chaos and sloppy talk beginnings (people enter late) and closings (people leave early).
  • It is risky to put the best speakers in the first slots, unless you allocate time for a proper opening.
  • You should never intersect talks with lunch time. Better to have fewer speakers.
  • The gaps between talks should not be 0 minutes. That's a straight road to screwing up your schedule.
  • Never "switch off" a speaker if your schedule "leaks".
  • If you list "breakfast", "lunch", or "coffee-break" in your schedule, expect people to think that the food will be (at least partially) free. Put a note that the food price is not included!
  • It really sucks to have a crowd of people going out of the building deliberately searching for a place to eat during the break. You should have it in the venue for many reasons: time, communication, focus, etc.
  • An after-party is a nice site for informal communication between speakers and regular attendees. If you conduct an after-party which takes place in a different area, write its address on the website, send it by email, tweet it, etc. Several times I saw "after-party" without an obvious address, and went to the main venue only to discover that my beer waited somewhere else.

Equipment

  • You should prepare all possible display adapters in the conference rooms: Thunderbolt to HDMI, DisplayPort to HDMI, micro HDMI to HDMI. Please don't use a VGA projector; otherwise offer an HDMI to VGA.
  • I am yet to see USB3 laptop chargers which seem to be a emerging standard. They can be of great help, and finally close the issue with going to sleep right during a talk.
  • You should offer a clicker (wireless presenter). Few speakers have it. A clicker allows them to get their hands busy and reduce the stress level.
    Please do not debug problems with the projector/HDMI connectivity right before the conference starts. However, do check how everything works once again 15 minutes before. I still remember the failure on the first Russian GopherCon when something went wrong within the last hour and the organizers had to entertain the crowd for almost 30 minutes.

Questions

  • It is smart to use a specialized online service for questions such as sli.do.
  • If you plan to award for the best question, you should notify the speaker right after they finish the main part.
  • Ask the speaker to repeat the questions if there is no mic.

Misc

  • A small number of lunch tables makes attendees compact together and encourages communication.
  • Another way to break the ice is to ask each attendee to introduce to their neighbors.
  • Lunch menu: there may be vegans who also want to eat.
  • I saw a brilliant idea with exit polls to gather feedback at the entrance. There was a girl holding a tablet which showed three smileys. I guess that a human improves the feedback collection rate the same way as a free newspaper giver is more efficient than just a basket with newspapers.
  • Don't spend all your time with speakers you already know. Don't talk all your time to attendees you already know. Unless your conference is invite-driven, you will show unnecessary elitism and discourage the rest to come next year.
  • Foreign speakers are quite often abandoned in the speaker room and feel lonely. You should do your best to make everybody speak English. On the other hand, mind the jet lag: some may want to sleep.
  • A few local presents for the speaker are always appreciated! If you decide to give them, include some branded stickers. Collectors will demo your logo on their laptops for free.
  • Going entirely offtopic during the breaks annoys many. Showing tricks, dancing, telling stupid jokes, and stand-upping may alienate software engineers, since not everybody has your great sense of humor.

After the conference

You should ask all the attendees to provide feedback. Speakers should be asked additional questions.
Please send a "thank you" email and include the aggregated feedback from your attendees.
Send the link to recorded video when it is ready. The speakers are not going to watch your website and will simply miss it otherwise.

Final words

All the points are based on my real experience. I removed all the references to real people and cities on purpose.
I am going to send a link to this post to the organizers of my future conferences. New IT conferences appear every year, they are often managed by inexperienced people, so my post should help them avoid obvious problems.
My advice may be biased in many ways. Let's discuss it in our community Slack, you can register by following this link. My Twitter is @vadimlearning.

Used images:

  • La Niña, La Pinta y la Santa María. Maritime Museum of San Diego. CC BY NC ND 3.0.
  • El Pregonero. Díaz Olano, 1893-1894.
  • The Preparations for Winter in a Panoramic Landscape. Jacob Grimmer, between 1546 and 1592.
  • The Express Train. Currier & Ives, 1870.
  • Concert given by Cardinal de La Rochefoucauld at the Argentina Theatre in Rome. Giovanni Paolo Panini, 1747.
  • Fatigue. Michele Tedesco, <= 1917.