.png)
Credit: https://hackathon.guide/. A step-by-step guide by Joshua Tauberer based on running and participating in many hackathons. These notes come from five successful years of Open Data Day DC and other civic hackathons that I’ve run, sponsored, or participated in. The ideas have been inspired by many individuals, especially including my Open Data Day DC co-organizers Eric Mill, Sam Lee, Katherine Townsend, and Julia Bezgacheva, as well as Justin Grimes, Matt Bailey, Leah Bannon, Laurenellen McCann, and Greg Bloom.
A step-by-step guide by Joshua Tauberer based on running and participating in many hackathons.
These notes come from five successful years of Open Data Day DC and other civic hackathons that I’ve run, sponsored, or participated in.
The ideas have been inspired by many individuals, especially including my Open Data Day DC co-organizers Eric Mill, Sam Lee, Katherine Townsend, and Julia Bezgacheva, as well as Justin Grimes, Matt Bailey, Leah Bannon, Laurenellen McCann, and Greg Bloom.
I define “hackathon” very broadly:
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 I keep in mind:
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. Just don’t. There has never been beer, competitions, or time pressure at my hackathons. Participants should come energized and be greeted with positive energy.
My notes below are mostly logistical and assume a technology-centric approach. I take it for granted that you want to run a hackathon. But read So You Think You Want to Run a Hackathon? Think Again by Laurenellen McCann for thoughts on other (and sometimes better) ways of engaging a community.
Also consider not calling your event a “hackathon”. Not everyone will know what you mean, and “hacking” might make it less likely that all groups will feel welcome.
If the goal of your hackathon is to market a product, stop here and read a different guide. Your goals and my goals are not the same.
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.
First time hackathon participants are often overwhelmed when it comes time to finding a project to work on. They may not yet know how to relate their own skills to the sorts of projects being worked on. Knowing how to be useful is a skill in itself. You will need to guide them to a project and through a process for them to realize how they can contribute. If you have too many lost participants and not enough help in getting them started on a project, they will leave — try to avoid that.
The hackathon organizer must make sure that everyone has something to do. One way to do this is to have a list of project leaders ahead of time: people you know are coming with particular projects that you can guide other participants to. And you can work to make sure your hacking projects are ready to accept newcomers. You can also hold non-project activities — workshops, described below — which are easier for newcomers to join.
You could also consider pairing newcomers with mendors or holding a pre-event session just for newcomers, as Wikimedia recently did.
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:
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.
A themed hackathon is one in which the projects are confined to a particular problem: such as food sustainability or returning citizens. Themed hackathons are able to attract subject matter experts (something that open-ended hackathons like Open Data Day DC are not good at), and projects typically revolve around problems that the subject matter experts bring to the table.
When themed hackathons are also technology hackathons, there is a common problem: Subject matter experts can readily identify problems in their field but cannot always turn those problems into workable technology projects. Other participants may be ready to apply their skills but not know anything about the hackathon’s theme. Bridging that gap requires careful planning ahead of time.
What often results is a division of the room into three groups:
#1 is great. #2 is fine if the group is happy. But #3 is bad: participants without subject matter guidance will feel lost. To avoid this, make sure you have enough workable projects for everyone ahead of the event. Work with the subject matter experts before the event to turn their problems into projects. See the section Cultivating Good Projects above to ensure there is a coherent question, that the necessary resources exist (e.g. datasets), and that the skills needed for the project match the skills expected to be brought by other participants (and in sufficient quantity).
Additionally, a subject matter expert may propose many ideas but he or she can only effectively participate in a single project during the event, so ensure that there is at least one subject matter expert + workable project for about every four non-expert participants.
Onboarding participants onto existing projects can be very difficult. It is one of the hardest parts of hacking. So have ideas for new projects that are especially easy for participants to get started with if they can’t join an existing project. Having project ideas ready is especially important if you do not expect many participants to bring projects! And always be open to project ideas from participants. A project of one, meaning someone working alone, is okay too!
Do not allow anyone to pitch an idea that they will not be working on at the event, unless there really are not enough ideas to go around. Otherwise, this is a waste of everyone’s valuable time.
Once hacking has begun, do not interrupt the hackers except to ensure that the hacking is going smoothly, to check that everyone has something to do, and to keep people on the overall schedule. Mid-day activities such as lunch-time speakers and video calls with people off-site are incredibly distracting for participants who are now eager to get working on a problem.
A successful hackathon might be just hacking, just training, or both hacking and training.
If you have a significant number of newcomers, having training workshops is a great way to give them something to do that they will be more comfortable with than diving into hacking. You can run workshops to introduce participants to the subject of the hackathon or to particular technical skills useful for the hackathon. Workshops can also be places to have a discussion about issues in the field related to the hackathon. Workshops should be interactive as much as possible
Choose your workshop leaders carefully. Ideally the leaders have run the same workshop before so they are well rehearsed. They should also be as diverse as the attendees you would like to see present at the event (gender, race, age, etc.). Read the Hopper Conference Diversity Guide’s tips on selecting speakers.
Run the workshops in a second room if at all possible. 45-90 minute workshops are a good length. If you have more than one workshop, leave 15-30 minutes free between workshops to allow for the first leader to close up and the second leader to set up.
At Open Data Day DC, we have run six workshops over two days on an introduction to open data and APIs, an introduction to collaboration using github, open mapping, an introduction to Python, and community engagement.
Find a venue to host your event and reserve the date. This is the only thing you need to do significantly in advance of the event. The earlier you can reserve space the better.
Find a venue that can provide:
(If you are running a large event, also read through all of the accessibility concerns listed here.)
Seating requirements are different for hacking and workshops. For hacking, you will want a banquet-style setup with large circular tables that seat about 10 people each. Rooms in banquet-setup hold the fewest number of people compared to other table/chair arrangements, so take that into account when computing capacity. For workshops you will want classroom-style seating, i.e. rectangular tables with chairs on one side.
Choose the date of your event carefully. Avoid the summer, holidays, and other major events in your field. Weekends are hard for people who are attending in their professional capacity. Weeknights are hard for parents.
Ask your venue about permissible start and end times. Set times for when you will arrive/leave and for when participants will arrive/leave. Plan at least 30 minutes before and after the event for you to set up and tear-down/cleanup.
Make sure you can get in and that your participants can get in. If the building’s front door is locked, make sure you have a key and that you have someone posted at the door to let in participants (you may need a team of people to rotate at the front door throughout the day).
Check whether the venue permits you to have food in the room.
If holding the event outside of business hours, check that the venue will have air conditioning/heating.
Professional venues charge quite a bit of money, so you will need to find something that fits your budget. Hopefully you can find some free space with good wifi (your local library, a friend’s company, etc.).
For a large, one-full-day event in a major city, expect venues to change in the thousands of dollars per day. It depends on how much space you need, and there is no rhyme or reason to pricing, but it usually comes out to about $10-$30 per person.
For large events, you will probably need sponsors to help you cover the costs.
Sponsors will give you something — cash, space, food, t-shirts — with the expectation that they get something out of their support for your event. They might be recruiting/hiring and are looking to scout out your attendees, or they might be marketing a product that they want to promote.
Think about what you’re willing to give sponsors in return for their support. You will certainly thank your sponsors, by name, during your opening and closing session, and you will probably want to tweet your thanks too. Beyond that, do you want to give them a time at a podium to speak to your attendees? Or a table in the back to show off their stuff? It’s up to you, and you have to strike the right balance between bringing in enough sponsorships with not interfering with the goals of your event.
Figure out your budget — your venue and food costs, especially — first, so you know how much in sponsorships you need. But then get started on securing sponsors early.
Ideally you should provide coffee and light fare for breakfast and beverages throughout the day (especially water). Food is surprisingly expensive though, so do what you can.
If you provide any food, you really must supply vegetarian and dairy-free options because these dietary restrictions are very common. Going all-vegetarian isn’t a bad idea. After that, give consideration to other restrictions your participants may have (vegan, kosher, gluten-free) and do your best.
Be responsible with your food. Think like a parent. Order food that is relatively healthy. Avoid heavy foods that make people sleepy (like bread) or ineffective (like alcohol). Caffeine and sugar are fine (energy is important), but have real nourishment too..
Figure on $7 to $15 per person. Pizza is the cheapest food to get, but it’s also basically the worst thing you can possibly feed someone (and not everyone eats it) — avoid pizza if you can.
If you are ordering food, you will probably place the order at least three days ahead of the event.
Some events like to provide swag, like t-shirts or stickers. Personally I think there are much better ways to spend your budget, but if you really want to provide swag keep in mind–
Don’t get one-size-fits-all t-shirts because people aren’t all alike. In fact, read Hopper Conference Diversity Guide’s section on t-shirts.
Technology events have a history of not always being welcoming to women and minorities. We need to change that. You can be a part of that change by adopting a code of conduct for the event. A code of conduct is not just about enforcing rules. It sets community norms and sends a signal to would-be participants that you are trying to create a welcoming environment. And, of course, if there is a problem at your event having a code of conduct ahead of time will help you resolve the issue.
Look for codes of conduct used at events you admire, or copy from Code for DC’s code of conduct or Tech Lady Hackathon + Training Day’s code of conduct. Also read the Hopper Conference Diversity Guide’s section on this.
A pre-event happy hour the night before helps participants to get to know each other in a relaxing setting. A post-event happy hour the evening after the hackathon wraps up gives participants a chance to socialize now that they know each other.
For large events, pick a bar ahead of time and talk to the bar and make sure it is ok for you to bring a large group. You may want to reserve a section of the bar (they may ask for a payment ahead of time or a guaranteed minimum spend that they will charge you after if your people don’t order enough).
If you are serving alcohol keep in mind: not everyone drinks (those under 21, pregnant women, and many many other people for a variety of reasons); alcohol can lead to an unsafe or uncomfortable environment; those that drink will need public transportation to get home. So therefore: provide non-alcoholic drinks; supervise the environment to ensure it remains professional and comfortable for all; be near public transit.
Set up an Eventbrite registration form.
Determine your maximum capacity. For an event with parallel tracks, bear in mind that participants will all gather in one room at the start of the event, so your maximum capacity is a little larger than the capacity of your main room (some people can squeeze/stand at the beginning).
For a free event, about 65% of those who register will actually show up. This number is very consistently seen across events. So cap registration at 150% of your actual maximum capacity.
Use the registration form to gather information about participants:
The more information you can gather ahead of time the better planning you can do. You can start to think about who will be working on what as soon as registrations start coming. Literally try to imagine how each registered participant will keep occupied at the event based on whatever information you know about them.
Look at who is coming and if you know some of those people are coming with particular projects, identify project leaders. You may also want to meet with them at this time to:
See the section Cultivating Good Projects above.
If you are running interactive workshops where the participants are following along on their laptops and expect many participants to attend, you may want to have workshop helpers around to help participants that get stuck. Plan for at least one helper for every 10-20 participants.
Also find helpers to run a registration table and the building’s front door if it is locked, and you can also consider identifying volunteers to take point on photography, managing social media, and documenting what happens at the event for storytelling afterward.
You may want to email the registered attendees at this point with as much of the logistics information as you know, so that they can plan ahead. See “The day before” below for what to include in the email.
Set up a way for your participants to communicate digitally and stay in touch after the event. Some options are:
Part of your event’s lasting impact is in how people will remember it:
You should bring to the event:
You may want to email the registered attendees at this point, again, with as much of the logistics information as you know, so that they can plan ahead. See “The day before” below for what to include in the email.
Do a walk-through of your venue. Ensure you have:
If you have two parallel tracks:
Send out a logistics email to registered participants. Include:
Print handouts for participants that include:
Print one copy per table (i.e. one copy for every ~5-10 participants).
Start with a brief session welcoming everyone and laying out the day:
In a small event (up to about 30 people), you can have all of the participants introduce themselves.
Anyone who has brought a project to work on should then introduce the project to everyone. This is sometimes called “project pitches.” Keep each pitch short: the leader’s name and affiliation, a problem statement, the solution, and the skills/help needed. Project leaders tend to talk for as long as they can, so you may need to cut them off after one minute to be respetful of the audience’s time. Encourage leaders to think of this not as recruiting but as boasting how awesome their day is going to be.
Have someone managing the hacking room. Go around to check that every project is going smoothly. See if anyone needs anything or can’t find something to work on. Keep people on the overall schedule. Alert everyone when it is time for lunch and one hour before the wrap-up session. Leading up to wrap-up, make sure each project is prepared to explain what they did. Get them to record their progress on the tumblr or hackpad.
Have someone managing workshops. Make sure workshops stay on schedule, that participants are understanding the leader, can hear the leader from the back of the room, etc. Be around to ensure that the workshop leader doesn’t have any technology problems. An organizer should be on hand at the workshops at all times.
The wrap-up session gives everyone a chance to hear what everyone else worked on during the day. For a small group, ask volunteers to report what they accomplished or what they learned (especially for workshop participants). Give folks rounds of applause.
In large groups, have each project report on its accomplishments. If possible, let them show their work on the projector. But keep things quick. By this point projects may have a lot to say. Keep each project to 1 or 2 minutes, and if they are going to show something on the projector make sure it is ready before the wrap-up session begins.
Finally:
Finally once all of the participants are gone, make sure the venue is returned to its original state:
After the event: