2013-03-30 10:34:42 by jdixon
This is not your typical conference review. This is a braindump of my thoughts following the organization and execution of the 2013 Monitorama Conference and Hackathon in Boston (Cambridge), Massachusetts.
I've organized three conferences now: DCBSDCon, a 2009 Washington DC-based conference covering the BSD operating systems; the 2010 inaugural Surge conference in Baltimore, MD; and of course, the just-finished Monitorama event. The aforementioned events went well enough to suggest that I'm a capable organizer and could try my hand at a self-bootstrapped event (again). The BSD event was financed largely off credit cards (huge mistake), although thanks to the help of a good organizer friend we were able to break even. Surge 2010 was a hugely successful measure of the popularity of learning through our shared experiences; however, it was an enterprise of my employer and as such, I was not operating under the same strict financial constraints that affected DCBSDCon.
As an organizer it's in my best interests to put a good face on the event, regardless of what's actually happening behind the scenes. This year (well, starting in August of last year), I embarked on this journey with a number of guiding principles:
- The event should be accessible to everyone who can afford travel and accommodations.
- The event should result in a measurable improvement to the Open Source monitoring toolchain.
- I will avoid spamming the community in an attempt to drum up traffic and registrations.
- I will be as transparent as possible with the organization and operation of the event.
- Sponsors should be an active participant but not dictate the theme or flow of the event.
Largely, I think the event was a success for each of these goals. The cost of attending was low; we had measurable improvements, bug fixes, and new projects introduced to the monitoring toolchain; registrations were overwhelmingly generated through word-of-mouth; the conference website, hackathon details and issues were public repositories on GitHub; sponsors gained direct access to and feedback from a large audience of motivated buyers.
Of those five goals, the one I'd like to improve upon the most would be the transparency of the organization process. Traditionally, conferences have been largely commercially-driven entities and opaque to the general public in the way they are organized and executed. I've become a huge fan of smaller, independently-organized events and hackathons. These are generally more fun to attend and have a much higher return-on-investment, both intellectually as well as financially. Any knowledge or experiences I can share to help others bootstrap their own events benefits us all.
As with anything in life, preparation is key to success. Organizing a conference is no exception. Give yourself plenty of time. Even though it's technically possible to put together a successful event with a short lead time (DCBSDCon came together in three months), the stress levels will affect your personal and professional lives. It will infect your schedule, absorbing all of your free time and resources.
Document everything, preferably in a revision-controlled medium. I prefer to document all of my thoughts and tasks in GitHub gists. I can work offline when I'm traveling, but have access to a mobile-friendly interface when I'm running around during the live event.
Never take anything for granted, and buyer beware. Choose your vendors carefully and get samples of everything. Ask around and search online for references. Get multiple quotes and don't be afraid to use one against another for a better deal; but never sacrifice reliability or timeliness for a lower price. Read the fine print on the contract.
I've started to see smaller conferences that aim to operate without assistance from sponsors. I understand why they want to do this. They feel that sponsorships distract and/or dilute the purity of the event. I empathize with this sentiment, but the benefits of a well-orchestrated sponsorship program far outweigh the inconveniences, in my opinion. By removing sponsors from the equation you are forced to raise the cost of your event, immediately excluding large portions of your potential attendee base. Sponsorships are a great financial equalizer.
With that in mind, there are good ways and bad ways to introduce sponsorship to your event. As someone who has experience as a technical conference attendee, organizer, and sponsor, I abhor the traditional exhibition format. Once you adopt this format you stop treating your attendees as respected partners and content generators; they become cattle that you must herd into the exhibitor trough as frequently and extensively as possible. Interactions with marketing coordinators center on lead generation and conversions.
Conversely, I've become a huge fan of the way DevOpsDays handle their sponsorship program (note: they may not be the first to do this, but it was the first time I encountered it). Premier sponsors are granted a short window to demonstrate their product directly to the audience, rather than having to coerce them to visit their booth or share their personal data. Feedback I've gotten from sponsors prove that this is a measurably better way of reaching consumers and making fans of your service. With one caveat.
If you are a sponsor, understand that it is your responsibility to demonstrate your product and stick to your allotted time. Believe it or not, I'm particular about companies that I will accept sponsorships from. I turned away multiple sponsors this year because their product or service was not appropriate for this attendee base. The worst thing you can do at these [technical] events is to send your sales rep up on stage with a deck of talking points and never get around to actually demonstrating your product. Running over on time is only slightly less unforgivable. It makes things awkward for the organizer, inconvenient for the attendees, and is downright disrespectful to the remaining speakers. Put yourselves in the place of your attendees; they want to see how your product will make their lives easier, but they don't want to be feel like they're being pitched a used car.
Beyond all other aspects of a running a conference, having quality wifi and internet connectivity is probably the single most vital factor to executing a successful event. Certainly we all want our attendees to put down their laptops and phones and pay attention to the speakers. Despite this, if your network is crap (or simply inconsistent) you will hear about it and it will become a distraction. Ensure that you have good internet access, despite the high costs associated with it. Find somewhere else to shave your expenses.
We were limited to, but thankful for, the wireless network at the Microsoft NERD Center for Monitorama. They provide a robust 100Mbps wifi connection for the conference venue. Despite the fact that we had occasional glitches and upload issues, it was strong enough to satisfy the needs of 230 technical users with heavy wireless usage patterns. Speakers and sponsor presenters were able to perform live demonstrations over the internet with nary a problem.
Room for Improvement
Despite all of our successes, there are still areas I'd like to improve upon. I love the single track format and I think this event went really smoothly. We stayed on track for the most part and were able to make up time as needed to finish each day on schedule. But these days were physically and intellectually taxing. Attendees need more time to take breaks and socialize. We need a way to provide more flexibility without introducing the hazards inherent in a multiple-track format.
Inclusivity. The tone of the event was overwhelmingly positive, but to look over the sea of faces was a stark reminder that the DevOps/WebOps community is largely comprised of white males. As an organizer my powers are limited as to the makeup of the attendee base, but I can set a better tone by introducing more diversity in our speaker lineup. This event is entirely a byproduct of my own existing relationships with fellow developers and speakers. It was curated according to a vision I have of the people I wanted to see on stage conveying their passions for the monitoring toolchains. And yet, despite the fact that this was a huge success, this serves to reinforce the bias towards white males dominating our community leadership. Future events will have a call for participation and a marked change in direction, cultivating diversity wherever possible.
This is all I have to braindump at the moment. I fully expect to read blog posts over the coming days about how awesome the event was, and I am eternally grateful for everyone's participation. I will resist the urge to talk in greater depth (or length) about my experiences at the event, but I'm open to share more of my philosophies and processes in future posts if anyone is interested. If you've made it this far, thank you for reading everything I've had the energy to share.
Monitorama 2013 Boston