_ _ _ _ _
| | | | __ _ ___| | ____ _| |_| |__ ___ _ __ _ __ ___ _ __ ___
| |_| |/ _` |/ __| |/ / _` | __| '_ \ / _ \| '_ \| '_ \ / _ \ '__/ __|
| _ | (_| | (__| < (_| | |_| | | | (_) | | | | | | | __/ | \__ \
|_| |_|\__,_|\___|_|\_\__,_|\__|_| |_|\___/|_| |_|_| |_|\___|_| |___/
A bunch of people who build things.
“Hackathon” may be defined very broadly as:
- Hacking is creative problem, may be technological, solving.
- Hackathon is any event of any duration where people come together to solve problems. A track of workshops may also exist.
Participants typically form groups of about 2-5 individuals, take out their laptops (if the event is technology themed), and dive into problems. Training workshops are a great parallel track especially for newcomers but also for all participants.
Hackathons have gotten a bad rap because of some that have an unhealthy, competitive structure, and for setting unrealistic expectations. Don’t run a hackathon like that and you’ll be on the right track. Here are the goals to keep in mind:
- Strengthen the community that the hackathon is for;
- Be welcoming to newcomers to the community;
- Provide an opportunity for participants to learn something new;
- Provide a space and a time for participants to make headway on problems they are interested in.
Big expectations lead to demotivation. Don’t expect to have actually solved a problem by the end of the hackathon. Real life problems are hard! Think of the hackathon as a pit-stop on a long journey to solve problems or as a training session to prepare participants for solving problems.
Since you’re not going to solve a problem, don’t put unrealistic (and unhealthy) pressure on your participants. Don’t stay up all night, don’t pump participants with caffeine, and don’t make winners and losers. Participants should come energized and be greeted with positive energy.
The hardest thing about running a successful hackathon is being welcoming to newcomers and helping them get involved in an activity.
Newcomers often suffer from “imposter syndrome”, the feeling that they don’t belong because they don’t have skills, aren’t smart enough, etc. They’re wrong, of course, but until they feel like they belong they will not be able to have a fulfilling experience. It is the hackathon organizer’s job to help them realize they have something to contribute. During the event, experienced participants will need to guide them to a project and through a process for them to realize how they can contribute.
The hacking track is for participants to dive into problems. Often groups of 2-5 individuals form around a project, such as building a new data visualization, writing a document, or collaboratively investigating a problem. Participants take out their laptops, connect to power and wifi, and get working.
Hacking begins with project introductions. Participants that bring projects to the event have an opportunity to briefly (1 minute max) explain what they are working on at the very start of the event so that other participants can join that project. At the end of the event, a wrap-up session gives each project a chance to demonstrate some accomplishments.
Not every project makes a good hackathon project. It is extremely important to maximize the following qualities in the projects at your event:
- Clearly articulated. Projects should have a clear question or problem they are trying to solve plus a reasonably specific proposed solution.
- Attainable. Most projects will accomplish about 25% of what they think they can accomplish in the limited time they have. Manage each project’s goals so participants are able to feel accomplished at the end of the session, not interrupted.
- Easy to onboard newcomers. Projects should have ready-to-go tasks for newcomers with a variety of skills and at a variety of skill levels. For coding projects, these tasks can’t require an intimate understanding of the code base, and make sure the build environment can be spun up in less than 20 minutes. Make a list of tasks or create github issues ahead of time!
- Led by a stakeholder. A stakeholder (or “subject matter expert”) guides a project to real-world relevance. Projects without a stakeholder can “solve” a problem that doesn’t exist. Ideally the leader (or one of the leaders) is a stakeholder, or a good proxy for a stakeholder. I strongly recommend reviewing Laurenellen McCann’s Build With, Not For series on involving stakeholders in all civic tech work. Additionally, it is never enough for a project leader to just be an ideas person. Beware when the leader is a stakeholder but can’t foresee how he or she might be implementing along with the rest of the team.
- Organized. For projects with four or more members, especially newcomers, the project leader’s role should be to coordinate, ensuring each team member has something to work on and helping to welcome new team members.
Treat these bullets like a checklist. Projects that think about themselves in terms of these qualities tend to be happier and more productive.
If you know what projects are going to be worked on at the event, the earlier you can get those projects thinking about this the better. Meet with project leads and talk about these components of their project ahead of time if possible. As an organizer, having this information about projects can also help you route participants to projects they may want to work on.