How Carnegie Mellon Created a More Inclusive Hackathon

I've been meaning to write this post for a while, but decided now would be a great time since I'm missing out on Grace Hopper.

In February 2012, ScottyLabs (of Carnegie Mellon) organized the school's first student-run software hackathon, TartanHacks. It saw 150 participants, 50 of whom were women. And this is how it happened.

Two years ago, I was working on a side project to make APIs for school data. By exposing data such as course schedules, room reservations, and menus from campus dining locations, I hoped that students would be more inspired to take on side projects and create change in their community, and realize that they can solve the problems around them.

The team dedicated to exposing campus data eventually became known as ScottyLabs (after our school mascot, the Scottie Dog). We decided that a great way to promote these APIs would be to hold a hackathon. This was just before hackathons exploded; polling the freshman class had shown us that freshmen, overwhelmingly, did not know what hackathons were - the next year that was not the case at all.

From the beginning, we cared about creating a more inclusive hackathon. One big reason was attendance. If we cared about using this channel to get our APIs out there, we wanted people to show up! Hackathons weren't popular among the undergrads. The largest software hackathon on campus had been organized by an outside company and reportedly had 50 attendees, many of whom were master's students, and only 2 of which were women. We also partnered with the school's Women@SCS(School of Computer Science) organization, which meant that we had many conversations about getting more women to hackathons.

Inclusion was also something that was very dear to me personally. Even getting over the "double minority" thing (do you ever get over that?) I never did feel at home in the School of Computer Science simply due to my skills and interests and personality. I thought it was crazy that I was organizing an event I'd never, ever attend. A lot of the tweaks that we'd made would have made me feel more comfortable as an attendee.

So here's my list of changes that we made. Unfortunately, we didn't test the effectiveness of each of these in isolation, but hopefully this helps you frame tech inclusion in a more practical, less enigmatic way:

We told people what a hackathon was. - We didn't tell people about the type of person that we expected at a hackathon. We told people that a hackathon was an event where you could focus on building something cool - and we're all smart, creative people that know how to build things.

We told people it was okay to be a first-timer. - This was something we put on our Facebook copy, on our posters, and when we went around and talked to classrooms. We said that first-timers were welcome. A lot of people were afraid to even try it out, and telling them that this was exactly the type of environment to try things out made people feel more welcome.

We didn't mention it was a competition. - Internally we were having a fiasco figuring out what we were going to do with prizes, and so we didn't announce prizes until our session on the rules right before the hackathon. Afterwards, a lot of students mentioned to us that they would have been too intimidated to come out had they known it was a competition beforehand. (Students that wanted to believe that we had prizes and a competition either assumed or asked the organizers beforehand.)

We didn't make it grungy. - A lot of students thought that hackathons were gross, grungy events. We decided to put the hackathon in our beautiful new Gates building, and let them spread out. We also advertised that we were serving really good food - "better than pizza." We needed people to believe this was a nice event where they would be taken care of, and return on that promise.

We helped students see this as an opportunity to learn. - Beforehand, we held a weekend of "crash courses" to get students up and running. These were taught by other students. Our approach to crash courses was not "How much can you teach about Rails in an hour?" but "How can you make Rails seem accessible and learnable in an hour, such that students can then spend the necessary time on their own to learn it?"

We made it easy to ask questions. - At the hackathon, we had a team of student mentors, who could provide technical assistance and be a sounding board.

Also - it's important to note that we tried to reach a broad audience in terms of teachers and mentors. We didn't just ask the "hackathon type," but students from all over the community. In fact:

We made it about more than just "shiny webapps." - The second year we held the hackathon, a good friend of mine was the "machine learning" mentor on staff. She helped a prizewinning team build a service that alerted you if your Facebook friends posted suicidal statuses. I'm proud that we had participants that wanted to pursue this project, a mentor on staff to support them, and judges that could award them. Hackathons don't need to be about shiny webapps; we wanted to enable students to experiment with other areas of computer science. We worked to have a technically diverse mentorship staff, gave out prizes not for API use, but for categories like "Best User Interface" and "Best Hack for Hack's Sake" and "First Penguin" (biggest risk), and had judges that could discern the technical difficulty of a project.

We made sure they knew they weren't going to be alone. - We had a free agent mixer before the hackathon started, and also played matchmaker during the early hours. 

And last but not least:

We had pre-registration for women and underclassmen. - This made these groups explicitly know that they were welcome. Surprisingly, we didn't hear any complaints about this policy. This may have been because everyone that wanted to participate ultimately got in.

Here are some things that I want organizers to keep in mind:

The reasons why women weren't going to hackathons were the reasons why people weren't going to hackathons. - It's incredible that we had so many female participants, but it's also incredible that we had so many participants. We made a hackathon that was friendlier and more accessible to our community. We didn't paint it pink. We figured out why women didn't want to come to hackathons and we did our best to fix those problems.

A better hackathon for women was a better hackathon for everyone. - Women didn't get better food. Freshmen didn't get better food. Everyone got better food. A better hackathon is a better hackathon.

"First-timer" does not mean "bad developer." - Just because someone has never participated in a hackathon doesn't mean they don't know development. It doesn't mean they don't know full-stack development. It doesn't mean that they don't have good ideas, it doesn't mean they can't implement their good ideas, and it doesn't mean they can't win. It simply means they've never participated in a hackathon before.

I had another hackathon organizer (from a different school) ask me "How did you make sure the good people still came out?" If you're asking about a very particular subset of people that don't need encouragement to go to a hackathon - yes, those people were in attendance. But more importantly, by paying attention to the sensitivities of the community, we were doing just that - making sure the good people still came out.
Shared publiclyView activity