ASTRID:  Welcome everyone to Episode 27 of ‘Plotting the Rebellion’. My name is Astrid Countee and I’m here today with my guest and friend, Sam Livingston-Gray.

SAM:  Oh, I’m just a guest now, but at least I’m a friend too. So, thank you.

ASTRID:  I want everyone to feel special, Sam.

SAM:  Why, thank you. I do feel special. Also here to be special is Rein Henricks.

REIN:  And super special thanks for asking and our special guest — see what I did there —

SAM:  I do indeed.

REIN:  — is Rachel Katz. Rachel works for AngelHack, the world’s largest developer ecosystem where she oversee social impact and diversity initiatives through their hackathons and HACKcelerators. This is included the Lady Problems Hackathon, the Ctrl Alt Delete Hate Hackathon and the Global Code for Impact Challenge in 63 countries last year. She lives in San Francisco where you can find her complaining regularly that the bagels just won’t ever be as good as New York City, which I think is fair.

RACHEL:  That’s why I had avocado toast this morning, like a true Californian.

SAM:  What was it, sourdough toast?

RACHEL:  At my house, we’ve been experimenting with fermentation so it was kind of a sourdough but it was more of like a whole wheat with a bunch of different types of flour and yeast.

REIN:  Oh, hipster toast. Yes.

SAM:  Fancy pants toast. Awesome.

RACHEL:  Well, it’s not fancy because it’s [inaudible] and didn’t arise so it’s more like hipster-I-don’t-know-what. Anyway, I’m not here to talk about bread but very serious about bread.

ASTRID:  Rachel, why don’t you tell us your origin story and how you got your superpowers.

RACHEL:  I’m not sure how far back to go…

SAM:  Beginning of time.

RACHEL:  Let’s see. my first experience with interacting with people as it relates to computers was — and this is probably going to date how old I am — doing stuff on AIM like doing various types of chat rooms on AIM. I don’t know what that means but anyway, that’s where it started: AIM, Geocities, Myspace stuff. Then thought I wanted to become an art therapist, studied that for a little bit then decided to become a real adult, study communications, got into philanthropy and was working in philanthropy for five years on big projects where people put a lot of money into things and then really see that much impact. Then got to do a couple of hackathons in the social impact and philanthropy space, got totally hooked on it and addicted to it and then sought out the hackathon space specifically, got sucked in and worked out about 100 hackathons last year.

In terms of my superpowers —

SAM:  Let’s see, if it was 100 hackathons last year, I’m going to go with super endurance.

RACHEL:  Yeah, super endurance being able to go without sleep for a long period of time if I was excited about something, which is probably true for a lot of people. I would say that’s probably my superpower.

ASTRID:  How did you get hooked on hackathons?

RACHEL:  I was going to joke with my teen like I always cry at the end of each hackathon, which sounds a little bit terrifying. But there’s just something about it that is really moving to me personally. I guess it’s about people creating things and coming together around a specific issue or topic and working tirelessly to create something. I wish I could say I only cry at the social impact hackathons but honestly, I’ve been known to cry even at boring, like [inaudible] hackathon.

There’s something about it that resonates with me and I think it’s the amount of impact you can achieve in 24 hours. But the one that hooked me was this hackathon called Chimehack with Gucci, which is a fashion company, not a technology company. We had somehow convinced them to do a hackathon at Twitter and it was for a bunch of non-profits like UNICEF and Vital Voices and UN Women and a really cool organization called Writers for Health and this mobile health services delivery. There was just something about it. We had high school girls hacking, we had experienced developers hacking, we had the CTO of Twitter there and hacking and they built the stuff for these nonprofits that some of them can actually use. It was just really cool. I had no idea what I was doing. In my mind I was like, “We’re going to do hackathon,” and then just literally figured it out. I had no idea and the outcomes are pretty cool. That’s the original one that hooked me but I get hooked pretty much every time I do it again and again. It’s just my thing.

SAM:  Rein, I understand that you have thoughts about hackathons.

REIN:  I have thoughts about hackathons. I don’t hate hackathons in general but I think that there are some bad hackathons especially the corporate-sponsored ones. They tend to be bad and I think that it’s a challenge to make them fair and available for everyone.

RACHEL:  It’s definitely true about certain hackathons. That episode with Zuri Hunter was the first time I found out about Greater Than Code because Zuri has come to quite a few of our hackathons and she was talking about her experience in those hackathons and that’s how I found out about your show actually. I mean, not all corporate hackathons are good. We do a lot of corporate hacks. As much as I love doing the social impact hackathons, corporate hackathons are kind of worth at in terms of running a business, I’ll say and they’re not all made equal. I agree with that statement and we can dig into it more if you like.

We try to make it as uncorporate-y as we can. We don’t always succeed at that but trying to make it fun and inclusive and it’s hard. We’ve been working a lot on trying to make them more inclusive and diverse, in terms of skill sets and backgrounds but it’s always something we have to keep trying to do better and better.

REIN:  I could describe more specifically what my issues are. My general issue is that hackathons are available to people with the free time to spend working on the stuff that people tend to work on. My specific issue with corporate hackathons are sometimes you do things that benefit this company and we’ll pay you with pizza for your labor.

RACHEL:  Yes. Now, the free time point, that’s an interesting one and something we’re trying to figure out is how do we shift this model around. I mentioned a topic that I was thinking about discussing with you guys was this concept of there are projects that need help and need to be worked on but the kind of people who might be able to help us on this project don’t necessarily have a weekend to devote to hacking. We’ve started doing a lot more virtual hackathons. We just had a global block chain one as block chain for public sector with the government of the UAE. That one, we have people from all over the world hacking.

