Back in 2016, as a medical student, I co-founded med_hack. Our hackathon would be considered very successful - despite quite a few struggles, we managed to have more than 140 participants from both healthcare and tech fields come together for over 2 days to hack!

Our participants seriously loved every moment of it. Some of the feedback that meant the most for us was that unlike other hackathons, our participants felt that this hackathon was made for them.

It’s two years later in 2018 and I’ve been asked for my advice on on what we did. So here it is. I'm publishing this old post here in 2020 too, so talk about recycling!

Inspiration and resources to learn from

We took a lot of guidance from the MIT Guide on Health Hackathons. We also attended local hackathons in Melbourne - both medical and non-medical - to see what they did well.

A summary of what you need to focus on

The fundamentals:

Vision: Develop a clear and articulated vision for how you want the event to run
Sponsors: Partnerships/sponsors should be one of your earliest considerations, due to their assistance being the fuel for your venture.
Venue: Get this concrete as soon as you can, as it can become deceptively hard to find a suitable venue.
Marketing: both offline and online avenues are necessary.
Logistics
– Pre-day
– Includes chasing up the things that you’ve been promised, as well as informing (and later on gently reminding) all the mentors and your partners when they need to be at your event– Make sure all gear that needs to be ordered and purchased is ordered early – On-day – Post-day

Developing the vision

Health tech collaboration rarely happens in the University setting except at events like these and occasionally in research. Healthcare lags behind when it comes to technological change.

Clinicians and healthcare workers focus on optimising exactly what they are asked to optimise for - faster processing of paperwork and patients, as well as safer care. The fortunate consequence of being on on the front line is we can directly feel the impact of systemic problems in healthcare. That may seem worded strangely, but the reason why this is fortunate is that you can’t fix a problem you don’t know about, or know about only in abstract terms.

But there are two obvious barriers to healthcare workers in producing technological innovation.

The first is that they may know what the problem is, but don’t know where to start when it comes to solving it. They might have a rough idea of what a solution looks like from a technological, but to do that they’d have to either 1) learn how to code or build themselves, or 2) hire someone for a large sum of money.

The second is that the language of someone in healthcare tends to be far removed from the language of someone in any form of engineering, software or otherwise. Yet, there is clearly an immense amount of knowledge to communicate across to them.

People from tech (front-end, back-end, UX, software, hardware…the list goes on) have a different problem. Instead of not knowing how to code or build, their problem is that they don’t know what to build in the first place. A smart layman’s understanding of healthcare may involve a lot of well-intentioned Googling but come to a conclusion for a product that does not actually answer a real problem. Sometimes people make products out of personal experiences with healthcare, which is a step better. But being able to pick the brains of somebody who understands the complex field of health first-hand will usually be the best way to make a product that actually matters.

Having an event that specifically invites both health and tech parties to join greatly appeals to both. It’s a win-win-win situation - for healthcare workers, technologists, and patients/the general population.

Mentors

These mentors will provide invaluable education to your participants, turning your event from a motley crew into something extremely educational. We networked hardcore to find people who would be good fits for this. You need both tech and healthcare mentors.

We made a mentor pack and sent it out to whoever we asked, because it provides clarity in communication.

Venue

Getting a place that will happily house your big group of people is especially tricky. There’s special considerations for a hackathon. Where will people sit? Are there enough powerpoints? Where will you do presentations? Where do you put food? Is there good wifi? How will people park at your venue? Again, we had a tech education specific venue which totally saved us, since they’d already heavily considered these requirements.

My one piece of advice is, get this confirmed EARLY. It’s not as easy as you think it is to secure a venue, or at least it wasn’t for us. It was one of those critical make-it-or-break-it factors.

These are considerations we had:

Food organisation
– Food placement
– “We usually do this by setting up a few large tables right where participants come in to create a reception desk, and some more tables with water, coffee, and snacks right outside the main hacking room to create food stations.”– Big meals – In-between meals– Drinks– Music – Quiet spaces for participants – Cleaning
– Bathrooms – Messy food hack tables
Equipment supplies and setup
– AV needs
– Photography – Microphones – Speakers – Projects – Display adapters for presentations – Power strips for each table x – Lighting– Wifi– Hardware
Room setup
– Registration table/workflow – Team seating – Stage/presentation area– Pitch practice area – Restrooms/Water fountains – Handicap accessibility
Prototyping tools
– Paper pens etc.
Mentor meetings
– Who's gonna meet the mentors on the day when they come in to guide them?

Team

Get the team size right. Too few means a ton of work but lots of flexibility and quick decisions, too many means a good spread of work but can easily divulge into people not feeling invested in making it good. Our core team of 6-7 planners was adequate, with an additional 7 or so people to help us on the day. Tech is sexy and you’ll find many motivated people wanting to volunteer for this.

In terms of who does what, I’d follow the MIT guide roughly. In essence, what we did:

