I don't care about trophies, certificate, gift cards, etc. What sounds most positive to me about your internal hack days is your effort to productionize the efforts. That means you actually realize that all those smart, ambitious people you hire might actually have good ideas.
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.
One benefit of doing a hackathon around the holidays is that support volume is generally way down as well (at least in an enterprise software world). That being said, one of our internal company values is (bear with me for the impending cliche) "customer first", and that's a golden rule for the team, so if something major comes up that would indeed take precedence. For minor things, it's not crazy to adjust the SLA. Some companies adjust support SLAs for all-company meetings, conferences, offsites, and so on.
I'm the hackathon guy here at MeetMe, where we are starting to plan our 9th internal hackathon since 2012 that we call HACKD. Most of these thoughts presented here I agree with. A few additional points I'd like to add:
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.
What you said about the prize element really resonated with me - it's fraught with peril. One thing I noticed is that your suggested prize is 'experiential' rather than tangible. I thought the ability to choose the movie for Movie Night would be more coveted than the certificate...
Your points about voting as the company scales are interesting. It's something we're going to have to watch as we grow. We did use secret ballots (we are a bit obsessed with privacy...) so the whole presentation-to-voting transaction could be done in one setting.
As for applying outside the engineering department - this is one of my priorities going forward.
Yep, we do. And while I'm sure it's obvious, I do want to make clear this is what has worked so far with us. We've tried different things, and some have worked better than others. Each group of people will be different and value different things.
The most important thing is obviously that everyone enjoy themselves and have fun.
Oh! And one more thing I forgot:
5 minute presentations, and you can't use presentation software like Keynote.
Really good read, and great tips on how to run an internal hackathon. 100% agree on having a theme open to interpretation, prize categories, and kinds of prizes you are giving. :)
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.
(Responding for Jon because he's in meetings this AM) -- The first two questions are related, and actually somewhat adressed in Jon's "frequency" section. I'm not sure what the "exact" distance between the events should be, but as he mentions in the blog post, "setting the events far enough apart that each time feels like a special event - a welcome visit from an absent friend."
This is likely different for different people and companies.
Regarding other departments -- yes! Everyone participated in giving ideas, feedback, etc. In fact, it's actually the sales people who fell in love with the results of the hackathon the most and are now vocally asking for more hackathons.
Great way to utilize some low productivity days! If people have something planned for the actual week, maybe you could consider giving them the next 3 days off so they still get a "week" off.
I organized and ran Hackendo (https://hackendo.techendo.com/) in April. Hackathons are super rewarding, but a lot of hard work if you don't have help. My biggest takeaway from throwing a hackathon is: Find reliable people who want to help volunteer to support before/during/after your hackathon.
I'd appreciate a hackathon for making AeroFS sync reliably. I've been using it for years, since when it was invite only, and it often simply refuses to sync. I've spoken with their support a dozen times. They're nice and courteous but the problems don't get solved. I've already given up on AeroFS; it's great for moving files inside a lan quickly but not for much else.
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.