Then we’re doing one right now called DataHack4FI which is a financial inclusion hackathon across seven countries in Africa and that one is virtual. We’re trying to figure out new models where, say you are not a student or someone who’s in their early 20s, no obligations besides a weekend to spend hacking and doing it overnight. We’re trying to figure out new models for that. I think that’s a valid criticism.

Although, we’ll probably keep going with that Saturday and Sunday hackathon model for a while because that is fun for a lot of people. Then the free labor question, I think what we always try to do and I don’t think it’ll fully solves that question is making sure that people own the IP that they create out of the hackathon. Then the majority of our hackathon, we run this global series, we accelerate the teams coming out of those hackathons and they own their IP so the idea is that they can continue building that project and make it into business they would like. We’re trying to course correct for some of those criticisms which I think are valid. That how I would address that.

REIN:  Yeah, I don’t think it’s impossible to have a hackathon be a good thing but I do think that there are a lot of traps you can fall into where it’s easily for it to end up being bad. What I mostly care about is what do you do to avoid those problems and to promote healthier ways of organizing and things like that. I’m glad that you’re thinking about that stuff, which doesn’t also doesn’t surprise me. You seemed to care about this a lot.

RACHEL:  We always talk about the typical hackathon that looks like a roomful of dudes in hoodies who are in their early to mid-20s and we want to expand that to more people. One of the things we’ve been talking about a lot is bringing more women into our hackathons. We’ve done a lot for that but for me, it’s never going to be enough. It’s still not enough. We were able to increase our diversity attendance to 60% female for our last hackathon series, which is awesome because it’s usually around 20%. But still, it’s younger women and it’s younger women that have a certain level of privilege where they can spend an entire weekend at a hackathon. We’d love to look at doing things like childcare and stuff like that but it’s step by step. Sometimes it feels like two steps forward, one step back but definitely a fight that we’re trying to fight.

REIN:  I’m just glad that you’re aware of these issues. So many hackathons I see were just [inaudible]. They don’t even consider these things and then it doesn’t go as well as you would think. Do you any suggestions for companies that wants their employees to hack on stuff or people who want to organize their own public hackathons to make sure that they’re addressing those issues?

RACHEL:  There are a lot of things you can do and in some ways, part of it is just blindingly simple. Unfortunately, people just don’t even think of these things but very basic stuff like your judging panel needs to represent the community that you want to come to the hack. People talk about this a lot but making sure that the folks who are in the judging panel and your mentors aren’t all of one category. If you want to be inclusive of women, if you want to be inclusive of different races and backgrounds, the judging panel represent that, the staffing should represent that, the mentors at hack should represent that.

I think also it’s in the marketing of the event and making sure you have an inclusivity statement that is very clear. Making sure you have a code of conduct. There’s an international hackathon code of conduct that covers harassment in hackathons, which has been an issue in the past and we’ve had to kick out or ban people for life for misbehavior and it’s something we’re very serious about, instead of being you must stay overnight — staying overnight is optional — being flexible about when people can come and go. I’ve had a lot of people e-mailed me before the hackathons and say, “I have a childcare issue. Can I still show up at 4PM?” And I’m like, “Yeah, sure. Come and we’ll figure out how to fit you in.”

Those are some examples that come to mind but I think a big part of it is in the pre-hackathon: marketing, being inclusive, reaching out to groups of different types and diversities. Then on the venue being closed from 11PM to 7AM so you all can get some sleep, we do that from time to time. We did a Tech for Good Hackathon at the University of San Francisco a couple weeks ago and we closed down the venue and people went home.

We had to force some people out and they were like, “Wait. This is not an overnight hack?” And I was like, “Nope. It’s not,” and I was like turning off the lights and telling them to go home. It’s always that balance of I want to support the enthusiasm of the people want to come overnight. We have some hackathons where we have high school students and their mom literally pulls up in their minivan and drops them off their sleeping bags and pillows and they love doing the overnight. I just realized that potentially it’s free babysitting —

[Laughter]

RACHEL:  But they love it too but we’ve experimented with the no-overnight. We’ve also experimented with the one-day event but then the question is around the impact of those outcomes like what can people build in a certain amount of time and how much do they want to dedicate to building that and how functional do they want it to be so that’s another thing to add to the mix and figure out the right blend of the hackathon model.

ASTRID:  Rachel, do you have any advice for people who are not programmers but who want to be involved in hackathons because a lot of times, the biggest, I guess hesitation that I encounter is people saying, “I would love to go to this hackathon but I don’t know how to program so I don’t think I’m supposed to go.”

RACHEL:  You should just go, I guess would be my advice. Do you all identified as software developers?

ALL:  Yes. Sure.

RACHEL:  Okay, well —

SAM:  That’s okay. You can talk shit about us.

RACHEL:  No, no, no. Obviously, I don’t want to insult basically what is probably 80% to 90% of our entire community but something that’s built by a software engineer in a vacuum is not going to have the same impact that something that has input from someone who’s not a developer will have. For example, at this Ctrl Alt Delete Hate Hackathon we just did, it was a mix of developers and designers and just marketing folks and then activists in political and nonprofit space.

