Here at Sunlight, we’ve handled lots of hackathons for the developer community– especially around Open Government. Some have been productive, some have not. By now, I think we’ve gotten it down to a particularly good set of principles and ideas to share. Below is a collection of those ideas that will help you run your event more smoothly, and hopefully get the most out of your event.

Remember: hackathons are not social engagements or consensus driven activities. They’re about doing work. Habitat for Humanity, for instance, doesn’t get bunches of people together to talk about how they should build a house at the beginning of the day. They identify skillsets and put people to work as quickly as possible, often times before the volunteer event starts, and have a plan for what roles people can play before they get there. Community will get built out of your hackathon– but more tight bonds get built by people getting together and doing hard work rather than sitting around and discussing current affairs.

Your attendees will show up eager to work, and more than likely they’ve sacrificed some of their time so that they could feel useful. It is your job to make them leave there feeling useful. That means being able to put them directly to work. That means:

Getting an idea for who will be there before it starts

Get people to RSVP and figure out the “mix” of your crowd before your event starts. Anticipate the ratio of technical to non-technical people you’ll have there, and figure out what kinds of languages everybody codes in, or what their proficiencies are before beginning the day. This will give you a clue for what to do and how to allocate resources during the event.

There’s a tricky thing here though: bet on 40% of the people that RSVPd not attending your event. That means you can’t be too fixed.

Start your Hackathon on Time

Request your attendees to show up on time. Plan leeway time for them to arrive. Let some social time to occur at the beginning of the day. In the hackathons we’ve done, usually people show up early (up to a half hour early) which gives folks plenty of social time at the beginning of the event. Start an all-hands-on-deck meeting approximately one half hour after the hackathon “event” starts.

This is important to send out in messaging before the event begins. Let your attendees know that the event will start on time and will require the whole day. People floating in and out throughout the day will not be useful, and may impact your end-of-day results, as new folks will tax your existing teams as they’re brought up to speed.

End your Hackathon on Time

When you start your hackathon, let your attendees know that it will be ending at a specific time as well. This helps developers know what kinds of constraints they’re working with time-wise, and helps project managers pace the development appropriately. Let your volunteers know that there will an end all-hands-on-deck discussion/showcase of what was accomplished that day. This is important for two reasons:

1. So that people can get a chance to see what they, as a group, have managed to accomplish.
2. So that folks know there’s a goal for their team: to have something to show by the end of the day.

Create Structure in your Opening Meeting

Developers not only need goals, they also need constraints and process in order to be most effective with their time. If you don’t set and keep constraints throughout the day, it’s likely that you’re not going to serve your developers well, or have them leave feeling as though they’ve accomplished much. For that, you need to create structure and process. For reference, check out the opening remarks I gave at CrisisCamp Haiti. You’ll get the gist.

Team

During your opening all-hands-on-deck, your first task is to create teams. The best way to do this is to go down the list of current projects and to assign project managers and developers to each team. Having some frame of reference for what kind of technical requirements each project will need. Getting leadership and common-language developers assigned to projects as quickly as possible is key here. Get the teams formed, and off working. There’s no need to debate as to who should go where– it’ll sort itself out.

While it’s pliable, we’ve found this structure to work well. Each team should have at least two developers and one project manager on it. Other resources can be added depending on event attendance. The core roles of two developers and one project manager may not be how each individual prefers to identify themselves. For instance– with an influx of developers and not enough project managers, it may be appropriate to assign a developer to be a project manager for the day.

After the core team has been built, get them out to their work areas as quickly as possible. Then you can begin assigning the other volunteers out as needed. There are other roles that can be assigned in the team– and they do need to be assigned. One particularly good role for a team is that of a documenter/scribe. This role can track a group’s progress throughout the day, take great notes, and prepare the project to be handed off to another team if needed. If a designer is appropriate for the team, add a designer. If researchers are needed, then add a researcher. The possibilities are endless.

You, the organizer should be a meta-lead, whose job it is to manage those project leads.

Structure

Because you’re dealing with a limited amount of time (usually just one day) you’ll need to put some serious thinking into how the day is structured. Project Leads should manage their teams in 55-minute-long task assignments. The most important session is the first one. In that session, the project lead and core team will figure out what the plan is for the day– how they’re going to have something to show for their work at the end of the day, and figure out what the first set of deliverables are.

At the end of that first hour, all the project leads should tell their teams to get to work on their assigned tasks, and then meet with you and the rest of the leads in a group. You should have at least 4 checkins with your project leads throughout the day, recognizing that they’re the most valuable when they’re with their teams, not with you. These meetings are to make sure the other project leads have an idea of what each other are working on, and to look for opportunities to collaborate if there are any. It is recommended that project leads check in and set goals with their team every hour for five minutes, and check in with other team leads and you for 15 minutes every two hours.

In terms of ticket-tracking and other types of systems for sharing information/managing workflow, these need to be fast decisions and they needn’t be universal. Because you’re with volunteers, you may have people that are accustomed to certain tools. Let them use what they need to use to be the most effective, rather than spending time on learning new ticket systems. The only thing that’s important is that you have a common place for people to store reports of what they’ve done at the end, so you can demonstrate success.

Be clear in your morning meeting about the structure of the day so people know what to expect.

Tone

Direction and leadership are really important. Truth be told, as cynical as it is, trying to come to consensus as a large group or even in the smaller teams, is more often than not a fools errand. This, as the organizer of the event, is your biggest challenge– balancing the need for a work-oriented day with alienating volunteers with too much of a hard-nose.

