Organizing a Hackathon (Again)

A week and a half ago we held the second Annual DCFemTech Hack for Good, which I had the pleasure of planning along with Ally Palanzi, Alex Ulsh, and Cat Robinson. We also had some help from other DCFemTech folks, especially Shana Glenzer, who helped us connect with contacts at the venue and with some sponsors. Last year, Ally wrote a great recap of our experiences planning our first hackathon, and I totally had planned to write down my own thoughts too. Life got in the way and I didn’t, but here are some new and different lessons I learned this year!

Find a Great Team, Keep Them, and Trust Them

Last year Ally wrote about how our engaged and hardworking team was the key to our success and I’d say that is still true. This year we had three organizers from last year’s event return and we added a new organizer whom we’d actually met at last years hackathon. The keys to this group working well to organize an event are:

Knowledge of and optimization for individual strengths. We’ve fallen into a groove where each organizer is focused on the pieces of the event where they are the strongest. It would totally stress me out to do some of the pieces handled by other co-organizers and they have told me the same is true for pieces of what I contribute. This year Ally focused on sponsors, food, and promotion; Cat made all of the art, made and managed the registration, helped with promotion, and did a lot of the public speaking; Alex organized the pre-party and did pre-planning to make sure each project was set up from a technical perspective going into the event; I was the primary liaison with the venue (thank you again OCTO!) and also communicated with the non-profit and community groups to set up and scope out projects in advance of the hackathon.
Trust. In the time that we’ve been planning this event together, this team has developed a great degree of trust in part because we’ve gotten to know each other. We are able to pinch hit for each other when necessary both during and prior to the event. We also communicate consistently throughout the planning process so that we all know where things stand. That all being said, we don’t over-communicate either – there are no lengthy and pointless meetings with this group!
Communication. This year we communicated primarily through Slack and Google Hangout. Slack was awesome as we were able to have real time conversations to make decisions and collaborate as a group. We operate with a lot of transparency and generally make decisions through consensus (even when the consensus is: we trust you, do what you think is best!).

Remember the Lessons from Last Time

It is easy to plan an event, acknowledge what went right and wrong, and then have that memory be fuzzy when you go to plan the same event again. Last year we made a few decisions that were unorthodox for a hackathon, but that absolutely helped make last year’s event awesome. Thanks to Ally’s blog post that documented everything, we had a reminder of what those things were and chose to keep these elements as part of the event:

Contribute and learn, rather than compete. Have projects where the aim is to help a community group/organization, not win prizes. We found that the project briefs I had scoped out for last year worked exactly as intended to contain the goals of each project to something that would be possible to do in a weekend. We recycled the same process/format for this year.
Keep a low pressure schedule. Healthy habits are part of our goal, which is why the actual “hacking” time for our event last year and this year was from 9:30am-4pm each day.
Value inclusion and diversity. Hack for Good is open to all participants, but by putting the event out under the DCFemTech banner, by using images of women in promotional materials, and by reaching out to networks that focus on pulling women from all backgrounds into tech, we ended up with a diverse group that was approximately 95% women and included folks from lots of different backgrounds and skill sets.

We also had a few adjustments that we made from our observations of last year’s event and we had one idea from last year that we thought about again and rejected. The adjustments we made were:

Plan technical set ups for projects in advance of the event. A failure to plan technical workflows for the groups was one of the largest issues at last year’s event because figuring out this piece cut into work time for the projects. This year, Alex did an amazing job of setting up different tools and workflows that would support each project.
Using a different platform for event registrations. This year we used nvite for registration rather than Eventbrite. By using nvite, Cat was able to really design the registration page, which made us look more professional and polished. We also used nvite’s tools at the event to keep a record of who attended.
Plan more projects. We realized that with the growth of DCFemTech and the larger women in tech community over the last year that we may have greater attendance this year than we did last year. We aimed to have 4-5 projects scoped in advance this year (last year we had 3) to account for our projected numbers.
Order less food. This year we ordered proportionately less food than we did last year. This year, Ally ordered enough food for about 60% of those who registered, which was plenty for those who attended, but cut down significantly on food waste when compared to last year. From the first hackathon, we learned that our drop off rate from those who registered to those who actually attended was around 40%.
Following up after the event. We sent a survey out to the participants this year after the event. Last year we ran out of steam and didn’t do this, but totally should have. We’ve gotten a lot of great feedback that will help improve next year’s event already! This year I am also following up with the community groups who had projects at the event to make sure they have everything that they need. I did this with some groups last year, but it’s something I’ve systematized more this year.