They were able to talk a little bit more about the user experience and what this would mean for the nonprofit that they were building tech for and they definitely it’s something to contribute. I think, specifically at our hackathons, when we do team formation at the beginning, we advise teams to make sure you have someone who does UX or UI design, someone who has business or market experience or experience with the users you’re trying to reach on your team because you’re going to be more likely to win.

We actually appeal to the competitive spirit of the developers at our events by saying, “You’re more likely to win or build a better killer app if you have more diverse perspectives on your team.” That gives us the concept that we have like the whole developer, meaning someone who’s not just a developer, a software engineer or not just a team of software engineers but holistically looks at a problem.

It’s really long answer to that question. I would just say, if I would give advice to people, I would say just come and if you feel uncomfortable or you feel like you don’t fit in, you should address that directly with the organizers and have them help you find a team. I always do that at the beginning like everybody comes up, introduces themselves as what are their skills, what is their background. A lot of times people come and say, “I’m new to hackathons,” and then we always give a round of applause for anyone who’s the first time hackathoner because that takes a lot of courage to show at hackathon, let alone introduce yourself to a group of 100 strangers. Then we make sure that everyone finds a place on a team.

I guess that goes back to the question about how to make hackathons more inclusive. I think that burden definitely relies on the organizers and then what I would say to the developers that come to hackathons is be open to not engineers being on your team because you’re going to get better perspective. You can have a super awesome functional app that is useless to the person it’s meant to serve so thinking about that is really important.

SAM:  You touched on something really interesting there, which is there’s an aspect of the developer psyche that leads us to value our own skills above everything else. It sort of captured in this idea, in that Jamie Zawinski quote, “I had a problem and I tried to solve it with regular expressions and now I have two problems.” But you can replace regular expressions with software, right?

My first tool of choice, when presented with almost any problem is I wonder what code I could write to fix that. I’m old enough now to recognize that maybe that’s not the best first reaction but I can’t always stop myself from having it or following up on it.

ASTRID:  I think that you’re trying to say that you’re going there because that’s what you do all the time but it may not be the best way for the problem to solve but then how do you find the space to be open in the right place so that somebody else different way of problem solving can be a part of the solution.

SAM:  Yes. It’s like you’re inside my head.

ASTRID:  I kind of am because since I wasn’t always a developer, I actually don’t start out thinking what kind of code could I write so I have a little bit more empathy I think for people who are trying to be a part of the group but they don’t have coding skills.

REIN:  Rachel, I think you said something really important earlier, which is that if you have a diverse group of people building something with the different ideas and experiences and backgrounds, the thing is better because of that and that’s a good reason to do that.

RACHEL:  Yeah. Have you guys talked about the movie Code: Debugging the Gender Gap on this podcast, yet?

ASTRID:  I don’t think so.

SAM:  No, I haven’t even watched it yet.

RACHEL:  You might have a guest and I’m about to refer to you, Astrid which they talk about this specific issue of when you’re building things in a vacuum, how terrible that can turn out if you don’t bring in diverse perspectives. There’s one very serious example that they get and one very funny example that they get. I guess I’ll go with a very serious one first which is they talk about the design of airbags and how — is it airbags or seat belts? It’s probably —

ASTRID:  I think it was airbags.

RACHEL:  It’s airbags, and how the folks who originally designed the airbags were men and they were designing airbags for men and then airbags ended up killing lots of women and children. That was an engineering problem. If they have had women as part of the process, probably they could have mitigated that issue. Then the second one is a funny one which is they talk about Clippy, the Microsoft little AI assistant and how women in a focus group found Clippy to be creepy and weird. But the men who designed it were like, “That’s not a valid criticism.” Then they ended up rolling out Clippy and we all know what happened.

SAM:  It’s like the software avatar of mansplaining.

RACHEL:  Yeah, exactly. I love talking about this two examples. I think one shows just how dangerous that can be and also how important design is in the airbags scenario. Then for Clippy, I just want to be hilarious but also becoming more relevant because pretty much every hackathon on app now, people are building chat bots and virtual assistants. They’re doing that right now and my concern is making sure they’re thinking about that. At the Lady Problems Hackathon, there’s actually people building a lot of chat bots around tracking gender bias communication and then there’s a chat bot for impostor syndrome that someone built called Pepper the Pet Bot. I do think people are using these things for good but they should use Clippy, I guess. I mean, I don’t know how many people Clippy hurt or harmed but —

ASTRID:  It was weird. I remember as a kid and I was like, “Why won’t this thing go away. Is it watching me?” It’s weird.

RACHEL:  Remember it’s used to wink at you — I’m doing it and you guys can’t see my face but I’m doing like the hard blink like Clippy’s.

SAM:  Oh, yes. I may or may not have given a presentation talk in which I mentioned Clippy and then used the fire animation on it.

ASTRID:  I think that that airbag example is actually a really good one because in the documentary, they talked about how the engineers were not trying to be assholes basically. They weren’t thinking like, “We don’t need women.” They were trying to save lives and they were so focused on what they were doing that they forgot that everybody is not going to be somewhere between 5’10” and 6’2″ and at least 180 pounds. When people started dying, they were shocked because they didn’t think about it. It wasn’t something that was on their radar so they were really upset by what happened. I feel like that’s what you’re trying to do when you’re saying make your teams more diverse, try to get other people’s opinions because you may not have this intention of being an asshole but you don’t always know what you don’t know.

RACHEL:  Yep.

SAM:  Right.

REIN:  There’s also the example of the facial recognition software that couldn’t recognize black people.

RACHEL:  Yeah.

ASTRID:  But that was more intentional.

