Last weekend there were no less than 100 hackathons happening all over the US and Canada. They were held for a variety of reasons, everything from trying out new SDKs, to causing Social Good. I can’t speak from personal experience, but what I can sense from Twitter is that most of these hackathon were very well run, very organized, very focused on hacking, and generally a very good force in the world. With one notable exception: the Energy Hack event at MaRS.
And worst of all, it was kind of our fault.
For starters let me give you a little background on MaRS. MaRS is a semi-private, non-profit organization, funded largely by government tax dollars with the stated mission to “drive social and economic prosperity and create global businesses through innovation”. They spend many millions of dollars a year. They occupy one of the poshest buildings in Toronto. They pay their CEO about $600K a year. And they have “launched” approximately zero successful companies, let alone global businesses, in their 13 years of existence. In fact there is an almost perfect negative correlation between the good startups and the MaRS startups.
So needless to say there is some tongue-in-cheek joking that happens between the good / real / successful (ish) startups in Toronto about MaRS.
But, they’ve actually been trying to get better lately. They hired my good friend David Crow for a little while, they’ve rolled over a lot of the upper brass (don’t worry :P, CEO Ilse still makes bank), and they’ve apologized, at least in person, for how shitty they’ve been. So when they reached out to us to help them with a hardware hackathon, despite my better judgement, we agreed to help.
OK… Let’s shelve that for a second, and talk about hackathons.
Hackathons are this pretty amazing mechanic of Social Good. A whole bunch of really smart people get together in a room and they work on stuff, often even working together, not for money, or even for fame really, but just because. Because its fun. Because they get to do something different. Because maybe they’ll learn something. Because they work on ideas instead of tickets. And because they get to work with their friends, instead of the assholes they normally work with. If the tech tree from the game Civilization was a real thing, “hackathons” would sit somewhere towards the end of it, probably right beside “open source”.
But nestled into the whole idea of a hackathon, right next to all of these amazingly positive qualities, is their greatest weakness. PEOPLE DON’T NEED TO SHOW UP. And they especially don’t need to stay. And if you don’t respect the hackers, their knowledge, their power and their motivation, they will absolutely and unquestionably “ruin” your event. They will eat your food, drink your beer, and leave. And they won’t ever come back.
Our role as organizers is to be the janitors, the line cooks and the gardeners. Our entire job and our only responsibility is to enable these hackers. Get them to show up. Empower them to hack. Give them a reason to stay. Help them to communicate. Feed them. Fill them with sugar and booze. Bribe them with other smart people. Promise them you won’t do any of the shit they deal with at work. And stay out of their way. Our only job, is to do EVERYTHING POSSIBLE, to enable people to do something that they shouldn’t want to do. At Upverter we try to take it a baby step further and not only provide this type of an environment, but also provide hardware hackers with a product that has most of these ideologies baked in.
Ok, so back to MaRS, what went so wrong that I felt the need to write this? I think there were 3 big things, and 1 giant one:
When the hackers showed up they were presented with a table full of paperwork. This was the first thing they saw when they walked through the doors and it framed and set the tone for the entire event. Before being allowed into the space the hackers needed to read, and sign 3 different documents. Before they did anything. No ideas. No teams. No energy. No whiteboards. Just a giant stack of paperwork. It’s a bit like the difference between the jobs where you have to sign a contract before you meet your co-workers, and the one where you’ve shared a meal, had a couple of beers, met the whole team, and started work before someone realizes you should probably sign a contract. In the end, this goes back to friction. Do they really need to read that right now? Do they really need to sign that? How much better is your event going to be with paperwork, versus how many fewer people will show up?
Rule of Thumb: If they absolutely do need to sign something it NEEDS to be short, to the point, and it needs to be in English, (NOT in legalize).
Look & Feel
The space felt passive. I felt like I was at a conference or a seminar. I didn’t feel like I could build, destroy, or change the space I was in. There was no creative energy (read, chaos). The room was big round tables, a stage, and a powerpoint presentation. No whiteboards. No list of ideas seeking hackers. No list of hackers seeking ideas. It felt a lot more like a workshop than a hackathon, more like a conference than an un-conference. This one goes back to the raw creation that a hackathon is supposed to represent and our duty as organizers to be the janitors to that creation. If a space feels passive then its attendees will act passive. If hackers don’t feel like they can change the space, they will sit and watch, or worse get discouraged and leave.
Rule of Thumb: Make the space and the vibe of your hackathon just as hackable as the APIs, ideas and parts you’re providing the hackers with.
Don’t Try To Teach
The hackers got lectured at for at least 3 hours before they were allowed to begin hacking. There are two big points buried in that. First, you can’t expect to teach the hackers programming, or hardware, or OAUTH, or XML as part of the event. Education is emergent, not scheduled. If they don’t know it they will figure it out. If they can’t code they probably won’t show up. If they do show up, bet on the emergence of the event, and remember that nobody ever learned OAUTH from Powerpoint. Second, you don’t get to tell them what to do. You just don’t. You’re their assistant, not their supervisor - they tell you what to do. This is also another reference back to friction, all of the Powerpoint, all of the “education” that the hackers needed could have just been emailed to them before the event. Its also a reference back to being custodians to the process, not schedulers or managers of it.
Rule of Thumb: Make resources available and help the hackers to learn, but do not ever try to teach them.
This is the giant one. Its probably a sum of all the others. You could feel it in the front desk, the overwhelming lack of technical support, the powerpoints, the space, the paperwork, the twitter feed, etc, etc. MaRS, in my opinion, did not respect their guests. At absolutely every step of the way they should have questioned the things they were asking the hackers to do. Do they really need to do that? Can we do that for them? Does that actually need to happen at the event, or could we just send them an email ahead of time? Do we really need to teach them software development, or oauth, or about our API - or could we just give them a link to a wiki page? They forgot these are very smart people, showing up to invest their time into an event with almost zero payback to them, they needed to be respected accordingly.
Rule of Thumb: Respect the hackers. Do everything you possibly can for them. And be incredibly grateful they showed up.
I think MaRS had their hearts in the right place. They tried hard to organize a successful hackathon, and I commend them for that; It just could have been so much better.
Upverter has organized, hosted and participated to dozens of hackathons over the last three years and if I had to give a single piece of advice about how to make an event successful, it would be “Don’t over engineer the event”. Keep it simple and the smart, industrious and enabled people you invite will amaze you, all for the bargain basement price of a bit of food, beer and time.