Or “Why Do a Hack-a-thon”
Or “What You Can Expect from a Hack-a-thon?”
Or “How Do You Set Up a Hack-a-thon?”

“Innovation” seems to be the business buzzword of the moment. But if you are part of a successful software development shop we all know the problem when people ask you to be “more innovative.” We don't really allow the time to do true innovation. After all everyone knows about all the urgent things we have coming up in the plan and if we take away capacity from that work … well you know how this argument goes. So the development shop gets the reputation of not being innovative.

To break this cycle, and to prove to ourselves that we still had innovation chops, we decided to take a leaf out of the playbook of companies like Atlassian and Facebook and set up a “hack-a-thon”. A hack-a-thon is a (development shop) event where people are given a couple of days to try out anything they want to improve in their product or process.

Now for us, selling this idea took some time. We worked to help everyone understand the development treadmill we were on, and that we could establish innovation by dedicating some capacity to the effort. In the end we set it up as an experiment to see what happens, what the results were and what impact it had on existing plans.

Before going into the details of how we organized our first hack-a-thon, what were the results? The backdrop for this experiment is a product family with more than 20 years of continuous software development, with work from 10 teams located in multiple countries around the world. We gave everyone about 1 week notice that we were going to run the hack-a-thon at the end of the latest release of the product. At the end of the hack-a-thon we had 38 ideas demonstrated after 3 days of effort. Product Management was excited about putting a number of these ideas into future release plans. We had a huge return-on-investment in terms of the engagement in the development shop in their work which I suspect improved productivity. As we involved leadership in all steps along the way, it allowed us to start dispelling the notion that the development shop is unable to innovate. And we started to help people understand that innovation is not something you get for free, that you need to decide that you want to do it and set up the environment so that it can be done.

How did we do it? As said about a week before the release of a product, we issued a notice to the development shop that we would run a hack-a-thon. We decided that if we were going to do something like this, it makes sense to do it at the end of a release where we really haven't started to work too much on the next release. We put together a simple (5) slide presentation for everyone that explained the idea, how it worked and what people needed to do next and presented it in a 1 hour kick-off session. The presentation covered:

• What the hack-a-thon is:
  • Most people have an idea what a hack-a-thon is, but to ensure we were all on the same page, we referenced Wikipedia's article on Hack-a-thon.
  • We then set expectations for our version - “Up to 3 days of free time during regular business hours to define and implement any new idea related to our products or business”
• Why, our business reasons, for having a hack-a-thon. For us this was:
  • “To create time and space to foster creativity and innovation in our products.”
  • “To seed ideas that can be further cultivated to become part of our products.”
  • ”To engage our people. We know you probably have an ‘itch’ related to the work you are doing, here’s your chance to scratch it.”
• Who is involved:
  • Participation is not mandatory and people could participate as individuals or groups - up to our people
• How the event will happen:
  • Timing (registration date, implementation start and end date, demonstration date, voting)
  • Prizes ($100 Amazon gift card for most innovative, best presentation, etc)
  • Special prize (area of focus we were hoping for more input in)
  • Results (we said short 2 minute video of working demonstrable software was expected and in particular said “no PowerPoint presentations”)
• What they needed to do next:
  • Brainstorm and register their ideas

We wanted to keep the administrative overhead as low as possible to encourage participation and because, in reality, we didn't know what to expect. We pointed everyone to a Wiki page (Confluence) to register their ideas. As people came up with ideas they filled in a table with the name of the idea, a brief description and the person(s) who will work the idea on the Wiki page. This was also where people recorded their results once implemented. In our case we said that you have to show something real through a short video and that people would vote on what they saw in the videos.

There was quite a bit of discussion around whether we should specify what we wanted folks to be innovative about. There were two drivers for this discussion. On the one hand, there were people who were concerned that we weren't going to be any new ideas and that we needed to seed the ideas in some way. At the other end of the spectrum, there was a fear that people would “just do anything” and we'd up with things that wouldn't help the business. In the end both of these fears proved unjustified. We went for “no approval of ideas” - we simply let people scratch whatever itch they had - and then offered up one “special prize” in an area where we were hoping for a little more focus (in our case the upgrade process between versions of the product).

We set up the hack-a-thon so that the implementation ran Tuesday to Thursday with results complete on the wiki page by midnight on that Thursday (note: we've also done the timing so that it incorporates a weekend with good results). If you ever want to understand the level of excitement these events engender, just watch the mad rush of activity that happens on that page in the run up to midnight (and a little beyond) as people and teams trying to get their final cut of their entry registered.

We then opened up voting through a survey (we used “Lime Survey” to tally up the results), allowing everyone in the development shop vote on what they thought were the most innovative, best presented ideas. We were originally going to have management do the vote, but decided that it would have more meaning if the vote came from peers. Voting was open until 11am the following day so that we could make announcements of the winners at a hack-a-thon lunch. Prizes were award to individuals or groups by the executives based on the voting results.

After the award luncheon, closing down the event involved two activities:

• The Product Management team went through all the ideas and reported back to the organization the ideas they thought they would take forward into product plans. To put it simply, the Product Management team, while skeptical about the hack-a-thon concept initially, became one of the biggest supporters of the idea in part because of all the good ideas, already partially implemented, they could take into product plans.
• We went through a simple retrospective on the event so we could increase the value for all concerned. There were a lot of suggestion for improvement, but the main one was “give us more time to come up with innovative ideas the next time round.” As a result we announced the timing for the next Hack-a-thon event.

There are a lot of words in this post so let me close with a few closing summary ideas as you think about setting up your own hack-a-thon especially if you doing it for the first time:

• Keep the administrative overhead as low as possible
• Don't worry too much seeding / approving ideas. With clear goals your people can be very innovative.
• Don't worry too much about prizes. We did. In the end we found that people were interested in being acknowledged by their peers than the actual prize.
• Make the hack-a-thon available to everyone, including all levels of management. Ideas, and implementations can come from unexpected places.
• Be clear about what happens as a result of ideas that are generated and include feedback in the process so you can improve the event itself.

But, as they say “just do it”. The benefits in terms of innovative ideas (and helping the culture of the organization become more conscious of innovation) as well as engagement from your people more than outweigh the cost.