The idea we had from last year that we rejected implementing this year was the idea of having a track of workshops for beginners. At the end of the day, we decided that such a track would detract from the projects and distract from the overall event. We did have a plan of who could give ad hoc workshops on different subjects, but we ended up not needing those. I still think it was a good decision to keep independent workshops out of the hackathon, though I do think it would be cool (and also a ton of work) for DCFemTech to do a full-fledged conference in the future.

New Ideas

This year we introduced a few new things into the event. These new things included:

The pre-party. This year we held a pre-party at Mapbox. We had a great time and this was a fabulous way to kick off the weekend. Our participant survey will tell us more about whether we should keep this party as a feature of next year’s event!
Use of Slack at the event. We ran into limits of how many people you can add to your free slack team at once, but otherwise using Slack at the event was a great way for project teams, organizers, and participants to keep in contact. Next year if we use Slack again we’ll need to stagger when we add folks to the team so we don’t run into issues of having enough invitations to get everyone onto the platform again.

Logistics

Space

This year we had an absolutely amazing space generously provided by the DC Office of the Chief Technology Officer (OCTO). We started and ended the hackathon in a big room where everyone could be together, but most of the hackathon was spent with project teams in break out rooms. There was also a kitchen/cafe area available to us that provided the perfect home base for food and snacks. Additionally, the venue was close to metro. We got lucky that this segment of the Metro was not directly affected by the Safe Track surges!

Food

In general, we aim for inclusive food at the hackathon. To do this, we collect self-reported dietary restrictions with registration so that we know what types of restrictions we need to account for with the food that we are ordering. In general, we try to have vegetarian, vegan, and gluten free options available, in addition to accounting for anything super specific that may come to our attention through the registration form.

Time and time again we’ve found Roti to be a great option for ordering food that takes into consideration the dietary considerations of attendees. Roti is also great at answering very specific questions about the ingredients in their food.

This year we made little signs to label each part of the lunch buffet so that there were indicators of what was vegan, gluten free, etc. Labeling the food did not take much effort, but definitely made the experience of eating at the hackathon more straightforward and easy for all.

Projects

Planning and scoping out projects for a hackathon like this one is hard because there are so many factors that you can’t really predict in advance ranging from the number of attendees to the skill sets of those attendees. When planning projects for the hackathon I’m looking for a few major qualifiers for each project:

The community organization is in fact not-for-profit. Enough said!
The community organization has a representative who is empowered to make decisions available to attend the hackathon. This has been absolutely vital to the project model working for this hackathon. With a key stakeholder present (technical or not) projects are able to move along more efficiently and a greater amount of productivity towards the goals of the project are possible.
Clear project scope. Our goal is for attendees at the hackathon to be able to hit the ground running with the projects when they arrive. This means a lot of work thinking through what pieces of a larger project might be possible to achieve within the course of a weekend with volunteers.
Diversity of technical skills required. Due to the unknown skill sets of the hackathon’s attendees, our goal with choosing projects for the hackathon is to find projects that have a wide range of technical skills required. We won’t take more than one or two projects that are technically similar to one another, even if the projects are otherwise a great fit.
Realistic goals. We can not promise outcomes with the hackathon, but we make a good faith effort to make meaningful progress on the stated project goals.

One thing I’ve talked about for years now that we’ve never exactly pulled off the way I envision is having predetermined technical project leads for each project. I think this would help guide teams that have a mixture of experiences and skill levels. The main barrier to doing this is finding volunteers with the right skill sets for each project in advance who also have the time to shepherd a project throughout the hackathon.

Conclusion

There are so many ways this hackathon can grow and improve in the future, but at this point I’m proud that we’ve brought the hackathon from the nugget of an idea it once was to a real event where people learn, community groups are supported, and where lots of fun is had too.

Have you ever planned a hackathon? What are your tips and tricks for making sure all runs smoothly?