REIN:  Was it?

ASTRID:  Yeah, because that had to do with Kodak and they were basically trying to sell their cameras and they were focused exclusively on white audience and they were not trying to be inclusive. It evolved from there, whereas with the airbags, they weren’t actually trying to assume that women never drive cars. They just forgot.

SAM:  For our listeners who may not be familiar with the thing that Astrid just very compactly referred to, film that was calibrated in the 50s and 60s with color film, rather was calibrated with reference shots of white people which is why film did a really poor job of representing the full range of human skin, thus made black people look terrible on camera for decades. Then that cultural legacy is part of what fed into this incident with, I think it was a webcam software developed by HP that would do facial recognition and tracking. They had a little camera that supposedly would follow your face around but it did not recognize black people because all of the subjects that they trained it on were white.

Is that a fair summary?

ASTRID:  Yes.

REIN:  And on the one hand with things like that, I think I wonder how many black people they had on that team. On the other hand, I think we build websites that are accessible to deaf [inaudible] people, blind people. I don’t have any blind people on teams that I worked on which is something I’d like to do. I know some, but I haven’t work with them. But my point is that you don’t have to have a black person on the team to have it recognized black people. You just have to care about the [inaudible].

ASTRID:  You do but I think also what tends to happen is, at least in tech you have a lot of people who are trying to change the world with whatever it is that they’re building but they’re not going out and talking to people who are a part of the world, who are not like them and they’re not having those people on their teams so you end up having something that goes out into the world that can do harm because you totally left out all kinds of scenarios that you just don’t know about.

REIN:  Yeah, absolutely. I guess my point is that one way to make sure that your team is putting its attention there is to have someone on the team to represent that viewpoint and the other way is to just make sure that you yourself are representing that viewpoint. In the case of the facial recognition software, you don’t need a black person on the team. You can just think about the problem and make sure that you’re testing it with a diverse group of test subjects and things like that. It looks like they did neither of which is possibly intentional but definitely pretty awful.

ASTRID:  One of the things I wonder how you do is how you do this in practice because when you’re in a hackathon, for instance and you are in a team, a lot of the team they may be software developers, how do you steer the group towards these questions because it is easy for you to just start working on who’s going to do the UI, who’s going to the backend and what are we going to make as our data story. Those conversations start really quickly so I’m wondering Rachel, if you have some idea or some tips of how to keep that conversation about who you’re actually building it for before you start working on building things.

RACHEL:  I guess, I could talk about from the hackathon perspective which we always include UX as a criteria for judging for hackathons. When we’re talking to our teams about thinking about what we’re going to demo on Sunday and this is about how do you build the structure of a hackathon to make sure that the outcomes that are created are the outcomes that you want to get. I think that brings on having user experience as a criteria for hacks so letting people know one of the things that it is going to be based on is have you thought about the end user experience of your product. Some people listen to that and some people don’t. I think the best you can do is try to instill that question in yourself and then instill it in others around you. My hope is eventually is it becomes a viral thing and I think it is.

Everybody loves to talk about design and thinking these days. We get more and more UX and UI folks come into our hack. They’re super in-demand. We had a UX person in our hackathon and he was floating around to every single team because everybody just wanted his input. That was cool to see all the developers be like, “Where’s the UX guy?” That was cool.

REIN:  One of the things that I’m really interested in is how people organize into relationships and power structures and sometimes that’s hierarchical and top down in the company and sometimes it’s self-organizing and my question is you’ve done a bunch of hackathons and you’ve seen people, I’m guessing come together and sort of self-organizing into teams. Is that the thing that they do? Who ends up taking on leadership roles in those team, is it more men? Is it more women? Is it more engineers? Is it more entrepreneurs? Who ends up in those leadership roles and what does that power dynamic looked like?

RACHEL:  It really depends on the hackathon. There’s no standard. It depends on the topic of the challenge. For the Ctrl Alt Delete Hate Hackathon, a lot of people just came in like, “I want to use my skills for good. I don’t necessarily know what I want to build.” In some scenarios, we had people who actually have the issues expertise leading the team versus an engineer or developer, they were just helping build the vision for the team.

If it’s a hackathon about machine learning, probably a lot of people are there just to learn about machine learning and flex their skills around that but somebody who actually has experience with that will end up being the team lead. I guess it’s sort of skills and knowledge base, depending on what the challenge is. Then I guess there are scenarios where nobody knows what they’re doing.

In terms of the power structure there, I’m not sure. I guess it’s just who yells the loudest, which probably isn’t a great answer. Now, that’s got me thinking about how do we think more about those dynamics within the teams as well. But if I had to give a short answer, it would be skills and knowledge based is where the lead is.

REIN:  Can you extrapolate it all from all the teams that you’ve seen as far as what make a self-organizing team, more or less, successful if I’m going to define success in terms of doing well in the competition, in terms of the morale of the team, how people feel about each other and how nice everyone is?

RACHEL:  You can always tell people go up on stage on what that dynamic is. At a hackathon, if one person goes up and the rest of the team doesn’t go up, that means something. We advise against more than two people talking because that can usually turn into chaos but if there’s more than one person doing everything at a time, that means they’ve all communicated with each other about who’s doing what and what role each person has to play. You can see that at the end and often when judges are judging projects at hackathon, don’t notice those team dynamics and the execution is typically much better on the project if everyone is listening to everyone else and they map out who’s doing what from the start and what role each person has in the build. The quality of the project is almost always higher if everyone on the team has had a say or an input.