One or two people to lead the project direction
One person to take care of financial matters like budget/treasury
One person to focus on marketing (though in the end this becomes a group effort anyway). In general, graphic design is really important for both pre-event marketing and on-the-day overall feeling, so it’s a plus if this person knows how to use Sketch or Illustrator etc. Bonus if they can code a website (if not, any of Webflow, Wix, or SquareSpace will do).
Two or three people that span different roles. This is flexible, but you’ll inevitably find stuff for them to do.

Marketing

All parts are hard, though marketing is one of the trickiest because it’s not always clear what to do. Chances are that you and your team are people that love healthcare tech, and people that attend are just like you — so pitch to them as you would to yourself, and reach out to them in exactly the same avenues that you might like to find this event yourself.

I discussed this with Khoa Cao (co-founder) and one of the critical aspects that you need to get right is that you must be aware of the different audiences that you are marketing towards. We articulated a marketing strategy to get people from every industry — health, tech, design, business, and even patients.

Website

For an example of a website, here’s what we did for med_hack. Our awesome designer Cheng Chua has actually made a document where you can see the design process and thoughts behind our designs, as well as some of the information that we gave to other people. You can view that here.

Make sure to include an FAQ!

How to communicate to your audience

This is something I learnt much later on (and actually in the context of Facebook marketing), but really potential hackathon participants are just like customers. You can use the UPSYD mnemonic: some are Unaware (don’t know health tech collaboration is a thing), some are Problem Aware (want to get into healthtech but don’t know how), some are Solution Aware (know about hackathons), some are Your Solution Aware (know about your hackathon), and some are Deal (they want to buy a ticket to your hackathon and need a small nudge.

Typically the majority of your participants are Problem Aware if they come from a medical background, and Solution Aware if they come from an engineering or tech background. You MUST be hyper aware of this and cater your marketing communication accordingly.

Medium of marketing

Direct worked best for us. We tried fancy stuff like Facebook ads, but in the end, by far the most effective means of getting participants was:

Asking sponsors to send a promotional email on behalf of us - free
Pitching it to University lecture theatres in front of halls of students - free
Directly inviting our friends to join - free

Now, we honestly leveraged our status are University students to the core. The problem you’ll find is not in reaching out to your own people, but to the people in other industries. You need at least one person from tech and one person from healthcare in your team.

Marketing timing

From our discussions with other people who ran successful hackathons: “1-1.5 months before event, start ramping up the marketing hard. Then 2 weeks before, pump and market like crazy. Start with getting your event in newsletters in one month out, calendars, digital screens. Then getting posters in your local university up. 2 weeks out, start “handholding' and directly reaching out to specific professors/students etc. to say ‘we really want you to bring some people in.’”

Give tickets away.

We thought it would be nice to be more inclusive of different groups of people, so we gave away a few tickets to e.g. high school students.

Logistics

In no particular order.

Stuff to buy

Expect to spend

Food.
Paper. Pens.
Promotional materials.
You should get gifts for mentors. Wine bottles are appropriate. Cards should also be given.
Lanyards.
ID card holders.
T-shirts.
Food. We thought about cooking our own stuff, but no, don’t do it. There’s regulations and stuff that you shouldn’t emphasise stress on, because you’ll have so much going on already. Get a professional catering service involve.

Analysis

How will you know how good your event is? We did pre-event and post-event surveys.

Paperwork

Protect yourself legally and logistically. Also tell people where the toilet is, because trust me, you’ll get asked this a lot.

Important forms

Intellectual Property. Get your participants to sign something that you both agree upon when it comes to intellectual property. As an example: All projects, code, and prototypes created at medhack remain the intellectual property of the group that created them. Use of 3rd party source code, APIs, or devices require appropriate attribution to their respective authors.
Code of Conduct. Assume most people are good, but also be prepared for bad eggs.
Diet preparation. Anaphylaxis is a no-no for most hackathons.
Medical emergency details. Participants dying is also kind of a bummer.
Media release. By signing this document, you hereby give the organisers and volunteers of med_hack permission to take photography/videography of the event which may necessarily include you in the recorded media.

Filmography/Photography

Consider how to make this awesome. I’d recommend having someone dedicated to photography for the day. These days you can easily get away with high-end smartphones as legit cameras, though if someone has a DSLR camera, then go for it by all means.

How do participants identify non-participants?

Think about how your participants will identify group organisers to ask them about things. This may be by lanyard, special T-shirt, or otherwise.

The Day

The actual day is here! Make sure to have a contingency plan for if things go wrong.

This is an example of what our timetable looked like. In terms of how well things went, it was a bit of a rush!

What we essentially included was:

Introductory speeches
Keynote speeches
Masterclasses
Time for groups to get together
Pitching time

Here is an abbreviated rundown of important things to happen.

Getting everyone set up

Make sure there is suitable parking somewhere for people to arrive at.

Prepare a suitable amount of time and tables for people to sign forms and get ready for the hackathon.

Introductory speeches

Before I gave an informational speech, we had an MC hype everyone up for the great day. This really kickstarted the day’s atmosphere.

I included:

Introduction (1 minute)
Overall structure of the two days
Team formation
What Hacking Involves (+Tips)
What Pitching Involves (+Tips)
Prizes
Conclusion (smoothly transition into masterclasses)

In my introductory speech, I included a breakdown of the different types of participants that came to the event. This actually was that so people could know who they might be able to bump into, as well as making people feel that they are warmly invited and included in the event from the get-go, being the person that we wanted to be there.

Encourage people to get to know each other and talk about some of their potential ideas for the hackathon! This way, when it comes to actual team formation time, there will be more prepared people.

Keynote speeches

We had two fantastic keynote speakers talk about healthcare innovation. Likewise, you should aim to set the tone of your event accordingly.

Masterclasses

For inspiration, we had some great health tech masterclasses too. These were interesting lectures for people to start to mingle with each other and have things to discuss.

Team formation

After the speeches and masterclasses and perhaps a short break, people should now be asked to gather - so that they can start to form teams with each other. Dedicate a specific block of time for team formation, and have yourself and your volunteers help people find teams.

Hack!

Whilst people are hacking, you should have mentors around to give advice to different teams. Not only will they give great advice, but the participants of the hackathons can make great contacts, and the mentors too will be able to meet interesting participants.

Regularly check in to see how teams are going and how you can help them.

For submissions

We used DevPost and encouraged teams to submit both their teams and projects there, with a hard and specific deadline time.

Pitches

Make sure your AV equipment is all ready to go well before you need it! This includes making sure that the participants’ presentation set-up is working with your AV.

Introduce your judges.

Emphasise how pitches will work - such as how your participants will know if they’re running to time, and how you might politely tell them to get off stage if they run overtime (e.g. using an Oscar style type of thing where you start to gently play music if they run for too long).

You should give a small intro about each pitch as they come on, but nothing really but a name. Let your pitchers be the stars of the show.

After the pitch, your judges should be allowed to ask some questions and maybe give feedback - right after the pitch. This provides an invaluable learning experience for participants.

Post-pitches

After all pitches, your judges need some time to deliberate. Prepare a quick presentation once you’ve finalised the results, and then make a speech announcing the winners.

What volunteers did

Volunteer tasks
– Photography / Videography– Registration– Timing for pitches – Food/drink serving– Logistics
Things that our volunteers helped with
– Photographer – Helping us intro people to people who need teams, at the team formation stage– Helping answering questions that people will ask (we'll try our best to anticipate the common ones) – Cleaning up/shifting various things as needed – Food/drink serving

For us, we felt it was especially important to emphasise how important volunteers were to making our event run.

Post-hackathon

The main thing is to:

1) Collect feedback and debrief

2) Make sure everyone gets their prizes!

