How to run a hack day

The last couple of years have seen a lot of buzz about the benefits of running
an internal hack day within your company. People like Twitter, The
Guardian
, LinkedIn and Dropbox swear by the
benefits of giving developers and engineers a day (or more) of freedom to
pursue whatever technical fantasy (within reason) they can come up with.

Chances are, if you’re reading this, then you already know about the benefits
of running a hack day. So the question is no longer why?, it’s how?

Of course, every company is different, so I can’t give you a prescriptive list
of “do these things and you’ll have a great hack day,” but what I can do is
share how we approach the prospect of selling the benefits of a hack day to the
business, and then organising and running the event.

Note: this article discusses selling the idea and organisation of an
internal hack day, not an open-to-the-public affair. If you’re interested in
running something on a larger scale, then the recently published Hack Day
Manifesto
is definitely worth a read.

 Selling the idea

If you own your business then you can skip this bit, but most people don’t and
before just getting on with organising a hack day, you generally need to get
the upper-echelons of the company to agree to an entire department “taking a
day off” (which is how it may be seen at first.)

The way we approached this was to put together a small document which not only
sells the benefits of a hack day, but also sets expectations of
what it’s not: a lazy day, going to produce finished products, nor is it
guaranteed to come up with the next £1m idea. In addition it covered an
example schedule for the day (we started off with a 9-5 hack day, rather than
jumping straight in with a 24-hour one,) how the hacks will be presented at the
end of the day, awards that could be given out and a few suggestions of the
sort of projects that might be created (we “themed” our hack day around our
dating platform.)

We also used this document to lay out the support required from the rest of the
business both in the run up to the hack day and during the actual day itself.
It’s easy to think “oh, it’s only one day,” but if the rest of the company is
still doing their day-to-day work, then you’ve got a few considerations:

Those are just a couple of examples of things you’ll likely have to contend
with. At the end of the day, if things really hit the fan then you have to
accept that the ongoing stability of your platform is more important than a
hack!

The hack day proposal document we created is embedded below.
You’re welcome to use it as a basis for your own:

 Pre-Event Preparation

Once you’ve got the go-ahead, a huge amount of the battle is already won, but
now’s the time to start actually planning the event. If you start small like
we did, you can make life much easier for yourself.

As mentioned, we kept things simple by running just a single-day event. If you
decide to jump in at the deep end and run an over-night hackathon, there are
additional considerations. Depending on the office space, you might need to
think about security, evening food and drink (and late-night snacks), if you’re
going to permit people to drink alcohol, where people are going to sleep (even
for a couple of hours) and, importantly, whether your insurance actually covers
people being in the building throughout the night. Again, the Hack Day
Manifesto
is a good source of information on these bigger events.

One final thing, but one that’s very important: make sure you clarify the
ownership of the hacks that are produced
. It may seem a daft thing to think
about, but it’s something that could bite back further down the line, and could
potentially cause a great deal of grumpiness amoung the participants. We
specified that, as everything was taking place during a normal working day, the
company would retain ownership, but we were happy to discuss options with
developers after the event.

 Developer Support

This is a day for the participants to be self-sufficient. Everyone is working
on their own ideas, and should have done enough preparation so they can just
get stuck in. Depending on how you’re structuring the theme of the day though,
you may need to set a few things up before the day so people can access the
services they need etc. As an example, we:

In general make sure that, come the big day, everyone can just get on with
their own hack, without having to bother anyone else.

 Expect Things to Go Wrong

We were lucky and didn’t have any major operational interruptions during the
day but, as already mentioned, make sure you either have emergency cover, or
that participants know that there’s a chance that they’ll get pulled back to
the “real world” should something drastic go wrong.

When you start thinking about running a hack day, it’s easy to get caught up in
the geeky glamour of spending a day hacking away. The more you plan out
up-front, the more realistic that vision becomes.

 On the Day

By this point, you’ll have everything organised and should know exactly what’s
going to happen and when.

You’ll want to be getting on with your own hack, but spend at least a few
minutes observing the quiet (or not) buzz of activity and focus as people are
getting their ideas down in code.

 After the Day

After your (hopefully very successful) hack day is over, it’s time to sit back
and take stock of what’s happened, but also to push forward:

If you find any of the information here helpful then please let us know. It’d
be fantastic to think that we’ve helped other companies get up and running with
their own hack day. Happy hacking!

 
1
Kudos
 
1
Kudos

Now read this

What open-source can learn about customer engagement

Running a successful open-source project is very much like running a business: it takes skill, time and money (there may not be a direct monetary cost, but there’s an opportunity cost in everything). You need to market your product: why... Continue →