How to Set Up Mentorship at Hackathons

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.
  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.


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.

  1. meet interesting people
  2. enjoy the process of building/collaborating, and
  3. work through an idea and try to build something.
  1. people
  2. the process
  3. post-hackathon continuity (may be).


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?


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

  1. Tools: identify relevant tools
  2. Process: troubleshoot the development process
  1. Assumptions: confirm / Deny assumptions
  2. Domain Knowledge: offer a deep understanding of a market


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.


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.
  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.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store