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:
- an operational emergency may rear its ugly head: servers don’t take a day off from crashing just because you’re busy
- we have no control over a partner starting a huge advertising campaign on the day of our hack day which means we need to react to the increase in traffic
- there are tickets, questions and conversations which happen on a normal work day that won’t be answered as quickly, and everyone needs to know that this will happen
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:
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.
- Make sure all participants know what’s expected of them. We sent a couple of emails out to everyone on the days before covering the schedule for the day, information about technical setup and source control usage, food, the lightning talks and prizes at the end of the day.
- Get everyone thinking of hacks they can do, and what teams they want to work in. For the couple of weeks before the event, we had loads of ideas written up on a whiteboard to get people talking and thinking about what they were going to do on the day.
- Try and arrange breakfast and lunch (plus dinner and late-night snacks, if you’re going for an overnight event.) You want everyone to have as much time as possible, and you don’t want them wasting time heading out for lunch in the middle of the day. We have a delivered breakfast every Friday, so that was the early-morning food covered, and for lunch we went with a selection of Subway platters.
- Make sure that the business leaders (or at least some of the more senior figures) are around for the day, or at the very least for the presentations at the end. This way they’ll see the ideas that can be generated given a bit of freedom, and hopefully will be excited to do it again in the future.
- Make sure you’ve got everything you need for people to be able to present at the end of the day: screens, connectors, network access etc. Our eventual overall winner Kris nearly didn’t get the chance to present her hack because of network connection problems.
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.
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:
- made sure that everyone had somewhere to commit their work as they were working on it;
- had development instances of our stack available for people to be able to demo their work;
- had API and other access permissions sorted so people could just crack on using data, rather than fighting to get the information they needed just to start.
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.
- Start the day with a bit of breakfast and a small welcome talk to introduce the day. Reiterate what’s expected of the participants (this is on company time, after all) but otherwise just let people get on with it.
- Keep your eyes open for things which aren’t going quite right. Hopefully there won’t be too many issues, but better to head them off early rather than wait until something’s become a real problem (e.g. lunch delivery problems!)
- Keep everyone up to date with what’s going on throughout the day; we created a live blog post which we updated as events unfolded. If you make this public, then not only is it great for those taking part, it also enables other interested parties (both internally and externally) to keep an eye on developments. Some people like to record the activites of the either by camera or on video.
- Make sure everyone attends the demos at the end of the day. You’ll more than likely have a few people still doing some last-minute hacking as they’re sat watching other people, but at the very least get them in the room.
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:
- Follow up on any projects which showed promise for the business. The Guardian have Star Chamber meetings to discuss the benefits of each hack and to decide which of them deserve to be take forward (hopefully to production.) You may also want to have discussions with any developer who’s done something that your business won’t want to take any further, but the individual(s) may want to keeping working on it privately.
- Show off what’s been built internally. You’ve probably got more than just a development team in your company. Some of these people will have been thinking to themselves “what have these guys been up to all day?” So show them what you’ve produced. Get the rest of your company as excited about the hack day as you are.
- Publicise what was created. Show off what everyone’s worked so hard at for the day. Make a big deal of it, both internally and externally.
- Start organising the next one. Off the back off a successful hack day is when you’ll have the most momentum, so start planning the next one straight away. And make it bigger and better.
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!