Don't Throw That Hackathon

These are my slides and a paraphrased summary of my talk from the 2013 API Strategy & Practice Conference in San Francisco. You can find the full slides on SpeakerDeck.

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.

Call me Swift. I'm one of the founders of this little outfit called Hacker League (acquired by Intel, 2013) and I'm the commissioner of this thing called Major League Hacking (MLH) (think NCAA meets Hackathons). I'm also pretty well known for my former role as the first 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 weekend 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 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.

While I don't have a pretty graph to show this one, 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.

3 Reasons Companies Sponsor Hackathons

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.

1. Product Feedback

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?

Some companies that you might be familiar with that employ this strategy well are SendGrid, Twilio, Firebase, and TokBox. 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.

2. Mindshare & Perception

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 and now have a personal relationship.

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.

3. Recruiting

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.

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, we should organize our own Hackathon, right?

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 pro-tip: 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.

Finding (or Creating) New Customers

The first one I usually hear is the company that's trying to acquire new customers to use their technology. We hear stories about GroupMe and Zaarly and suddenly hackathons become the place to find the next million dollar customer.

Here's another Pro-tip: 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 level of polish than a 24 hour hackathon.

Another alternative here is to incentivize existing companies to use your APIs through support programs. That could come in the form of a grant, fund, mentorship, etc.

Getting Developers To Attend Your Conference

Often companies 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, which was much shorter *(3 hours)* and focused on more bitesized coding adjacent activities. It was much better suited for the fun environment of a conference and went over phenomenally.

Ok, But When SHOULD I Organize A Hackathon?

So now that we've talked thoroughly about why you shouldn't throw a hackathon, let's talk about the cases when you should.

1. Lack of Nearby Events

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 pro-tip: 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.

2. A Hyper-Targeted Audience

Another reason it might be a good idea to throw a hackathon is if you're targeting a really, really specific group of people (less than 100 usually) 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 are inviting feel like they've earned it in some way.

3. API Launch Events

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 that isn't ready for public release and requires a lot of engineering handholding. 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.

Conclusion

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 listening!