October 15, 2013 - by Liz Howard

How To Have An Awesomely Inclusive and Radically Transparent Hackathon

We hosted a hackathon from a perspective of transparency and empathy. These aren’t simply box-ticks, they’re different approaches borne of different attitudes, so I’ll also go ahead and explain why we made the small changes we did, and what we were hoping to achieve. A huge part of the success of our event was removal of barriers.By Liz Howard (Director of Operations & Instructor, Hackbright Academy)

We had a hackathon last weekend, and we managed approach organization and inclusivity from a perspective of transparency and empathy, which made the event rock pretty hard. We did it with not a huge amount of radical change, but rather a few subtle changes that made all the difference, and I thought I’d talk about them in case someone else wanted to deal with the same things we did.

These aren’t simply box-ticks, they’re different approaches borne of different attitudes, so I’ll also go ahead and explain why we made the small changes we did, and what we were hoping to achieve.

Events need user experience design too - someone who’s going to think about how the audience feels is key to have on staff. For that, @aerialdomo (main organizer), @undeRStandig and @janardanyri were critical members of our planning group, they were key to understanding how our audience would experience the event, and interface with the organizers.

Step #1 - A Clear Narrative

We wanted to invite our attendees to participate in a narrative about the event we were having. We couldn’t have thought properly about how to do that without writing the actual narrative first, so we wrote this:

“My friends and some people I recently met (mostly women) formed a team of 5-7. We got some hardware to develop with, and were encouraged to bring our own parts. We brought something from home, and added it to our project to make it unique. We didn’t know much about hardware, but there were extremely helpful mentors at the event. Everyone learned something from the mentors, and everyone contributed to the project. Then, we presented our product to the audience, and everyone cheered. We won a prize, which wasn’t a huge prize, but helped us feel recognized for our efforts. In the end, our team made plans to meet up a few more times to work on our project, since the supplies are shared and we want to continue learning more about working with hardware.”

Writing a story like this, where the story is generic to all teams, but is a basic template, will allow you to design the schedule and guide your audience to participate in the story. For more examples of this, look at storyboarding a game.

What you’re creating is an experience, not just an event. Write a story, and invite people to participate.

Getting everyone ready for what was going to happen next was the main job of the organizers, and it kept us busy throughout the event. Clear communication was our goal, which gave our attendees prep time for everything from talks to dinner. Some tips for creating a narrative:

• Write the story of the event you want people to tell. A template allows you to understand what you need to do in order to create that experience.
• Post a highly visible schedule. Include food, speakers, presentations, and availability of mentorship. Set expectations about what attendees are supposed to be doing.
• Incentivise following the narrative, be clear about how to obtain the incentives.

In our case, attendees (who were self-identified beginners) were supposed to be using a box we had given them and well as their own supplies to create a physical object to show to the other participants. They understood this as the storyline, and participated. Because of this, 90% of teams presented. 100% of teams created hardware-based projects. 80% of our audience was female, and 60% reported that they had never programmed before.

Step #2 - Remove Barriers

A huge part of the success of our event was removal of barriers. Essentially, we did more experience design by thinking about common objections people might have to signing up and participating. We did a lot of brainstorming around “well, what if someone doesn’t want to come because”, and then we did our best to remove those barriers. I’ve included some examples from our hackathon.

Our first, and biggest biggest barrier to hardware hackathons is the hardware itself - it’s expensive, and most people don’t know where to buy it, or what to buy. Even those who are apt to dive in and purchase something usually don’t know where to start or what to buy, so we did that legwork for them.

We bought SparkFun’s Inventor’s Kit - they have “lab” discounts for bulk purchases. The kit comes with some amazing things, the biggest one being the book that comes with the device with lots of examples to build, and colorful, large, easy-to-read diagrams. It also comes with a wide enough range of sensors to push the imagination, while keeping them simple enough to be approachable.

The next barrier is that, unlike software, circuitry does not have as tight of a feedback loop, or comprehensible error messages. It’s difficult to dive in on your own, so we saw a potential attendee imagining sitting at the hackathon, unaware of what to do next or how they could contribute, and then opting not to embarrass themselves.

We made it clear that mentors would be walking around at the event. We kept the mentorship recruitment in the same social media channels as the attendee advertisement, so that our attendees could see what we expected of the mentors. We also kept the ticket count of mentors visible, so that attendees could guess about the ratio of mentors to attendees.

We helped them form a clear picture of what it would be like to be completely new to hardware hacking and participate in this event - which I think is responsible for the ratio of people who had no experience we got to come to the event, as well as display of amazing projects that got pushed to completion.

Step #3 - Consider the Experience Design

The other main thing we payed a lot of attention to was the design of the rest of the experience. In order to be inclusive of the most people, we tried to keep the event entertaining, with speakers and prizes and lots of audience participation. We also needed to keep it family-friendly, and free of explicit imagery or inappropriate behavior. Some factors that kept women engaged without excluding other attendees:

• Cleanliness, and calls-to-action surrounding cleaning and organization from the attendees - this helped drive home the idea that this was a community event, not just some corporate stunt.
• A code of conduct enforced in a way that appealed to empathy over public shaming
• Specific encouragement of minors and family participation
• Inclusion of noted advocates for hardware and learning, like Highway 1 and Julia Grace

Step #4 - Enforcement: Empathy Over Policy

We had a code of conduct that stated no sexual imagery in presentations, as the event was family friendly, and the inclusivity aspect was very important to us. However, we had a team that wanted to bring together two pieces of hardware that weren’t appropriate in a family-friendly setting. The project was interesting, and the team was enthusiastic and genuine.

Rather than kick them out, we had a conversation with them about how we could allow them to continue with their plan, while respecting everyone at the event. We settled on having them not use the hardware out in the open, so that no one (especially minors) would stumble upon it. Next, we had them do any testing they needed to do in an area we blocked off for explicit content.

Last, we made it clear that though they would still be eligible to win prizes and pitch their demo, they would have to do it off of the main stage, and after the other teams had pitched.

We might have had the demo pitched on the main stage and asked minors and those who might be offended to leave. We chose instead to have the team pitch the demo in an area where attendees would have to explicitly go. The difference is subtle, but important. It sets a tone - one where we’re not forcing you usher your children out of the room, or visibly work your way out of a crowd of 200 people because you don’t feel comfortable or just don’t feel like seeing explicit content at the moment. Instead, we invited adults to come see content of a mature nature in a different area, which set the tone of getting to see something interesting and fun.

The idea is an explicit opt-in, versus an explicit opt-out. This is the difference between a vulgar joke in a comedy show, and a vulgar outburst in a restaurant. One is something people are prepared for, one they have consented to. The other is intrusive if you’re not ready, and weren’t expecting it.

Step #5 - Empathy and Transparency

We were able to have a great deal of fun with the hackathon, without worrying about whether or not we were being “politically correct” or not, by changing the conversation. We approached each decision we made by thinking about how our attendees would experience the event, and by appealing to empathy, rather than strict rules.

By communicating what we were going for, the experience we were trying to create, our audience helped us achieve our goals. We were clear about our thinking process, rather than seeming to make exceptions for some people, but not others. Our community developed a great deal of trust for us as organizers, and have a new expectation about how events can be managed.

Our code of conduct is posted here - feel free to use it for your hackathon.

We hope you can join us for the next one, as a mentor or an attendee, or even as a sponsor. We sold out this event, so we’d love to offer it again for everyone on the waitlist, and the new batches of students that will be coming through Hackbright Academy. Let us know if you’re interested in getting involved.

This blog post was originally posted at Liz Howard's blog.


see all