How to Mentor at Hackathons

When I first started building a career in tech, I used hackathons to build a profile that I then parlayed into a role in developer evangelism. For a period of three years I was a ‘prolific’ hackathon participant, competing in 3–4 each year, and won many placings. These days I like to contribute to hackathons in less intense ways than competing. I mentor frequently and occasionally make appearances on judging panels. From time to time I get back on the tools and compete for fun. As someone who is an experienced hackathon participant, mentor and judge, I have insight and perspective on the role and value of hackathon mentors.

Hackathon mentors are often volunteers from corporate sponsors, and haven’t necessarily competed themselves. They are often unsure of the role they play and how to add value. A good hackathon mentor doesn’t need to have been a hackathon competitor or even a technologist to be a value add at a hackathon. As long as you understand what it is you bring to the table and how to communicate that effectively. The role of mentor can be interpreted in a few different ways, depending on the style and goal of the hackathon. I’ve made a few observations about what works and what doesn’t, which I’d like to share.

The first thing to be aware of is that each hackathon is different in terms of purpose, theme and format, and there are many different kinds of mentors. Maximising your impact as a mentor really depends on the kind of hackathon it is, but also, what kinds of skills you bring to the table. You may be one or more of the following kinds of mentors (or a generalist). When you understand which “hat” you’re wearing it will help you to add value.

The business/corporate mentor has an undervalued role in a hackathon and teams typically don’t understand how valuable this mentor is until the opportunity to leverage them has long since passed. This type of mentor has a dual purpose; 1. Be the outside voice that can help teams maximise the validity of their solution, 2. maximise the value of the hackathon in general for the sponsors and other supporters.

This type of mentor is often the thorn in the side of the purist hackathoners. There’s a subtype of hackathoner who attends these events because they want to challenge themselves to create technically amazing hacks. However, your advice can be essential to helping teams create viability. A good business mentor will be able to prompt highly technical hackathoners to think more deeply about the application of what they’re creating. Gently prompting them to think about this will help them create something that’s actually going to be attractive to the judges and other stakeholders.

The corollary of this is that it will help you maximise the value of the hackathon for your employer. The value generated in this context is in the form of how viable the solutions are that teams build using the sponsor’s toolset, or that expand potential use of the sponsor’s product. Work closely with the coding mentors or any developer evangelists sent by your company to help teams create solutions that a) use any dev products you might be spruiking but b) use them in ways that are viable and generate value.

An important part of being this kind of mentor is that the time frame for usefulness is really day 1. By day 2, the teams are deep into execution mode. Having the conversation on day 2 about why their hack isn’t really viable is just going to stress them all out. Very rarely will they actually be in a position to pivot in any real way, without hating you or each other. I’ve seen a team manage to pull a pivot off on day 2, but it’s extremely rare. The ability to execute this will be down to how well the team works together and isn’t something a mentor can make any easier.

Questions to ask:

Who will pay for it?

Who are your competitors?

Can you think about your competition in a different way? What aspects do these competitors share in common with you that these ones don’t, and vice versa?

How are you differentiating yourself?

My main piece of advice on pitch mentoring is that regardless of the usefulness, some teams will unfortunately not be in a position to do pitch presentation when scheduled. Try to have the pitch mentors set up in a room and let people come by and see them rather than scheduling time slots. Not everyone will be in a position to actually do pitch prep with a mentor by their allotted time. Forcing them to do the pitch prep when they’re madly trying to fix code, and haven’t even thought about slides, will be a waste of their time and yours. Additionally, not everyone will want to do pitch prep with a mentor — for some, the extra time to get their slides together will be more valuable than a run through. This seems like a mistake but bear in mind that hackathons are less than 48 hours. More often than not the team only just fixed that completely fatal bug two hours before final pitches.

In the vast majority of cases, the best thing you can help teams with is telling them what to cut, or more accurately, what they can ‘edit’ out. Most teams will come with far more slides than they can effectively communicate within the time frame they are given for pitching. As a function of the fact that hackathons typically have many teams, pitching time will usually be super tight. Having a neutral ear to tell them what they can leave out of a deck without losing the essence of it will be super useful to most teams. Most teams will think of this as ‘cutting’ stuff but encourage them to think of it as editing out the stuff that is obvious or doesn’t contribute to getting across the things they’re being marked on. For this reason, some slides can be left in, shown briefly and not expounded on. Additional useful advice from pitch mentors is parts of the pitch that can be clearer or more succinct.

Please be mindful of the fact that there is very little that they can change about their product on day 2 immediately before pitching. Your job as a pitch mentor is to help them clearly express what it is they’ve built. Resist the temptation to critique their idea in its entirety, or to launch into working on product market fit validation with them. Critiquing the viability of the hack is the judges’ job. Commenting in a way that tells them that you think they need to pivot the idea is absolutely the most stressful thing you could do.

Definitely do not try to talk pitch until day 2. This seems like it would go without saying, but I have seen mentors who wear multiple hats or are confused about their role, get scheduled on both days and try to be all the things. If you’re trying to talk about the business concept and market proposition on day 1, be sure to keep your business mentor hat on.