Some people are better than others. We have some people who typically hack solo or in teams of two because they’re not good at group dynamics and we try to be inclusive of that as well. If you’re someone who just wants to be on your own, we are open to that.

ASTRID:  Rachel, I know that recently you had this Lady Problems Hack and I’m interested to know if there was a different mix of people who came to this hackathon and if you did see any difference in the way the teams interacted.

RACHEL:  Yeah, totally. It was a lot more women. Our goal was a 50/50 ratio. Typically, hackathons are 80/20 — 80% male and 20% female and it was very different. A lot more collaboration across teams so less competing with each other directly, even though there was a prize to win. We’re accelerating the winning team from each city. We did 17 cities but more collaboration across the teams.

Something else we noticed was — I don’t know how relevant this is to the question but I just thought it was an interesting observation that’s related to team dynamics and the quality of projects — women are a lot less likely to pitch at the end of the hack if their solution is not perfectly built or functional. Whereas, men will go up there and demo and pitch even if it’s not working and just do Slideware or show some of the code and talk through it. That was interesting even if the project quality was higher or good enough to demo or pitch, we had some women who were like, “I’m not going up there unless my project is perfect,” so that was sort of an unexpected roadblock that we ran into because a big part of hackathons is getting up there and showing what you build and knowing that there’s no way it’s going to be perfect in a 36-hour span.

Another thing we observed is people will much more collaborative, we didn’t have that issue with the confidence of going up there, even if your project wasn’t perfect. It’s a totally different dynamic. What people were building was totally different. We had four challenges around health, safety, economic, empowerment and culture and we didn’t know which way people were going to go and it varied in the different cities we were in.

In the Middle East and Africa, people focused a lot more on health and safety but in the US and Australia and Europe, people were much more focused on cultural bias. I guess that made it different from a typical hackathon and not the solutions people were focused on we’re very much designed for the group that was in the room. Those are some of the differences there.

SAM:  That’s interesting, that phenomenon of women pitching versus men pitching tracks really well with this phenomenon of people applying for jobs where men will apply if they meet some portion of the requirements. I don’t know what the actual number is — 40%, 50%, 60% or something like that but women will not apply for the job unless they meet all or nearly all of the requirements.

RACHEL:  Yeah. It’s crazy. I’ve seen people go up and pitch things that are completely not even relevant to the hackathon and still the confidence and they goes up there. There is this one group of people who were coming —

SAM:  When you say people, I’m assuming you mean, men?

RACHEL:  Men, yes. Young men. I don’t want to call them specifically because they come to a lot of our hackathon and they’re great but somebody must have dared somebody else at some point to pitch Tinder for Music at all of our hackathons, regardless of what the challenge was or what the API platform was they were supposed to using. They just pitched Tinder for Music for all hackathons.

Honestly, it’s probably just like a fun griefing strategy but to have a confidence to go out there and do that in front of a hundred people and kind of my job would be like not relevant, don’t even care versus of I’m thinking at Lady Problems London, we had a woman who’s building an app and she was doing really well and then her code just fell apart at the end of the day on Saturday. We did everything we could to try to convince her to come back and get people to help her and jump in. She was just like, “No, this is a piece of crap. I’m not demoing this at the hackathon.” It’s just typically, overall it’s hackathon we see, that’s the case. Some people will just go up there, regardless of how good or relevant their project is and pitch. At Lady Problems, we’re often have to encourage people to get up there and pitch, “Even if it’s not perfect, just get up there and show your stuff.”

REIN:  Oh, pranks. Yay!

RACHEL:  Yeah. There are probably less pranks at Lady Problem so maybe that’s another observation. It was definitely a much more safe, inclusive space.

REIN:  What if pranks are actually bad?

RACHEL:  Yeah, pranks can be bad.

SAM:  I want to, at least briefly touch on this idea that what we’re talking about is not just some observed phenomenon with no possible cause. This is a learned behavior where men get praised for a lot of things and they have their confidence built from the time they’re boys and girls do not. When they grow up into women, they are afraid to pitch something that isn’t perfect because they know they’re going to get a lot more crap for it.

RACHEL:  Yeah.

ASTRID:  But what I find interesting is that, Rachel had said that the majority of people of this hackathon were also women. Efforts are usually made to try to create environments where women feel safe. Even in this environment where you actively tried to make sure that it was going to have more representation of women, a lot of women still didn’t feel confident enough to pitch their own project.

RACHEL:  I wouldn’t say it was a lot. I don’t want to discredit like we had women all over the world pitching badass stuff so it wasn’t totally systemic issue. It was just an unexpected observation that we ran into at quite a few of the hackathons: encouraging people to get up there and pitch. I had that with men too with hackathons like everyone has done their work, everything falls apart and shit hits the fan, usually at two in the morning on Sunday and encouraging them to still go do it.

But specifically, it was much more of an issue at Lady Problems. We talked about it too like is the pitching format right, like making someone go up on stage and demo versus doing a science fair type feedback. It does relate to the structure. It certainly is an issue and it’s systemic.

We did a Lady Problems in Delhi, India and the last time we did hackathon in Delhi, the female turnout was 3%. The idea that you need to go to an event with a bunch of men and stay there overnight and travel to it and come home, it’s not a very safe concept in certain regions. When we did Lady Problems, just for the fact that we have set up as inclusive space, we had a 20% female turnout for that event so that was an increase of 17% and part of it was just letting them know there was a safe space and the challenges were related specifically to women’s issues made a difference.

