Recently I have noticed that larger, more 'classical' organizations are looking at doing 'Hackathons' - short time frames where people are employed to hack on code, possibly to create new interesting ideas.  Organizations hear about Facebook, Twitter, Spotify and the like doing these hackathons with great results - employees like them as a creative outlet and the general influx of product ideas and innovation among other benefits.

Here is the catch - Hackathons are not magical and hackathons alone don't create this enthusiasm or product engagement.

Take a step back from the hackathon event and look at the organization.  Without these events, are employees more engaged and more focused on their products?  I would say so.

In these organizations, do teams have the leeway to discover new ideas and see them to fruition or are they bound by annual budgets and expected deliverables?

Before you run off to start up a hackathon at your organization, I would offer up considering the following:

 

  • Are there organizational silos that this hackathon will be working against? Think teams, products, environments or the like
  • Is this hackathon a 'free for all' or a 'random bug fix march'? How creative can teams be?
  • What happens after the hackathon?  Is there a 'process' to move a good idea forward that may suck the life out of the energy of the idea? Budgeting cycles can stop learning and innovation in its tracks.
  • Can there be more than n number of good ideas at the hackathon?
  • How do you know if an idea is good?  Is it based on some pre-defined constraints? Or will you allow learning?  Are you iterative or incremental?

 

These are just a few points to consider around a hackathon.  Any organization can cram people together for a day and tell them 'go, be creative'.  If your organization faces any of the challenges, I would offer up that you may want to consider these constraints first before the event.