Major League Hacking is one of those names that crops up time and again in developer relations circles. Working with a global community of 65,000 student developers, MLH is behind 240 student hackathons each year. They also run on-campus training and are one of the new mission-driven B-corporations.
Shortly after DevXCon 2017, I spoke to MLH co-founder Jon Gottfried to learn more about what they do. After hearing from GitHub’s Joe Nash on how they manage their student developer outreach, I was particularly interested in the benefits to students of taking part in hackathons.
Jon: There’s a number of reasons why people participate. A huge one is that it’s fun. The people that we work with are self-selecting to spend their weekends building technology rather than partying with all their friends. You have to really love it if that’s what you’re spending your free time on.
But there are a lot more concrete benefits as well. A lot of our students are looking for internships or jobs once they graduate. And it’s different from a professional hackathon where it’s taboo to be recruiting people. At student events, that’s a huge motivation for why people participate. They don’t necessarily get exposed to the tech industry on campus and hackathons are a great place to meet companies and potential co-workers that are doing interesting work.
The last thing is exposure to new technologies. CS courses tend to be very academic and not necessarily practical in the industry sense. Hackathons are a place where you can learn to use both software and hardware tools that are pretty bleeding edge. I don’t know what CS class is ever gonna teach you how to deploy a container to the cloud. This is a chance where they not only learn how to do that but also put it into practice in a real project that they’re creating.
Matthew: Do you see students who’ve been through MLH programs doing better once they head off into the career market?
Jon: Absolutely. Think about the difference between someone who has done tons of independent projects, whether at hackathons or otherwise, versus someone who has just done the required course work in a CS class.
Hiring managers want to see that the engineers that they’re going to hire are experimenting, and working on a variety of projects and building expertise outside of what’s required of them. So, they do tend to be more sought after as employees and I think that the mindset that they’re developing of how to solve problems and how to work on a team, and how to build using new technology is something that takes them pretty far in the industry.
All the collaboration and problem solving and experimentation is hard to learn without actually sitting down and doing the work.
Matthew: Hackathons really easy to get wrong. So, why would developer relations people risk all that money and time on hackathons?
Jon: I would actually draw a distinction between student hackathons and professional hackathons. People’s reasons for attending, the scale of the events, and ultimately the ROI tend to be very different.
The organizations that are most successful at student hackathons are companies that understand the long tail value of a developer. You spoke to Joe Nash recently. Joe works for GitHub, who is one of our major global partners. And for GitHub, it’s really important that people know how to use GitHub, from the beginnings of their careers.
They may not become an enterprise customer for a couple of years, but the truth is that if people have it in their tool belt and they know how to use it, and they know why it’s important to their projects, that creates a ton of long tail value. I mean, when I was doing developer evangelism, we used to see all the time that someone would build a hack using a technology then throw it away after the weekend. But they would come back six months later because they now knew what our product was useful for and put it into production at their company. It’s not something where you get an immediate return that weekend. Certainly, you get a lot of brand awareness and immediate sign ups. But the real value is getting developers to the point where they’re familiar with your product and how it works and where they might want to use it for something when the need is right.
Something people get wrong about hackathons is that they expect it to be an immediate revenue generator. They expect it to be something that makes a really fundamental shift in their sales channel. I look at it as an education and brand awareness play, where if you want developers down the road knowing who you are, thinking about using your product in production, and implementing it in the right situation, then they need to have a point where they’re enjoying using it and building something cool with it. That’s memorable.
Matthew: So, what do you say to people who are looking to organize a hackathon? There are certainly plenty of agencies out there who’ll run your hackathon for you in exchange for a big fee but I’m not sure that you can outsource that kind of thing.
Jon: Well I tend to agree with you that outsourcing a hackathon is almost always a mistake. I have seen situations where it works really well. I have a friend that contracts with the Museum of Natural History in New York to run their hackathon. The museum has no incentive to have an in-house dev rel team, but they get a ton of value out of engaging that community. That’s one of the situations where I’ve seen it work and honestly, similar situations with governmental agencies, or non-profits or something along those lines, are the most successful examples I’ve seen of outsourcing the organization of a hackathon.
But the truth is that engaging developers and in many cases, putting on developer events, is a core competency of a developer marketing or evangelism department. Honestly it might cost them the same to hire one full-time dev rel person who could do that type of event in a more authentic way, versus hiring an event planning agency. Having said that, there are a few agencies that put on really great events. We definitely pride ourselves on being able to augment great dev rel teams with our scale and expertise, and the most successful agencies do the same.
Hackathons aren’t the only type of developer event. There are conferences, there are training days, there are workshops, there are meet ups. It’s just one component. The reason that people look at hackathons, in my opinion, as kind of this “end all, be all” is that it combines a lot of those other aspects. There is an education component, there is a user onboarding component, there’s a feedback component, there’s a press component. There is a community building component. You know, all of those things come together at a hackathon, but that doesn’t mean that it’s a solution to everyone’s problems.
There are certainly companies that get really involved with hackathons, and then kill the program when it’s not successful. We try to filter pretty well at MLH for companies that we think will get a lot of value out of our events, but also provide a lot of value to our students. As a company, we’re actually a B Corp, which means that we’re a mission-driven for-profit company and our mission is to empower hackers. So, if we’re engaging with a customer that we don’t feel aligns with that mission, it’s probably not going to be a good engagement for us or our community. We take that into account in a pretty meaningful way. Developers are most successful when they get value from sponsors, and honestly, sponsors are most successful when they’re providing a lot of value to developers.
One of our most successful lasting partnerships is with Amazon Web Services. They provide credits to all of the students that go to our events. Students want to be able to host their projects. They want to be able to learn this technology that they hear about all the time, and Amazon wants the students to learn about their product offerings. So, it’s very mutually beneficial, and that’s the lens we look at a lot of our offerings through.
Matthew: So, how do companies tend to work with MLH?
Jon: There’s a couple of things. One is, you can sponsor an individual event. This is something that’s fairly cost-effective from a sponsorship level but you have to factor in people, time, and travel. But that’s a really good way to dip your toe in the water. Once companies want to do a bigger engagement, that’s really where MLH starts to get involved and most of our sponsorships are either global or national.
We will roll out programs that we’ve developed with a dev rel team across all of our events. So, whether that’s a promotional program like what we do with Amazon Web Services or GitHub, or whether it’s a training program like what we have been doing with Docker, there’s a lot of opportunities where we provide the scale component. And we partner up with you to develop the content and promotion, so that you don’t have to fly someone to 250 events a year. The cost for sponsorship is higher than it would be for one event, but it balances out when you look at it on a per event basis.
We love this community, I really enjoy being part of the developer relations world and, you know, we’re always happy to offer advice or services to help people be successful.
All the fun stuff happens with shiny new tech, right? Nah. You can get audiences excited about older tech, if you serve them well.
Are dev rel teams just here to make everyone feel good about using a technology or is there a deeper responsibility?