Don't Throw that Hackathon
These are my slides and a paraphrased summary of my talk from the API Strategy & Practice Conference in San Francisco. You can find the full slides on SpeakerDeck and when the video goes live, I’ll be sure to post that as well.
Let me start by saying, “I love hackathons.” If you’ve ever met me before, that’s probably not a huge surprise. Over the last few years, I’ve literally been to hundreds of them and played every role from hacker to organizer and back. I’ve also founded a couple of hackathon related companies (more on those later) and I’ve been known to write about hackathons occasionally too. These are some observations I’ve made along the way.
So if you’ve ever seen me speak before, you know this obligatory slide is coming already. Believe it or not, despite the handsome resemblance, I am actually not Ryan Gosling. They actually call me Swift. I’m one of the founders of this little outfit called Hacker League and I’m the commissioner of this thing called Major League Hacking (think NCAA meets College Hackathons). I’m also pretty well known for my former role as a Developer Evangelist over at SendGrid.
Between all those roles, I spent a lot of time at these things called “Hackathons”. So let me take a step back and ask the question, “What is a hackathon?”.
Hackathons are these collaborative events where people who make things (developers, designers, hardware people, etc.) get together for some time interval and do what they do best - make awesome stuff. The format that most of you are probably familiar with is the 24 hour hackathon. Hackers get together in the morning and hack around the clock for a full 24 hours. Companies like yours spend time walking around helping them build stuff. And at the end, everyone shows off whatever they hacked together.
It’s an awesome experience. If you haven’t at least been to one, you should check it out. These are some of the big names you may have heard of in the space. These events take place all over the world and range from a room full of developers up into the thousands of attendees.
This is a graph of the events that my startup, Hacker League, has powered since we launched in October 2011. As you can see, the number of hackathons that are happening every month is going up at a pretty spectacular rate.
I don’t have a pretty graph to show this one, but the number of companies getting involved is also pretty astounding. There’s a couple of student events that I work with through Major League Hacking that consistently raise in the mid 100s of thousands of dollars every semester for their event.
So the question that comes to mind is “Why are so many companies getting involved in Hackathons?” Based purely on the rising number of events and the astronomical sponsorships that the organizers are able to raise, there’s certainly something worth investigating here.
Broadly speaking, I’ve broken down the reasons that companies get involved in hackathons into three big categories. Now, you can certainly fall into more than one of these buckets, but I think there’s always one strategy that dominates the others. And each of these buckets has its own optimal strategy for how to approach these events.
The first kind of company is the kind that’s going to hackathons for direct product feedback. A lot of companies want to be like these guys, but it’s the hardest to imitate for sure.
These companies want to optimize their products by going directly to their customers and watching them use it. Developers are the customers of the companies I’m talking about specifically, and what better place is there to watch your customers integrate your products in real time than a hackathon?
Generally speaking, there is some kind of direct feedback mechanism that these companies bring to hackathons. The most successful of these are probably Developer Evangelists because they know to listen for the things that developers really care about and hone in on those.
Here are some companies that you might be familiar with that employ this strategy well. These companies have some of the best developer evangelism programs in the world right now and there’s a good reason for that. The best evangelists aren’t just marketing a product, they’re helping to build it. They’re taking everything they’re seeing at hackathons and piping that directly back into the engine that produces it.
The second category of company that gets involved in hackathons is what I’m calling “Mindshare & Perception”. You guys probably call it “marketing”. I wanted to be less general than that because I think this one can actually be broken down into two distinct sub-categories.
The first sub-category is mindshare. These companies want to associate their brand with awesome stuff so that developers think of them in relevant contexts. For example, if you’re a hacker who is suddenly in need of venture capital for your new app, it’s very likely that you will fall back on one of the VCs that often shows their face at hackathons. That’s especially true if you met someone from the brand there.
Here are some examples of companies that I think might fall into this bucket. If you’re a developer, you probably won’t be surprised by some of these logos because they’re literally on every good event these days. There’s also some relatively early stage examples here. Mindshare is especially important for them because any gained real estate is significantly more than they had before.
The other marketing sub-category is companies that want to work on their perception. Generally speaking, these are larger or older companies that aren’t trendy and cool like the young, agile companies that dominate this market place. The want to put their logos on as much cool stuff as possible so developers don’t discount them when they’re making decisions.
Here’s some examples of those companies. I think these should be pretty obvious for the most part. This is a pretty expensive strategy to pursue and I certainly think there are better ways, but I get where they’re coming from and why they do it.
And that brings us to the last category: recruiting. This is arguably the most and least successful of the three simultaneously. If you get into this one, make sure you do your research about which events you should hit because some are way better than others for picking up top talent.
The math here is pretty simple: the top talent goes to lots of hackathons because it’s a way to keep your skills sharp and meet a bunch of other smart, driven folks. If you go to a hackathon, you may be able to hire them. It’s also a great opportunity to build long-term relationships with the hackers. This is extremely effective if done right.
And of course, here are some examples of companies that recruit effectively at hackathons. Note that I said “effectively” though. For each of these companies, there are 10 that think it’s a job fair and look silly. Make sure you keep in mind that most of the hackers aren’t there to find a new gig.
Now that you’ve seen those general categories of companies that get involved in hackathons, you have a leg up on the rest of the field. Most companies don’t realize that each of those goals has its own optimal strategy to accompany it. They see either the peers or their competitors at these events and want to reap the same benefits. So they jump into it head first without doing any research and disasters ensue. If you’re interested in reading about some successful, real-world examples of these strategies, I would check out this article called “Forketing” on Medium.
So here’s the first big mistake that companies make: they decide that they want to throw their own hackathon.
Seriously though, don’t do it. I know it sounds counter-intuitive: if we get all these benefits out of being around hackathons, why not just throw our own and make the developers come to us? Well here’s the protip: The reasons that your company does hackathons and the reasons that developers do hackathons are fundamentally different. There’s a very small subset of developer whom want to be marketed to and recruited, and usually, that subset isn’t the one you’re trying to hit.
Usually there is a better alternative to throwing a hackathon (especially if you’ve already acquired the budget to do it). I have this killer question that I use to get it out of people.
What are you trying to accomplish by throwing a hackathon?
You’d be amazed how many people haven’t even thought this one through. If you can’t answer it, you need to go back to the drawing board and figure that out first. Once you know what you’re trying to accomplish, you can usually figure out what the right thing to do is.
If the reason you come up with is any of the three reasons I outlined already, your best bet is to sponsor one of the amazing events that exist already. Seriously, go back to that slide with all the hackathons, pick one and sponsor it. They’d be super happy to have your help and I guarantee you can reach your goal there.
Here are a couple of other common goals I hear and some good alternatives to throwing a hackathon for them.
The first one I usually hear is the company that’s trying to acquire new customers or startups to use their APIs. We hear stories about GroupMe and Zaarly and suddenly hackathons become the place to find the next million dollar company.
Here’s another Protip: Hacks are hacks, not startups. A huge majority of the hacks that get built at these things will not exist beyond the event. One of the main value props of Hacker League is that we preserve the history of what gets built. Most hackers don’t want to work on their hackathon project after the hackathon ends. Your Twilio or SendGrid credits run out, your app crashes, you shut down your localhost. Who knows.
The point is, if you’re looking to get long term customers out of the hacks that get built, you’re at the wrong event.
A better alternative might be a Startup Weekend or one of the month-long app developer contests. NYC Big Apps and Evernote DevCup are great examples of events that promote building sustainable businesses over the course of a month and have a much higher retention rate than a 24 hour hackathon.
Another type of company I often hear from is the kind that wants to spawn innovation in their industry. Often these are non-profits or companies that have an innovation or social good branch. They want to support the people that are building game changing technology.
The problem is that most hacks aren’t innovative. It’s really hard to build cutting edge technology in a weekend. Most hacks are actually mashups of APIs and existing tools. There are certainly exceptions to that rule, but you’re gambling if you’re counting on it to make your event a success.
The alternative here is to support the people that are already innovating in your field. That could come in the form of a grant, fund, mentorship, etc. These are some of the more successful examples that I could think of. I bet if you just researched startups that were working on problems that you’re interested in solving that you would find a ton that could use your support. Help the existing folks before you start trying to onboard new people to compete with them.
Other companies just want to meet and support their existing communities. Often they’ll throw a conference or meetup and tack a hackathon on to the end of it because they think developers will engage around the event. The intentions here are certainly on target, but the execution is the questionable part.
Hackathons and conferences don’t really tend to mix well. People are usually more interested in socializing and hanging out with other smart people than building something new. Just providing a good atmosphere for people to network and have fun is actually way more on target than forcing a hackathon on them as a second thought. The hackathon ends up being a distraction and a non-priority and ultimately isn’t as good as it could be as a separate event.
The alternative here is to focus on throwing a really great conference or meetup. These are some events that I’ve seen that do an excellent job of highlighting the community around a company.
A good example of this in action is TwilioCon’s hackathon. The event last year was sub-par because it was crammed into the end of the conference. The quality of the hacks was pretty low and the turnout wasn’t so hot either. This year they ran this thing called “Hacker Olympics” instead. It was much better suited for the fun environment of a conference and went over phenomenally.
So now that we’ve talked thoroughly about why you shouldn’t throw an event, let’s talk about the cases when you should. I’m running short on time, so I’m just going to briefly talk about these points. I may expand on them further at a later time.
The most obvious reason that you should throw a hackathon is geography. Cities that don’t have a lot of hackathons happening in them are prime targets for companies to come in and run hackathons at. A great example of this in action is the work that SendGrid, Twilio, Mashery, and TokBox do with API Hackday. They throw hackathons all over the world in cities that don’t necessarily have a lot of events. Sometimes they’ll do it a few days before a conference or something to help boost attendance, but for the most part they’re independent hackathons. Also, Hack the Midwest is another good example of a successful hackathon that popped up in an underserved market.
Here’s another protip: New York, San Francisco, and Boston are completely saturated with good events. It’s also really hard to compete with the ones that have already established a name for themselves. In general, unless you have a really good reason and a bulletproof marketing strategy, I would steer clear.
Another reason it might be a good idea to throw a hackathon is if you’re targeting a specific group of people for some reason. For example, Greylock does an invite only hackathon where they invite the top talent that they want to work with their portfolio companies. It works out really well for them because the people that they’re inviting feel like they’ve earned it in some way.
A final reason that it might be a good idea to throw a hackathon is when you’re launching some brand new API or product. This isn’t universally true and will only be effective if it’s some kind of extra fast-paced feedback loop. Companies that employ that Product Feedback strategy at hackathons tend to do the best with this kind of event.
So that’s all the time I have. There are certainly other reasons to throw or not throw a hackathon, but you’ll have to ask me about them at another time. I think the big takeaway I want to leave you with here is that you should really focus on optimizing your strategy for approaching hackathons. If you’re going to throw your own, make sure it really meets the goals that you’re trying to accomplish.
You can find me on Twitter at @SwiftAlphaOne. I’d love to hear your thoughts on the subject. Thanks for having me!
P.S. My name is Swift. I'm a former developer evangelist at SendGrid and one of the founders of Hacker League. I also tweet as @SwiftAlphaOne. Follow me there for more of my thoughts and maybe a laugh or two.
Tweet Vote on HN