Questions to ask:

If you could cut any slide from this yourself, which would it be?

Is this part of the pitch better served with a demo?

How can you make your transition between demo and pitch smoother? Pre-record pitch in case the tech stops working?

I once went to a hackathon where the organisers were very aggressive about each team having mentor time whether or not they needed it. They kept asking us what kind of mentoring our team needed, and what we needed help in, (at the very beginning before we’d had a chance to even figure out what we were doing). Exasperated, I answered that we needed help with the design because we didn’t have a designer on the team. At that point, they allocated one of the random design experts to us, who came over and started chatting. It became obvious that we didn’t really have anything designed yet and we were kind of just figuring out what to do, so he just started talking to us about working as a designer, projects he’d worked on, etc. In hindsight the role of a design expert mentor in a hackathon context is extremely vague — how do you even ‘advise’ on something when the team are not even building the MVP yet?

The way you can add value will depend on what day it is, and what stage of development they’re at. If it’s day 1, It’s highly likely that the team you’re advising won’t have a designer on it. UX/UI designers are as rare as hen’s teeth in hackathon world and when they rock up to hackathon team formation night they get snapped up very quickly. The best value you can contribute to teams is advice about tools and platforms that will help them to function and execute in the absence of a designer. This may again, seem counterintuitive, but what I’m talking about here are frameworks and tools. Be able to advise on tools, templates and other things that will make their life easier.

It is possible that the team gets to the point where they are doing wireframes. If this happens, swing back around as your knowledge of UX/UI principals may become useful and they may have questions for you. However, in the vast majority of hackathons I’ve been to the focus ends up being execution. The devs will divvy up front-end and back-end and work things out as they go. This seems insane if you’ve worked in any kind of dev team professionally. However, typically teams with less than 48 hours to build an MVP will deem anything more than the most basic of wireframes as an unnecessary time suck.

A third scenario, which is increasingly more likely is that the team doesn’t actually have any devs on it at all. While this would seem crazy, this does happen at things like Startup Weekends and policy hacks and so on. In this scenario, the design mentor is the most useful of all. All your knowledge about prototyping tools, design platforms, mockup tools and such, will be hugely valuable to teams who have to create some kind of semi-functional MVP to demonstrate their idea and how it would work. Nothing pisses off the hackathon purist devs more than when a team who didn’t write a single line of code is able to so effectively demonstrate a concept that they win a place. On the other hand, nothing brings that team and the design mentor more satisfaction.

Questions to ask:

What kind of MVP are you looking to build? What is the technical experience of the team?

Do you envisage this as a web product or a mobile product?

The main value you can contribute to teams is on day 1 when they’re trying to figure out how to actually execute their hack. To be a good coding mentor you should be able to hear a quick pitch of what their hack is, and then be able to advise on a list of tools (APIs/ Paas/Baas etc.) that will help the teams execute as much as possible in the shortest time.

The other main thing of value that a coding mentor should be able to contribute is to be able to help them prioritise features. An experienced hackathoner knows that not everything can be executed but somethings are easier to execute in a short amount of time, and some are more impressive for the judges. The hardest job for the coding team members on day 1 is figuring out this trade-off. As an experienced hackathoner you will be able to add some insight on this and help guide them in the right direction.

An essential characteristic for a coding mentor, more so than for any other kind of mentor, is hackathon experience. A coding mentor isn’t necessarily the most experienced senior software engineer, but you definitely need to have done a few hackathons yourself to be valuable to teams operating in that kind of situation. This is because hackathons are not about delivering the cleanest, most polished code. They’re about delivering something that demonstrates a product really quickly. A hackathoner knows not to reinvent the wheel, and where to find the quickest, dirtiest shortcuts to a functional hack.

Questions you can ask:

Have you thought about how you can abstract away parts of this solution using third party services?

Do you need to make this part from scratch or can we make it easier for you?

You may also be a combination of any of the above, a generalist, or someone secretly on the judging panel. The same general advice applies and you’ll need to ‘code-switch’ depending on what hat you’re wearing. The main point to remember with all of these different types of mentoring relationships is that you may not actually be useful. Like any good relationship, don’t force it. You might have been sent by your employer, a corporate sponsor, with aggressive engagement targets, pursuing this blindly may ultimately end up burning good-will. The aim of any mentor at a hackathon should be to create net positives for you, for the participants, and for any other stakeholders such as your employer or the hackathon organiser.

Related posts:

Looking for some proven B2B demand generation strategies to boost your business? We’ve got you covered! The most important goal of demand generation is to create interest in a product or service…

Mengenal Tentang Permainan Slot Gacor Ini — Apakah anda tertarik dan penasaran ingin mencoba memainkan game slot online yang saat ini sangat ramai dimainkan dan difavoritkan oleh para pemain. Tentu…

All music reverberates through New Jersey’s heartbeat. The diversity of this state lends itself to incredible communal creativity and passion. This year Record Store Day (RSD) will be held on…