Skip to content

Hacking away at hackathons

In a past job, I worked at a company where the CEO often suggested we do “hackathons.”

We never actually did one because I could never square my mental image of them and the contextual gaps the request could represent.

In my head, a hackathon is an event where you order some pizzas, have developers stay after hours and crank on things for the business that aren’t a priority the rest of the time. But, innovation!

It always struck me as a signal that the business wasn’t happy with the pace of development or wasn’t sure what to work on and wanted to encourage their developers to think in more business terms.

Or, sometimes they’d be framed as bug hunts where we’d bucket all of our care and maintenance work into a compressed timeframe outside of the usual flow of work – usually signaling that things have gotten out of control enough for the business to try dramatic things to address the situation.

We never did a hackathon because I instead tried to adjust our processes and systems such that they could address those concerns.

We baked in care and maintenance tickets such that we addressed them along the way, and made it so developers were responsible for quality assurance – with explicit permission and expectation to make things better than they found them.

We also adjusted our process a bit to have an experimental squad and a care and maintenance squad concentrating on the respective problem areas.

Doing this process and systemic work helps clarify what a hackathon is for.

Used effectively, it can carve out time and permission for your developers to try some crazy ideas, serving a similar purpose to Google’s fabled and now long extinct 20% time.

If you’re going to pull off a hackathon, here’s some tips:

  1. Be explicit about the purpose: As we’ve talked about before, and even hinted at earlier, developers who have been around the block a time or two might have a dim view of hackathons. Be upfront about why you’re having one so they don’t invent the darkest timeline in their heads.
  2. Constrain the scope: Just shouting “hackathon!” And expecting your developers to suddenly come up with great ideas when presented with the writing equivalent of a blank page isn’t going to make your time very efficient. Great art comes from constraints. You’re likely to constraint the time, but constraining by the scope or area of focus can also produce great results. Pick one area of the business, or one area of the app, or one customer archetype to focus the effort on.
  3. Do it on company time: Don’t use a hackathon as an excuse to wring more time and effort from your team. Period. If you’re going to do this, do it on company time, during the week and during regular hours.
  4. Give it enough time: Speaking of time, you need to give this effort a big enough chunk of time to accomplish a full thought. That can be a whole day, or better a whole week, it’s largely up to you and how big a thing you’re hoping to come out of the exercise.
  5. It’s not just dev: Consider including the entire product organization in the effort – designs, product managers, product marketers, the works. A good working model can be the Startup Weekend structure of project teams.
  6. Keep the lights on or clear the decks: If we’re talking about a week of dedicated effort, you have some choices to make. After all, there is still a business that needs to run. If you can truly unplug your entire team for the week, do that. Rent out a cowering space off-site and let them crank. Let the rest of the company know they’re off-limits for the week – and mean it! If you can’t stomach that, consider peeling off a skeleton crew to keep the lights on and triage issues and the like while the hackathon is going on. If you want dedicated effort, you’ll need dedicated attention. Hackathons don’t work well when folks are dipping out for meetings and fires and emails. Make it important, and mean it.

More than that, before you resort to a hackathon, ensure that your existing workflows help serve the business – so they don’t request that you do one and instead you can do one for the fun of it.

Leave a Reply

Your email address will not be published. Required fields are marked *