How we run hackathons

I recently left an NYC ed-tech startup that would have 'hack days', but during the hack days there were games, distractions, and once even a live band. Now I like parties, but it indicated to me that the non-technical CEO was allowing the hack day because Facebook did it, and he viewed it more as a recruiting effort than something he took seriously. I won one of the categories once and received no followup whatsoever, and the impression that I got was that if I wanted to work on it nights and weekends after the fact, then maybe it would be considered. Lots of people did do 'real work' during hack day, and most of the projects were fluff or things that were obviously going to be on the product roadmap anyway. To me, the entire thing was a waste of time, which is unfortunate, because I really wish more companies looked for creativity out of their engineers. Many companies (especially NYC ones) will begrudgingly pay you for your coding skills, but then put you at the whim of a product manager with no experience building anything. I always say that if you think about why designers/coders learned these skillsets, it's often because they are extremely interested in the end-products and that's what motivated them to learn to build products in the first place, and so to totally ignore their input and put them in pure heads-down coding roles is really unfortunate. This blog post indicates to me that you're not that type of company.

As for external hackathons, to me they are a waste of time as a coder because nobody actually checks that your implementation works. And worse, they hire people like journalists to judge (looking at you Angelhack). What that means is that the 'hackathon' really turns into a 'pitchathon', and the winners go to the best designers (which I can at least respect), or slide decks and charismatic pitches (which I don't). Getting the judging right so that time spent actually coding is valued is really difficult, but something more hackathon organizers should consider.

I liked that you mentioned that everyone had to contribute and no one got a "hall pass" to do real work, but I often need to manage our customer requests and it's difficult to say "I can't help you for 1-3 days because we're focusing on team building".

We do one of these quarterly and I'm trying to think how I can avoid being the worst hackweek teammate ever next time around. Maybe it is saying that we'll have limited availability for 1-3 days to some customers.

Themes can also back fire. I'd highly suggest going with no themes as well. Heck, even encourage things outside of your day to day job. You might be surprised at what people come up with. Hackathons are about exploration, and while themes can be great to help people come up with ideas, they can also hinder. We've had hackathons with themes and those without, and I can't say that the themes made any noticeable impact on the ideas presented.

Prizes are dangerous. Don't make it tangible, such as money or a thing. We tried many different prizes, and the one that worked the best was a paid team outing. Limo to and from a restaurant of their choice, all paid for, and the net result was a team that had a lot of fun getting out, relaxing, and just getting to know one another better. The specific outing isn't important, but that the activity is done as a team. Indeed, the activity itself was chosen by the team.

Support is also crucial. If the idea is something that can be put into production, it should be. In this case, those teams were given an additional week of time to clean up the product and make it ready to ship. Focal came out of this, and while it's a hobby of ours, it's simple and fun, and still supported (with new changes coming!).

Voting is interesting. I do votes via a Google Form. Generally we have between 15-20 projects per hackathon, and some projects get 1 vote. You don't want to be that guy to get the 1 vote. It's demoralizing. We announce the top 3. You have to account for larger teams. They'll vote for themselves, and that's in some ways fine. After all, if you can convince 3 other people to help you with your idea, that should count for something.

Also, look beyond just programmers. We include QA, design, project managers, and product on our teams. I've had our QA people build websites, and product people programming iOS apps, and even projects managers working to streamline processes that needed improvements. They did spend their time learning this stuff, but that's the whole point of a hackathon. To stretch yourself.

We've had a blast with our hackathons, and I can't wait for HACKD 9.

Are you guys running it quarterly already? How much time have you guys waited in between hackathons? Also, you say "every engineer who was present was expected to participate". Were the other departments allowed/expected to participate as well? This is something really positive for improving internal relations.