I don’t know, it’s also different in different regions in the world and how that’s been ingrained or not. I don’t know where I’m going with that but it’s a tough question because we’re talking about how women and men are raised from birth and then on top of that, we’re trying to do this in Gaza, India, Nairobi. There are certain things that are true across the board and then certain things are more or less true in the different regions.

REIN:  I’m sure, it’s just a coincidence that a lot of failures happened at 2AM.

[Laughter]

RACHEL:  Yes. Some of the Lady Problems, we didn’t do an overnight because it wasn’t safe. The hackathon we did in Gaza for Lady Problems, there was not an overnight.

REIN:  Okay, here’s a question. Have you noticed a difference in success rates for hackathons that have overnight participation versus those that don’t?

RACHEL:  Not really but what happens is a lot of people go home and keep hacking, anyway.

REIN:  So they get all of the negative effect of working overnight, whether they’re not supposed to.

RACHEL:  Yeah but —

SAM:  But they do it to themselves, Rein.

RACHEL:  Yeah, they sort of do it to themselves. I think it’s a good point but some people like that. For some people, the reason they do hackathons is they’re like, “I’m going to dedicate 48 hours to learning this new topic and then I levelled up, one or two levels in that skill,” and they like that intense crunch versus running something out like a virtual hackathon which is one to three months and you’ve got plenty of time to learn.

But some people don’t have that self-discipline, including myself. If I had to work on a project that doesn’t have a strict deadline, that project is not getting done until 24 hours before. I think it’s also about people’s work styles. For some people, they don’t have three months to work on a project. Maybe they only have one weekend to learn a new skill so that’s the flip side of that.

SAM:  Have you tried to do anything as part of the framing and set up for these hackathons that would help encourage people to fail and fail spectacularly and be proud of it? It occurred to me as you were talking that you could give a prize for the most glorious implosion of a project or talk about epic fails from previous ones. Have you tried anything like that?

RACHEL:  No but I love that idea. It depends on the hackathon too. If it’s a super high stakes hackathons like we do this big hackathon called Money 20/20 in Vegas. It’s tons of massive cash prizes and things like that. We have to be more careful about celebrating the epic failures because it’s so competitive. But at Ctrl Alt Delete Hate — sorry I am super obsessed with hackathons because it was just last weekend and I didn’t sleep the entire weekend and it was awesome.

That one, we had people come up and demo then their laptop died in the middle of the demo and they haven’t gotten their simulator set up yet on their laptop and I was just like, “Fine. We’re just going to put you at the end and you can start over,” and it was kind of funny. It was very safe space and I was like, “Oh, you screwed up. You’ll get another try,” and I love that.

But when you’re doing like a 600-person hackathon, there just literally isn’t time because people would be there forever demoing for that. It depends on the type of event you want to create and different people like different types of events but I like the idea of celebrating failure. As a company, we celebrate failure like whenever someone screws up at our company, it’s almost there’s a little internal celebration about it like, “We f’ed that up. Oops.” I like to try and fit that and structured into the hackathon a little bit more and be interesting.

SAM:  Yeah, it just seems like an interesting way to sort of help set the tone at the beginning.

RACHEL:  Yep. I’m writing that down. ‘Failure.’

ASTRID:  Glorious failure.

RACHEL:  Glorious failure.

SAM:  I learned so much from those.

RACHEL:  In the hackathon, in itself, the majority of the teams don’t build like a fully functioning solution that’s ready to go to market. It’s almost to see how good you can fail, sort of, at a hackathon, like in 24 hours, to build something and learning a totally new topic and I figured that out all in a weekend so in some ways, everybody kind of fails, just seeing who failed the best. Or can you fail in an interesting way? I’m not 100% committed to that concept but I do love the idea of celebrating failure.

REIN:  Benjamin Zander is a conductor for the Boston Philharmonic and gave a TED Talk about leadership, which was very good. He tells his students when they make a mistake, he tells them to throw their hands up in the air and say, “How fascinating?” Rather than getting really upset and hunch over and get angry with themselves. It’s interesting because actually changing your posture and not letting yourself, put your body in a position to put yourself in when you’re sad, it makes a difference. I’m really interested in ways that we can get around or rewrite people to not look at failure as some sort of [inaudible] that they have to avoid at all costs because it turns out that failure is actually one of the best things you can do if you’re trying to learn.

RACHEL:  Then there’s the flip side of that which I thought there’s this issue in Silicon Valley around moving fast and breaking things like celebrating failure so much so that you don’t think about the collateral damage with that mentality.

SAM:  Yeah, that’s a really good point. Thank you.

RACHEL:  Yes, like how do we celebrate and have failure be not something that’s scary but also not have it be so ingrained that people are like, “I’ll fail at any cost.” I don’t know…

SAM:  Celebrate learning from failure?

RACHEL:  Yes, celebrate learning from failure.

REIN:  You have to put in the work to make it safe to fail so mitigating the downside risks of failure and things like that.

ASTRID:  You mean like a safety net kind of thing?

REIN:  Yeah, exactly.

ASTRID:  Okay, that makes sense.

REIN:  Safety net mitigate the downside risk of falling out of the trapeze or whatever.

RACHEL:  I think that [inaudible] the user experience question, right? Like if we fail, what’s the fallout? Who does that impact? It’s like if we fail to design this properly, what’s the collateral damage and you think about that in advance. Often the reason people fail is what they haven’t thought of all the right things so it’s like Catch-22.

