Over the years, a number of companies I’ve been an investor in have had hackathons. These are typically day long events where everyone in the company works on whatever cool new ideas they have. On Monday night I got a note from a company I’m on the board of about a hackthon they just completed. As I looked through the list of things that the various teams created, I got chills of excitement.
Most of the companies we invest in release software at least once a month. Some release weekly, or even daily. I’ve become a big advocate of true Agile development (partly because of my experience with Rally Software – the leader in Agile software development environments) and – more recently – the notion of trying to get to continuous deployment which has been popularized by Eric Ries.
If you are releasing at least monthly, it’s easy to do a full day hackathon at least once a quarter. And, rather than have it be an “engineering thing”, you can (and should) make it a full company thing. Here’s how:
- Pick a date during the quarter for the hackathon. Mondays and Thursdays are best.
- Designate one person in charge of managing the hackathon. This person has a budget for food and prizes and is encouraged to do whatever they want to publicize it throughout the company (easy for 10 people, not so easy for 1000 people). The goal is to engage 100% of the company in the hackathon.
- Form teams. The teams should be between two and five people. The teams should be self-selecting. The Hackathon manager should come up with an easy way to manage the team list (hint – wiki). Each team should have a name and, in advance of the hackathon, should spent at least one meal together talking about what they are going to work on. People should be encouraged to work with folks they’ve never done anything with before, although this shouldn’t be a requirement.
- The hackathon starts at 12:01am and ends at 5pm. Whatever is done, is done. Demos and awards start at 5:30pm. Food is included. The hackathon manager is responsible for coordinating all of this, including the mechanism for judging.
In the best hackathons, there is a wiki that is very dynamic during the hackathon. This way all of the activity is captured and can be reviewed afterwards. The goal is not to include everything from the hackathon in future releases; rather it’s to stimulate a bunch of ideas, generate some prototypes, end up with some useful code, but get everyone in the company thinking about all the products.
Not all of the hackathon projects need to be about code. I’ve seen things like help systems, new web sites, better customer support processes, better management of social media activity, and lots of business process stuff created and implemented during hackathons.
After the hackathon is over, publicize what you’ve done to the world. FeedBurner used to do a great job of this with a simple blog post that highlighted every project and the teams that worked on them.
Oh – and don’t forget to invite your board members. If I can make it, I’ll always spend a day at a hackathon. It’s one of the best ways for me to really engage in and help out the companies I’m involved in. Plus it’s a blast.