Reflections on hackdays
I’ve been to a couple of hackdays/weekends recently (Fieldwork Hackday and Good for Nothing / Summer of Love), and have learned a fair bit about how they function. Having worked with large-scale online innovation communities, that play out over several months, I’m particularly interested in how these different approaches compare. What kind of outcomes can you expect from a highly compressed burst of activity, compared to an extended, mediated process? How could the two formats complement each other?
Here are my thoughts on the format, and how to make it work.
What is a hackday?
My perspective on hackdays is slightly different from the classic view (I’m not a developer). So here’s my working definition of a hackday:
- A diverse group of creative people
- Brought together into one space
- Building solutions to interesting problems
- With an imminent and immovable deadline
- Sharing their results at the end
A hacker, in this context, is just someone who is able to make something within those constraints, usually following a prototyping approach. The outcome, or ‘deliverable’, is often something that only just functions; it’s a tangible proof of concept (or a ‘minimum viable product’), rather than an unrealised half-step towards a polished product.
The format has of course come from the developer community, so the end-products are often websites, or apps, but there’s no reason why they can’t be physical devices, models, poems, films, spreadsheets, clothing, buildings, or documentation. But they do have to be actual things, not just ideas for things.
What hacking looks like
These are my personal reflections on what I’ve learned so far. I’d hesitate to use the word ‘rules’, but they are at least things that seem to work. For more guidance you could do worse than checking out the
Hackday Manifesto, or go along to a hackday.
Setup
Recruit a diverse group of hackers
Collaborative innovation works best when your pool of collaborators is diverse. Which means reaching out to different communities, but also using different tools. For example, focusing on digital channels will exclude many people who aren’t heavy users of those channels.
A diverse group is also more fun and more rewarding to work in, and helps people break out of habitual working patterns. A developer who’s used to working with a UX designer and a project manager is likely to think and act very differently when his teammates are a beekeeper and an actor.
Set well-defined, interesting challenges
The hackday format works because it’s ruthlessly focused on a definite, material outcome: a tangible answer to a question. So it’s essential that the question is a good one.
- Spend time refining the challenges – as the saying goes, “a problem well-stated is half-solved.” Be clear and concise. Provide supporting material where it helps. If you can’t define your problem in definite, understandable terms, it’s unlikely that anyone will be able to solve it.
- Be interesting – look for the part of your problem that is also interesting to others. How can they benefit by helping to solve it?
- Be achievable – or at least have some achievable problems in the mix. A ‘big hairy audacious goal’ isn’t inspiring if no part of it can feasibly be attempted in the time available.
- Reflect the make-up of your hackers – your challenges should be as diverse as your hackers, and reflect the mix of skills they bring.
Make it feel real
Things that feel real have a kind of magnetism, or momentum, that often makes them successful. When you’re starting with nothing, it’s important to direct some energy towards making it feel like something. Then you can attract enough energy, buzz and commitment to actually make it something. (The same goes for a software startup, an event or conference, a film or album, or any other creative endeavour that you’re trying to launch into the world).
In practical terms, that means giving it some good branding, working hard to get the word out, and encourage people to talk about it, and finding some supporters to lend their names to it, to sponsor it, in the broadest sense of that term. People who are thinking of taking part want to be reassured that other people are also committing to it.
Nice branding by Good For Nothing for Summer of Love
Running the hackday
Venue
A cool venue can be part of the appeal of a hackday. Conversely, if someone spends their 9 to 5 in a strip-lit office, they’re unlikely to want to spend their weekend there too. Can you provide access to an interesting part of town, or the countryside? Are there areas for people to break out and socialise? Where are people going to eat? Or sleep, if it’s over a couple of days?
Fieldwork Hackday was held at the beautiful Slapton Ley National Nature Reserve
Logistics
When you’re busy hacking, it’s great to know that there is someone to call on who can sort out logistical problems; get more tables or chairs, buy sharpies, fix the aircon, whatever. And it helps bind everyone together – the organisers, the challengers and the hackers, all in the same boat.
The finish line
The prospect of having to present their work in the very near future helps give participants energy, and also accounts in part for hackdays’ incredible efficiency at solving problems. It drives people to focus on action over talking, and helps ensure that there are useful, tangible deliverables at the end.
Demo-ing real physical stuff at Fieldwork Hackday
Nevertheless, sometimes people need to be reminded to get back to work, to cut short discussion, or just make a decision and go with it. Knowing when to intervene, and how to do it positively, is a skill you only learn by practice.
It’s worth a note on presentations. Nothing saps energy from a room more than an unfocused, rambling presentation, and yet still people find it difficult to keep to time limits. It’s the organisers’ job to enforce time limits on speakers. A big countdown timer on a screen facing the speakers helps. As does a loud noise when their time is up.
Looming deadlines can be oppressive, but an impossible deadline can feel liberating. I probably enjoyed the last hour of work at Summer of Love more than any other time. And I found presenting (and listening to presentations) more enjoyable here than in many other situations.
The outside world
While hackdays may look like inward-focused events, with all energies directed to people and activities inside the room, they’re actually driven by the outside world. The problems people are working on solving are faced by people outside. Glimpses of the outside world can be an unwelcome reminder of what everyone’s giving up in order to hack, but gestures of support from outside can also be a powerful motivator.
Can you bring people in to play music and keep the hackers entertained? Or find local businesses to sponsor the event with cake, goodies, beer or lunch? Can you throw open the doors and invite passersby to join you? (The Summer of Love guys seemed to have some success with this strategy, and it gives a wonderful energy boost to the people already there.) Every gesture of support from outside helps grow the hackday, and binds the active participants with the wider community.
Pies, bagels, cider, chocolate and frozen yoghurt were all supplied by sponsors of Summer of Love
Follow up
I can’t say too much about this yet, not having had much experience of the follow-up, but clearly it’s important to make use of the energy generated on the day, and support people in whatever they do next. Everyone pours energy into the day, but it’s easily dissipated if you don’t pay attention to what happens afterwards.
Polishing products
It’s inevitable that the products delivered at the end of the day will be unfinished in some respects. Ideally, they will be useful as they are, or at least provide evidence to support further investment. You need to anticipate this extra work and find ways to support people in making it happen.
Supporting the challengers
Assuming you’re working with a group of people who have set the initial challenges, they’re likely to feel like they’ve been put through the wringer in the course of the event. They’ve probably been left with a pile of assets or products which may or may not work properly, which they have to learn to use, or further develop. Again, they need support in taking on what they’ve been given.
Reaching a wider community
A successful hackday is likely to be interesting to a wider group of people than just those who attended. The organisers of Field Studies Hackday held a follow up event back in London a couple of weeks later, designed in part to expose the work to a larger group of people who couldn’t make it down to the hackday itself Devon.
The Summer of Love Social is in a couple of weeks. I’ll report back…
Social dynamics
As a participant, I’ve found it fascinating to observe the social dynamics (and my own state of mind) as they unfold over the course of the exercise. The novelty of the situation, co-operating with newfound peers, the compressed format and high energy levels make for an unpredictable and constantly surprising experience.
These social and personal dynamics are critical to the success of the event. To some extent, all you can do is try to set the right conditions for positive dynamics in the setup, then hope for the best. But it helps to be aware of some of the critical tipping points in the hackday where things can flourish or wither.
Arriving
As I walked through the doors of Lighthouse for Summer of Love, I was greeted by smiling faces, offered a beer and immediately engaged in conversation. I was able to move from a state of mild apprehension and uncertainty, to a more comfortable acceptance of the unknown.
Briefing
I talked about the importance of good challenges already. And they have to be well-communicated too. This is the point where, as a participant, you want to be feeling inspired, to hear something that grabs you and makes you think, “I could solve that”. It’s the first big set piece of the event, and an opportunity to establish it as something credible, to validate people’s commitment. Or vice versa. I imagine it’s a pretty nerve-wracking experience for everyone who’s helped set up the hackday.
Starting work
After they’ve been briefed, the participants face their first big tipping point. They stop chatting, form teams and start working. Only, no-one knows much about the other participants. It’s likely that few of them have worked under these kinds of conditions before. Some people might be struggling to find a role, and need help to find the best place to contribute.
And in my experience, you don’t even know it’s a critical point until it’s over. The transition from exploration to action takes place in maybe just a few minutes. There’s no bell to let you know that it’s just happening, there’s just a phase change in the room.
I think this is possibly the highest risk point for the organisers, where they need to be most alert to the need for intervention; to give encouragement, or change course on a brief, help teams form or hackers to find their feet.
Work and play
There’s obviously a role for some social time at the beginning of the event to let people get to know each other. And it’s good to try and help people break out of any existing social groups they might be retreating to. You want everyone to be talking to someone they don’t know.
But there should be space (and permission) for socialising or switching away from work throughout the event. This can be at set occasions like lunchtime, but also as an when people need a break. The flexing between work and play is part of the format.
Cider time (photo by Good For Nothing)
Gifts, recognition and love
I’ve not really addressed the issue of rewards. What makes people give up their free time to set up hackdays, or to participate as hackers? What motivates people to stay? A complex relationship of gift-giving is certainly a part of it. Everyone is giving something, and that invites reciprocation, which in turn build social bonds.
That’s a web of relationships that I’m not best-placed to untangle. Maybe it’s easier to see the rewards of recognition, or even love, that are shared. It’s a rare opportunity to be able to work in such an environment, and a powerful reward.
Interesting questions
So that’s what I’ve figured out so far. As ever, I’m left with a pile of questions:
What kinds of problems can hackdays be applied to? How can they complement other innovation processes?
How do you adapt the format to work well outside the traditional software and hardware hacking communities?
How can a hackday be used in a business context? How do you structure the rewards when the challenges are set by a commercial organisation?
What ancillary value is created during the hackday – beyond the products themselves? How do you exploit it?
How can you turn the day into a starting point: for new networks to grow, for fresh innovation?