ASTRID:  Yeah, this is like what I brought up in our last show which was that computer scientists don’t have to learn about ethics and that seems to be reflecting in a lot of what’s going on. I do think that this is an opportunity for somebody else who has that background or understands those questions to try to join this hackathon teams because they do have this perspective of, “We should be thinking about what happens when this fails. We should be thinking about the consequences of picking this particular route to take with whatever it is we’re building.” Since oftentimes, if somebody did study computer science, they’re not going to have that in their background and a lot of people are also self-taught so they may not have it there either.

SAM:  As somebody with a computer science degree, I believe there was a course offered. It may even have been like a one-credit requirement. In which case, I had it waived because I was looking at my transcript and I did not take it. Yay, me! Rather, yay my school.

RACHEL:  I think it’s an interesting question. A lot of people that come the hackathons are coming out of coder schools like Hack Reactor and General Assembly and Hack Right and things like that. I do think a lot of them are doing a good job at focusing more on inclusivity and diversity but I’m curious if they offer ethics as part of their overall bootcamp or program. I’m not sure, specifically but I think that’d be interesting because in certain parts of the world, that is a significant makeup of our hackathon attendants. Now I’m going to go back to my team and be like, “Guys we have to build an ethics workshop at every hackathon,” and they’re going to be like, “Oh, God.”

ASTRID:  I think that sounds like a really great idea.

RACHEL:  I do think, it’s an interesting concept. I’m writing that down too. I’ve written down ‘failure’ and put a big circle around it and then I’ve written down ‘ethics’ and put a big circle around it.

ASTRID:  Circles mean special things.

RACHEL:  Circles mean special things. A circle as inclusive. It should be an open circle actually. I need a close circle.

REIN:  I wish we could have an entire show just on how we approach failure.

RACHEL:  Yeah.

SAM:  Why can’t we?

REIN:  I don’t know. But we do the context of hackathons, I think failure is especially interesting because there are high pressure situation. There are unusual downside risks to failure. You’re not just losing an hour or two of work. You’re potentially losing money, prestige and a number of things that are normally on the table when it’s not your day job. I don’t know if I have a question there. I just think it’s interesting to think about what might some of the factors be that make people more afraid of failure in that situations.

RACHEL:  Yeah, I mean it’s more or less afraid because for most people, it’s not your day job. In some ways, it is an opportunity to fail spectacularly because you may not win the prize but you learned the limits of your own abilities and knowledge. As long as you can find meaning in it and learn from that, that has value in and of itself. Sometimes having those constraints or, I guess lack of constraints does have with personal growth. I’m not sure everyone has that experience but I think why a lot of people come to the hackathons is it’s not your day job so if the code breaks and it crashed the entire thing, yes that sucks but you’re not taking down the entire company.

REIN:  This is also a good example of a form of diversity that we don’t often consider which is how do people respond to stress. I think that people that run teams of developers should think about that on their teams.

SAM:  And what causes them stress.

REIN:  Yeah, because you’ll have some people that will respond to the same stressors in very different ways. That’s sort of what you’re talking bad at the hackathon as some people look at it as an opportunity to try things. “Well, if it doesn’t work, no big deal. It was just a hackathon.” Then other people are really that triers or really need to, “Show my work,” and have it be accepted and then they have a very different response.

RACHEL:  Yeah, that was something to think about. We just get all types like whenever someone asks me, give me the Person X at hackathon, honestly everyone is so different in the way they reacted and engage and approach the hackathon. Honestly, what we like about it and we wouldn’t change like we can put as much structure in place as possible to make it a positive experience for people but people will always react differently in those situations.

There are always people who are like I give a [inaudible] and someone who goes up a pitch is something totally not relevant, solves a great time versus somebody who build something amazing and it doesn’t have the confidence to pitch. It’s such a mix.

REIN:  When you look at the different ways that people respond to the pressure, some of them look at it as an opportunity, some of them end up quitting the hackathon, do you think that there’s a stigma associated with certain ways of responding to stress? The people that maybe don’t want to share their work when it’s not done, do you think there’s a stigma that other people associate with failure that prevents them? I’m just trying to get a handle on the dynamic there at the hackathon.

RACHEL:  No, I don’t think so. We always try to encourage people to pitch and share what they’ve created because I find that when people go up there and do it, they always get something out of it. It may just be getting feedback from the judges or it may just be having the experience of doing public speaking and you don’t always have the opportunity to do that. A lot of developers don’t have opportunities to do public speaking. In doing that or just the experience of having completed something, even if it’s not totally done, I do try to encourage people to pitch but we never shame people if they don’t.

REIN:  I didn’t think you did. I guess I meant more of other participants.

RACHEL:  Not really. People are so focused on their own thing. They get so in the zone on their own project, typically by the end but they’re not really thinking about other people or guiltiness in those people in anyway. Because everyone comes to get a different experience out of it, and I feel like everyone commonly accepts about everyone else at the hackathon is we’re all here to get something different out of this. There are new coders who just want to learn and build. There are the professional hackathon hackers who are coming to win the prizes and everyone respect everybody else’s space around what they want to create. If they don’t respect that space, we kick them out. I haven’t seen that. Yes, professional hackathon hackers is a thing.

SAM:  You’re blowing my mind here.

ASTRID:  There are people who actually make their living like that.

