On Monday morning, Hilary and I met with Erin Maguire (Digital Content and Event Producer at AmbITion Scotland) to talk about how AmbITion’s upcoming Culture Hack Day could be structured. We had a really interesting discussion, pulling together Hilary’s knowledge as an organiser of Launch48 Edinburgh, mine as a team member at Social Innovation Camp and team leader at Launch48, and Erin’s experience organising the London Culture Hack Day. We swapped tips and talked about experiences, so here are some of the notes I made from that list.
Tip 1: Open is good, but structure is good too. Having a completely open, freeform event works well most of the time, but sometimes, it helps to have some structure too. A lot of it will depend on how experienced your audience is with hack days. The less experienced they are, the more structured the event should be to help attendees get the most out of it. The trick is to take the best of open and structured styles, and balance them.
Tip 2: Attract the Designers. Hack days are where developers hang out and build some really cool stuff. However, we rarely see UI/UX designers there. Having a few designers around makes a big difference, not only because they help make the actual UI design of your projects better, but also because they tend to lead the user research for the team—which is oh-so-important when you’ve only got 24 hours to put your prototype together. Find ways to reach designers and give them a reason to come to your hack day.
Tip 3: Seed ideas. Here’s the main problem with hack days: no one wants to give up their weekend to work on a rubbish idea. At the same time, as the organiser, you don’t want to dictate the ideas too much. We suggested a number of ways to try to get this right, e.g. getting the original leaders to offer suggestions on what they think would be interesting, showing examples of what other teams have produced at previous events, offer up examples that you admire, or getting your end-users to talk about potential problems. This is really important—the quality of ideas/prototypes pursued at the hack day could make or break your audience’s perception of the event, and great ideas offer more than their weight in marketing/promotional purposes for your next hack day.
Tip 4: Get people to work together. The best ideas come from co-design, where people who aren’t from the same fields to work together (designers, developers, and arts and cultural types). It might be painful at first, and you might have to do some artificial pairing (see tip 1), but it’ll be worth it—if done correctly.
Tip 6: Brief team leaders. This is my specific request. After leading a team at Launch 48, it was quite an “interesting” (read: stressful) experience. I didn’t expect to have a team of 15 people, especially when I’m used to working in a small startup company to build a MVP. A quick brief on best practices (i.e. this is what other people found useful to do), would have helped. A lot. It doesn’t have to be long, just a 10–15 minute chat to offer tips on organisation, and best practice tips from previous leaders.
Tip 7: Make sure you tell people what the IT infrastructure is like. If you’re not planning to have a dedicated IT team on-site, or if you’re not providing server space, make sure you tell people beforehand. These things can be set up in advance by the individual developers, but it’s just a pain when you have to spend the first hour of a hack day setting up stuff because you thought servers would be provided.
(Optional) Tip 8: Not everyone likes pizza! Contrary to popular opinion, lots of developers don’t like pizza. If you can afford it, get some proper(ish) food! It’ll improve everyone’s moods and general, all-round well-being!
I hope that people find this list useful. I’m tempted to do one for anyone that turns up to a hackday, closer to the hack days itself …