Back to the list

Learning Hackathons Redux 

I have written before about hackathons in the past. This time I am re-thinking some of the lessons Erin and I have learned. Erin Peterschick is my partner in crime with these things. We have been a great team for 3 years now. I have worked on some of these in the past, but we really did some good work in the past year on hackathons in the learning community and in the non-profit world as well. In September, we will be doing it again at Training Magazine’s Online Learning Conference. This will be our largest Hackathon yet! So on to the lessons learned! Here are some points we have learned and have refined for our upcoming hackathons. 

1. Hackathons don’t have to be 24 hours’ worth of hacking! I have done them over the course of a day, and with Erin, we have done them in as few as 2-4 hours. The premises are similar to a full hackathon, but you come away with actionable ideas and a path to get to real world solutions. The point is to get crisp about what you are trying to accomplish, don’t make it too big, whittle away at the outcome you want, then go for it as a group to get to what it will look like. 

2. People want to connect and to collaborate. Sit people at a table and ask them to do things and they will do it as individuals. Give people assigned roles and tell them they need to come up with ideas together, that they only have limited time for each activity in the hackathon and now they need to get crackin! They find ways of getting the information they need, they talk about their challenges and they bring it all together by tackling the hard stuff together. 

3. The roles are important in a group. We have all seen activities that go awry because the facilitator does not set it up correctly (I am guilty), but also if there are no clear roles for people who are needed in a team. For example, we need a scribe in each team. Everyone can take their own notes, but we really want to share out the group's ideas to others. We need someone to help with that effort by taking effective, clear notes. We need a table captain. Someone to take charge, keep people on task, and keep them moving. In our hackathons, we also have a coach for tables or who walk around. These people are hugely important. They keep teams and people from being stuck. They are the ones who are intentionally provocateurs of new processes and believe most challenges can be overcome. They are a catalyst for people to think differently to solve the problems. These and a couple of other roles are hugely important for good learning and action to happen. 

4. Be concise and brief with your idea. In the end of some of our hackathons, we judge the team’s ideas. We sometimes use the “elevator pitch”, which is a very concise way of pitching your idea to the C-suite. I am not a huge fan of long PowerPoint decks because they first 5-6 slides get looked at in an executive presentation, then the meeting gets derailed by questions. We all know you need facts and data to get the project approved, but you also have a short time in the beginning before the executives are going to start diving into the details. You need a way to generate excitement and to show impact up front. 

5. Visualize it! Another way we summarize our hackathons is to have the teams draw out their ideas. This helps get the ideas and the creative juices flowing. This also is a fun way of explaining their thoughts behind the ideas. You often see it from a different perspective when you are drawing it out. For a team, this can be powerful as they see where there are other connections between the ideas and even how to overcome some of the challenges. Pictures add layers and dimensions to the ideas. 

Erin and I have learned much about the world of hackathons through our own mistakes, learning from others, and putting best practices into action. I hope you will join us for a hackathon soon. It will be a fun filled action packed day with lots of good information sharing.