The key to this balance is tone. In the beginning, ask people to accept responsibility for their own contributions. Let people know the overall expectation is action, not discussion. Note that the projects are fixed, and ask people to resist the urge to debate for the day they’re there, and instead to dismiss ego. Ask people to remember they’re part of something bigger than they are, and that you’re really only asking them to dismiss their ego for a day. To do this you need to thank your volunteers in advance, give them an idea for the magnitude of what it is that they’re trying to accomplish, and let them know that what they’re doing is important.

Remember: they’re there to feel useful. The best way they’re going to be useful that day is to be led by someone who knows what they’re talking about. Tell people they may not get to do what it is that they want to do, and may be relegated to a support role if there’s a lot of folks there, but their contribution is still honored, precious, tremendous and respected. And respect them for it.

What to do while everybody is working

Hopefully, if you’ve set your tone right, after your first all-hands, you’ve gotten your teams working, the other volunteers assigned to those teams, and you’re beginning to ask yourself “now what”

You, the organizer, have three roles: initially, to make sure the people that may be straggling to find a way to contribute– you need to help them find a way to contribute or get them out. If they’re not contributing in some way, they’re going to distract in some way. Thankfully, most people, from our experience, find a way to meaningfully contribute– after all, that’s why they showed up in the first place.

Secondly, you should begin slowly taking note of how each group is working and performing, and begin to find ways to push the various teams in the right direction. For instance: if, prior to the first project lead check-in, most of the teams are standing around a white board– that’s fine. But if they’re still standing around it in the next one, you should check it out and encourage the project manager to move past the planning stage and into the work stage. People standing around a white board is a great indicator that they’re planning to write code rather than writing code.

Thirdly, you should be providing each project lead with what the next step is. Here’s our standard agenda with some helpful hints about what to talk about.

• 8:30-9:30: Check-in, bagels, coffee, meet-greet
• 9:30(sharp)-10:15: All-hands-on-deck morning meeting, teams formed, getting to work.
• 10:15-11:00: Group planning conversations, volunteer assignment
• 11-11:15: First project lead checkin with organizer (prepare leads for lunch)
• 11-11:55: Work
• 11:55-12:00: First round of check-ins with project leads and team (prepare team for lunch)
• 12:00-12:55: Work
• 12:55-1: Check-in with team
• 1-1:15: Project lead checkin with organizer (prepare for post-lunch slowdown, remind that there’s only a few hours left)
• 1:15-1:45: Working Lunch
• 1:45-2:55: Work
• 2:55-3:00: Project lead checkin with team (prepare for deliverables)
• 3:00-3:15: Project lead checkin with organizer
• 3-3:55: Work
• 3:55-4: Project lead checkin with team
• 4-4:55: work
• 4:55-5: Project lead checkin with team
• 5-5:15: Project lead checkin with organizer (go over deliverables, prepare for cleanup)
• 5:00-6: work (push stuff live, commit source, plan for post-hackathon work if needed)
• 6: All-hands-on-deck wrapup.
• 7: Happy-hour

Each check-in, if done over the course of meeting every-other-hour, providing them with ways to see potential problems with the next check-in. The biggest potential problem during your day– the greatest single, mass, horrible buzz-kill is:

Lunch

Lunch is your enemy. People will eat, take a bit of time to eat, and once they start digesting their food, their energy levels will drop faster than Florida housing prices circa 2007. Especially if you feed them junk. Now, I happen to like junk food, so it’s hard for me to not order pizza, but feeding folks a healthier meal while they’re there may be useful. But at the very least, in your check-in prior to lunch, you need to start planning your project managers for it. Let them know that lunch is a super momentum-killer. Tell them to plan on working through lunch, and that lunch should be done with teams in their areas, and that they should, if needed, to have group conversation about what’s going on, to do it then. But to schedule no more than a half hour for that discussion and to lead people back to work after it is done to show momentum.

End of day wrap-up

At the end of the day, each lead should talk about what their team was able to accomplish that day and what the next steps are for the project. Where those projects end up and whether or not they still need work are valuable things to share. What the plan is for future work on the product is also an attainable thing.

After each project lead has spoken, give the opportunity for anybody else. If the energy is right, and the tone for work was set-up correctly, a few other projects may have been created and accomplished at your event. They should be announced to the group, too.

Once that’s all done, ask people to help you clean. Chances are they’ve made a mess. They’ll gladly be great heroes and help you clean up the space that you’ve used.

Miscellaneous

A few helpful reminders:

• Very rarely do software products get built in a day. While you can acknowledge that, you must have a set goal for the end of the day for each team. Your project lead should help their team come up with that and stick to it.

• Be respectful of the fact that often times people’s time is far more valuable than their money. Treat them with respect and acknowledge them at every opportunity.

• Avoid en-masse group discussions. With a large enough group, you’ll spend the entire day having a discussion and a lot of people will walk away feeling as though they’ve wasted their time.

• It’s OK if you take some downtime. You don’t need to be doing something all the time. It is often more damaging to do something because you need to fill the time (distracting a project manager, for example) than it is for you to just duck into a quiet corner and check your email. You need to be useful 100% of your time, but that doesn’t mean you have a use 100% of the time.

• Don’t take yourself too seriously. Use some humor. Even at your own expense.