In terms of the level of support we provided: from our experience, be wary that teams are often made up of some proportion students who aren’t particularly interested in dropping out of University to go work on some brilliant startup. We tried to hold a post-hackathon pitch to stakeholders 6 months after, but at that time none of our teams were ready / had disbanded.

What we could have done better

This was direct feedback from our participants about what we could have done better. We did exceptionally well, especially for a first time event.

Our participants thought that the hackathon was quite short. We had to cut down to 2 days due to budgetary constraints, so some people wanted longer. This was a common feedback, so where you can, go for three days. I discussed this with Khoa Cao (my fellow co-founder) and he mentioned something really interesting, which was that some hackathons have successfully run their hackathons over weeks (Melbourne Datathon 2018) and as a result teams have their own time to be able to create real projects that have more tangibility — so consider if this setup is suitable for what you want to accomplish.
Our food was okay, being composed of healthy salads and such to fit the theme, but participants actually wanted hot food.
The space we got was a little too small. We really did cram people in because we had so many participants. We had multiple instances of feedback of this.
On the day, we failed with some of our microphone and video stuff. We didn’t properly test through our audiovisuals before the day, and we ran into a bunch of problems especially when our participants had to pitch. Our microphones had done that squeaky feedback thing and sometimes the video wouldn’t work. In addition, everyone has different computers - prepare for this scenario when people are doing their presentations.
The timing of the day had unfortunately made it difficult for many professionals to participate, being during the weekdays. Try to run your hackathon on a weekend.
We were told that “members without an idea should be given more information about the hackathon before signing up to it”. This is a common occurrence at hackathons, where participants can sink a full 40-70% of their time just thinking of which idea to land on. You’ve got to proactively try to help participants with this.

Conclusion

This was our first hackathon, yet we received a lot of praise from our venue and from our participants about how smoothly it went. There’s inevitably more nitty gritty details that I haven’t covered in this guide, but I do hope that this can give you some guidance as to what you might include in your own medical hackathons!

Special thanks

Special thanks for Khoa Cao, my co-founder for med_hack, for taking a second look at this guide and contributing some really interesting points to it!

How to Run A Medical Hackathon