RACHEL:  Yeah and people are going on winning streaks too. Like I mentioned, we have a team of high schoolers and they’re actually not professional hackers by any means but they’re on a winning streak right now. It’s awesome. One of them is like 14 years old and winning hackathons but there are people who go to the big ones with the big prizes. I don’t know if I would recommend it as a career but you certainly can do it.

ASTRID:  I have a random question for you Rachel.

RACHEL:  Yes.

ASTRID:  In your origin story, you were talking about how you wanted to be an art therapist. Do you see threads of that in what you’re doing now?

RACHEL:  I think, if I dig into that, I feel like that’s a question that therapist might ask me.

[Laughter]

RACHEL:  Yeah, let me dig into my own psyche. I think I see tremendous value in how different types of media can create a therapeutic experience for people. I think ultimately, when I look at hackathons, that’s why it moves me so much because different people are getting different personal benefits out of experimenting with the media that they’re working within. Like they’re coding and they’re putting something together and for a lot of people that is therapeutic and be like, “I’m in this range of time and I’m going to try to solve this problem using this medium and even if the outcome isn’t a Monet, you still have that effort into creating something and creating meaning out of the medium that you’re working within.” Does that make any sense?

ASTRID:  Yeah.

RACHEL:  I think that’s why it gets to me because like this person just came for this weekend to create something for a prize and to learn but for the sake of creating something. We have accelerated quite a few businesses out of our hackathons but not everyone’s there to start his mess. I have honestly not thought about that until you asked me that question so I’m a little bit like, “Oh…”

ASTRID:  No, your answer make sense. I thought about it because of how you said you often cry at hackathons and it made me think, she must be really proud of how far they come in a weekend.

RACHEL:  Yeah, I am. I don’t know, there are just something about it like when someone gives their all and does something in a short amount of time. I honestly still need to unpack why hackathons make me cry. I don’t know…

ASTRID:  We don’t have to do a therapy session. It’s okay.

RACHEL:  But the same thing happens to me at marathons like I can’t watch a marathon because I just always cry. There’s something about that concept of people coming together to achieve things that don’t necessarily always have an immediate outcome. I guess when you run a marathon and you’re like, “I ran a marathon.” But if you run and going up like this, there’s something about that bringing people together around a specific topic in a finite period of time and they all show up and they all come out and they all contribute. Then they might go back to their normal lives. To me, there’s some power about that and I am, by no means, a religious person and I never practice religion but I think for me, it sort of ties to that like we are agreeing to share this collective experience and get some benefit out of it. It’s something like that. I’m not exactly sure where I’m going with that.

ASTRID:  We come to the time in the show where we try to reflect on something that came up during the discussion that stuck out or made impression on us. One of the things that stuck out to me about this discussion is how much talking about hackathons is really talking about all kinds of other issues. Because it’s an opportunity for a lot of people to come together who are different, it brings up things that we often describe around these tech adjacent problems of how do you make diverse teams, how do you encourage people to put themselves out there and to present their work, how do you make sure that you’re being inclusive. I didn’t really think about hackathons like that before. I just thought about it like a cool activity to do but now, it makes me think that when I participate, I’ll be looking around a little bit more to see how is this affecting everybody else too.

SAM:  I would like my reflection to be, that your reflection was awesome —

[Laughter]

SAM:  — I guess hackathons are sort of a little microcosm of development overall but I hadn’t really thought that through to the cultural implications and that’s great.

ASTRID:  Also I really appreciated, Rachel your criticism of developers because I don’t think that it’s bad to voice how a lot of people who are not developers feel at the hackathons. I think also a lot of developers don’t even know that they may be making an environment that’s not as open because they’re just doing what they do so it’s good to have some sort of feedback.

SAM:  Before you said your awesome thing, I was thinking back to the conversation about developers having a very sort of, defaulting perhaps to a very egocentric mindset and I was really struck by that reminder to me to not only just to make room for non-developers but to actively seek out people with those different perspectives that make everybody do better so thank you.

REIN:  We’ve been talking about that atmosphere at the hackathons and to feel the atmosphere, the pressure people that are under, how we deal with failure. There’s an aspect of coaching going under motivation. I mentioned Benjamin Zander earlier and I wanted to specifically highlight one of his talks that you can find on YouTube. It’s called Leadership on Display and it does something fascinating which is he takes a local kid who plays the cello. He put him on stage and he hasn’t rehearse a piece. As he’s going through the piece, he makes a variety of mistakes, they discuss the interpretation and that process sort of mutually creating that piece together onstage was fascinating to me — the way that he encouraged and made sure that the student was motivated. It’s really great. If you’re in a position of leadership and you’re looking at how to motivate people to do their best work and deal with failure in positive ways, I think you could take a lot of lessons from him.

RACHEL:  I guess if we’re talking to developers and software engineers, just having this concept of the hackathon being a microcosm for a broader ecosystem, I guess, developers and engineers are building the future that we’re going to live within. It’s this concept of we already have our [inaudible] computers and eventually, we’re all going to be living within some sort of coded system, depending on how global warming goes. Understanding your responsibility within this world and I think there’s something about responsibility and accountability within hackathons.

My initial key takeaway is going to be show up and contribute and listen. I think that fits within the broader context. I guess my key takeaway for engineers and developers is you are the stewards of the future systems that people are going to live within. Therefore, thinking about those people that are going to live within those systems and the ethics of that is extremely important and you’re not just writing code. You’re building this future system that people live within. Show up, contribute and listen.

ASTRID:  Thank you so much for being our guest today, Rachel. We had such a great conversation and we’ll see you all next week.