How to Set Up Mentorship at Hackathons

I’ve participated and mentored at a number of hackathons. I’ve also been doing the gritty sort of early stage venture building since around 2005 (more on that below). Having seen how not to do mentorship and having successfully mentored a number of teams, here is the recipe I recommend.

Here is a companion video that I’ve put together, in case that’s your thing.

Before the Hackathon

As with other things, the better you prepare, the better the outcome:

1. Knowledge Domain: Identify what knowledge will likely be needed for the hackathon.
2. Set Up Network Mentors / Sherpas: select individuals who will recruit knowledge mentors and to be conduits between teams and such mentors.
3. Prime Knowledge Mentors:
   a) Sherpas reach out to knowledge mentors to have them on stand-by during the event
   b) Sherpas add these mentors into a database so that teams can request the mentor (or have the knowledge mentors do this themselves, though this should not be a requirement, since the best mentors are also going to be the busiest)

At the Hackathon

A typical need for a mentor looks like this (at a healthcare hackathon):

• someone who is a:
  physician / nurse / patient / lawyer / sales specialist / administrator / etc.
• at a
  hospital / device company / insurance / etc.
• working on a
  drug / medical device in oncology, etc.

To properly match mentors to teams, the following should be in place:

1. Team-driven: teams should be able to search for mentors by keywords via an app (phone/web/whatever). Teams should NOT be expected to read every bio to identify relevance. A simple keyword-based UI should suffice.
2. Sherpa-driven: sherpas should monitor and understand what the teams are doing and what mentors would bring the most value. Good sherpas should know all the mentors available and have a rich network of mentors in their personal network they could invite ad hoc.

Reaching Out: once a mentor is identified, either the team should be able to reach out to them directly or they would request a connection via sherpa (depending on mentor preference).

And that’s it!

Rationale

Hackathons have matured tremendously over the years. What started with gritty and loosely organized events back in the day with the likes of Startup Weekend has grown into events organized and backed by companies and universities. As a former coder, I felt that most hackathons were, frankly, rather lame. Having coded and pitched our hearts out, I couldn’t escape a certain feeling of emptiness afterwards — after pulling near or full all-nighters for a weekend, the experience would rank a solid 3 /10 on average for how satisfying it felt in the end. I never regretted it, but I just always wished that the organizers took hackathons more seriously than just offering a space.

What is the goal of a hackathon?

1. meet interesting people
2. enjoy the process of building/collaborating, and
3. work through an idea and try to build something.

Thus, for a hackathon to be successful, the most important components are:

1. people
2. the process
3. post-hackathon continuity (may be).

In this article, I will focus on the process (2). Especially what role mentors play at a hackathon.

How NOT to do mentorship: the worst thing I’ve seen is mentors, who are not relevant, showing up, interrupting team flow, taking up too much time, and not contributing in a significant way except offering words of encouragement.

What should mentors do? The fundamental role of a mentor is to save time by untapping existing knowledge. Thus not all mentors are relevant all the time and matchmaking becomes extremely important.

Let’s look at phases within a hackathon:

Ideation

Mentors should have deep knowledge of questions related to an industry.

1. Can they confirm then pain/need?
2. Can they confirm the solution?
3. Can they confirm assumptions?

Build

The build has two components. The Product and the Business.

For the Product Build, mentors can:

1. Tools: identify relevant tools
2. Process: troubleshoot the development process

For example: As a coder, one of the most challenging aspects of hackathons was that one missing f*cking semicolon. Or I’ve seen young coders missing that one “div” tag that I could see, but they kept missing. Or I remember how the Jibo team helped me use their API and development interface — something I couldn’t figure out on my own. You get the idea: an experienced mentor can help jump the learning hurdles thus facilitating the build.

For the Business Build, mentors can:

1. Assumptions: confirm / Deny assumptions
2. Domain Knowledge: offer a deep understanding of a market

For example: one thing I did when mentoring at MIT Hacking Medicine is look through all the teams immediately after ideation. Once, there was a team that wanted to produce videos. I happen the have deep knowledge here, being the Founder/CEO of a surgical video journal jomi.com, having been the Co-Founder/CTO of a scientific video journal jove.com. Upon connecting with the team, I was able to quickly share both negative learnings (e.g. user contributions in their markets would be unlikely to work), and positive learnings (e.g. understanding what goes into costs in video production).

Continuity

And then, finally, there is continuity. Once the project is built, mentors can connect the project to:

1. users
2. investors
3. other parties that may want to support it.

Matchmaking

And so we come to the primary recommendation. For a mentorship program to be successful, the mentor infrastructure should have two tiers.

1. Knowledge Mentors: people with deep knowledge are generally going to be very difficult to get a hold of. Moreover, these are the individuals that can become a primary marketing driver for a hackathon — no matter what you are building, getting expert advice is incredibly desirable. Imagine being able to get the right physician to give you feedback on a device as it applies to them, or an engineer to discuss prototyping, or a senior FB/Google/MSFT dev on how to code something up, or someone at a senior pharma company to give feedback on drug development process — you get the idea. Knowledge mentors can be absolutely an amazing resource.
2. Network Mentors (Sherpas): time is a precious commodity for most seasoned entrepreneurs and professionals. They won’t fill out forms. They won’t hang out for half a day at a hackathon (usually), unless we are just chilling. In come the Network Mentors or Sherpas, who can act as an efficient conduit between teams and relevant mentors. They generally should know all the mentors who are in attendance, have a broad network, and, if there is no person available, they should be able to quickly reach the right person and pull them into the hackathon.

Thus, there are two ways of matching mentors with teams.

1. Push: the Sherpas should know what’s going on and recommend mentors and then seek them out. For example, when I saw an idea for a genetic approach to cancer, I found two people in my rolodex who had good knowledge of Foundation Medicine and Flatiron Health and made the introductions.
2. Pull: teams should have an easy way to identify relevant mentors, at which point they should be able to quickly flag the need and get assistance.

And that’s it. This is a simple recipe that requires some investment of time, but can yield tremendous results.