I recently hosted and facilitated a successful sustainability hackathon, and I thought you might be interested in seeing my playbook and the rough timeline. I liked it, the participants liked it, and I think you’d like it too.
The hackathon was run by the Tekna’s Network for Developers, and Tekna Klima (environmental). We’re volunteer networks for Norway’s biggest STEM union, but our events are free for everyone, regardless of membership.
We had 6 inspiration speakers, some digital, some in-person. All the hackathon participants were in-person. We held it over 1.5 days, with the first day being focused on inspiration. The second day was focused on the hacking and demos.
The participants were a mix of developers, data people, product people, and misc. We had 7 teams, with a very international crowd
I’ve split the post into two parts - first is the philosophy and tools of facilitation I use, the second is the timeline with some notes from me. The timeline is from memory, written one day after the event took place.
How I approach hackathon facilitation
The narrative of “why are we doing this?” and “why are we here?” are fundamental to the whole event. If it’s not clearly defined, people won’t show up, or they won’t care. I like to make sure the audience knows the whats and whys.
I rarely plan out the exact timings of in-person hackathons. The big deadlines are important, but everything in between is “flexitime”. Talks, the start of the event, and the wrap-up time are fixed. Everything else is flexible. I watch a clock, read the room, and adjust timing as I go. Be fair, but strict with timing.
Controlling the room is important. I prefer to be authoritative through confident kindness.
There’s a term that psychologists use called “self presentation”. It’s the way that a person consciously and sub-consciously projects their self-image to others. I don’t do it consciously, but there are a few different “modes” I enter during events like this. I’ve labelled them in the timeline below, but they’re basically either me being myself, being a presenter, being a host, or being a facilitator. They’re all a little different. If I’m a facilitator, I don’t feel embarrassed. If I’m myself, I’m shy and introvert. Recognising these modes in yourself can help you realize when you need to take a break, or change mindset.
To me, hackathons are most valuable for two things: 1) The skills people get to practice or learn, and 2) The networking and discussion people have. Making finished products is almost never the goal for me, but I do encourage people taking part to have something to show at the end. It makes people feel like they got more value out of an event, even if the true value isn’t directly obvious. Slides, videos, and code are directly obvious. Learning, growth, and network less obvious.
Lead by example. Want people to clap? Start clapping. Want them to clap louder? Start clapping louder.
I don’t like hackathon prizes. Everyone should feel their participation was valuable. I know some disagree with this, and think that prizes provide motivation. I don’t think that’s necessary if the narrative for the hackathon is relatable enough for the audience.
Facilitation tools I use
Put three fingers up so a speaker can see when they have 3 minutes left.
If the facilitator raises their hand, anyone who sees it must stop talking and also put their hand up. It spreads throughout the room, bringing attention and silence to the facilitator.
Whiteboards, HDMI cables, HDMI-to-USB-C for Apple users.
Food and drink in a common area. It encourages people to take a break when they need it, and gather in one spot when it’s feeding time.
Lots of smaller rooms with tables, chairs, and power.
Humour. No need to be strict all the time.
Multiple people there - to handle the logistics of the food, the presentations, letting people in and out of the building.
Ask more questions than giving answers. The 5 whys are handy.
Business model canvases, and variations of it, can be handy depending on what the teams are looking into.
Eye contact can help figure out who is engaged, and who isn’t. Sometimes people make eye contact when they have something they want to say, but don’t want to put their hands up.
Have some people “on your team” in the audience. These will be your collaborators for the hackathon, and play an important role in making the audience comfortable. A good example of this is someone who helped plan the event, but is in the audience so can reply as if they are an audience member. Very handy for topic suggestions during unconference events.
Assume nobody knows anything. If you introduce a tool, remind them of how it works.
Some useful metrics
How many people attend both days? 2 day hackathons can be a big commitment for people. Losing people between the two days should be expected. It can be painful if only half a team shows up on day 2. So I suggest making sure you know who plans to come to both days, and make sure that people are in teams that will work on things they all find interesting.
Are people discussing and engaged during the eating/chilling periods?
Are people paying attention during the talks?
Are team discussions being dominated by one person? If so, sit with the team for a bit and help everyone speak up.
Now let’s look at the timeline of this event itself.
Before the event
Sync with the people running the event. I was brought in mid-way through planning as a facilitator, which I’m generally happy to do.
Sync with the speakers to give them an idea of what they should expect, and what I expect of them.
Day 1
Welcome and inspiration talks
Begin “presentation mode: friendly person”.
Entry - say hi to people. As the facilitator, it’s useful if people know your name. You want people to feel comfortable coming to you with any questions they might have.
Prep the speakers. Make sure you know how to say their name. I’m always afraid of mispronouncing names, so I try to ask them how they say it if I’m not sure.
Gather everyone into the main room.
Begin “presentation mode: host”.
Light, keep my participation short. Let the speakers shine. At this, I am mostly there for logistics. Some of my slides:
Introduce the topic, mentioning why we are here. Share my personal motivation for the topic, so that people can see we are all collectively exploring the problem space. I am not there to tell people what to do, only to guide them.
Start with a speaker who gives an overview of the topic. This talk is the longest.
Short, specific inspiration talks from people who work in the industry.
Thank the speakers, finish the streaming / recording.
Grouping and setting the context
Begin “presentation mode: facilitator”.
Step away from the stage, stop using a mic, and step into the audience. The main difference here is to move away from 1-to-many setup, to a setup where the audience is expected to contribute more. The audience now becomes the participants.
Introduce different facilitation tools to the group. These are the ground rules: the times when things will happen today and tomorrow, and techniques like “when I raise my hand, stop talking, raise your hand too, and face me”. These give the facilitator authority, through the collective power of the participants’ desire to take part.
Send the participants to eat, with them knowing at some point I will raise my hand and want silence. I take a lot of joy from seeing the participants all mixing and having great engaged conversations. It’s also magical to raise my hand, and see the wave of hands rising to match. Going from a lot of noise to complete silence without needing to yell, ring a bell, or clap, is amazing.
Rejoin the main room.
Get a pulse of the participants. Who is here for both days? What do people care about? How many developers, designers, data, product, etc?
Set the scope for the event. There’s only around 8 hours between the remainder of day 1, and the demos on day 2. A good demo could be slides, it could be a running program, it could be a mind-map.
Begin “presentation mode: unconference”.
Invite the participants to mention a high level topic they’re interested in, within the topic of the hackathon. In this case, sustainability was split into three parts: environmental, social, and governance.
Group people based on the topics they want to explore - aim for a group size of 3 or 4. Bigger groups should be split. Nobody should be alone - the value comes from working with others and getting to know other people. Try to get a mix of skills and backgrounds in each group.
Begin “presentation mode: innovator”.
Introduce the double diamond. By the end of day 1, the aim should be to have discussed in each group why they are interested in the topic, and the problems they care about (discover). A stretch goal is to have a specific problem they want to solve (define).
Day 2 will be for develop and deliver. Make sure the participants know how much time they have, so that they keep it in mind when looking at solutions.
Split into group discussions. Check in with the different groups, but let them mostly discuss amongst themselves.
Send people home: a good night’s sleep is one of the best ways to prepare for a long busy day full of thinking and discussions. Planting the seed of the problem that each team will try to solve can help them think about it overnight. Make sure the teams have exchanged contact details, and have agreed when to show up on day 2.
Day 2
Hacking
Slow start, let everyone arrive and eat breakfast.
Begin “presentation mode: facilitator”.
Raise my hand to get silence once everyone’s arrived, and tell the participants to go find their team mates and distribute themselves throughout the rooms we have available. Make sure they know the big two points in the day: lunch and demos. Remind them of the goals of the day. The last 30 minutes of the hacking session before demos should be the garnish - perfecting what they already have rather than making new things. Check people’s battery levels, encourage those on low batteries to take a break. Or drink coffee/Pepsi Max.
Rotate between the teams, listening in to their discussions. Answer questions they may have, and point them in the direction of useful information. Ask questions that further their own discussion. Don’t spend too long with each team, unless they’re really stuck. Let them know when it’s time to go for lunch.
Begin “presentation mode: chill for a bit”.
Gather back into the room for lunch. Let the participants eat in peace.
Begin “presentation mode: facilitator”.
Remind people of the deadline for talks. Send them back to their groups.
Check in on teams, giving them a heads-up when they should start gathering in the main room.
Demos
Begin “presentation mode: host”.
Remind the participants of the rules: 10 minute talks, then we eat. Check with the room to gauge when/if you need breaks. Let them know you’ll give them a 3 minutes warning when they’re out of time on stage. Make sure they have a microphone - many may not have given talks before, so a microphone is there both as a prop to hide behind, and to make sure everyone hears them.
Invite each team to the stage in turn. Everyone on each team should come to the stage, not all need to speak. Clap as loudly as you can after each talk. Q&As need to be time-managed, encourage people to talk to each other after if they have more questions.
Thank everyone for coming. Take a group picture. Get everyone to send their presentations to one of the organisers so that they can be redistributed later.
Begin “presentation mode: normal me”.
Socialising
Enjoy talking to people, congratulate people. Get people’s contact info for later communication.
Thank the others organisers there for their help.
Clean up, put food and drinks away.
Go home.
Afterwards
Reflect on what went well, and what didn’t. Note things you’d do differently next time.
Write a blog post about it (this blog post).
It’s hard for me to fully enjoy myself during events like this - my mind is focused on making sure it goes smoothly, with the results we want. It takes a couple of days for me to appreciate my own contributions. But it’s very important to take a moment and feel proud of not just the speakers and the participants, but yourself too.