Is the goal of the hackathon a clickable prototype? A low-level prototype with only wireframes? What business-critical questions they need to have answered? How do they need to present their ideas at the end of the hackathon? With or without slides? Make sure you know where to focus. And focus is often something the teams need the most.

If you somewhat know the topics the teams will be working on and if you’re not an expert on that specific field (for example, you’re a design mentor at a health tech event but work in another industry), take 30 minutes prior to the event to do some research on what companies and startups are doing on the same field. I’ve seen a lot of teams to get stuck in their heads and a mentor getting them unstuck after giving some examples how other companies are handling similar issues. Yes, you could argue that the teams should be doing that job themselves, but they simply don’t, sometimes they just don’t know what and where to look for. That’s when mentor’s comments come in handy.

Often mentors are available for the teams only for a limited amount of time. Even worse, they help at their own schedule and not according to the event or team’s schedule. If you have promised to be there, be present as much as you can so that the teams can ask you questions if needed. If you cannot be there the whole time, tell the teams how they can reach you.

Be around, visible and approachable, but don’t disturb the teams by being with them too much. They’re getting a lot of different advice from different mentors anyway so they need time to digest, make decisions on their own and just work. Tell them when you will be stopping by to see how they’re doing and if they say they don’t need help, leave them be.

Even when you’re really skilled at what you do and a really good mentor, you only have a certain framework how you see the world. But your most important skill when mentoring is asking smart questions. Avoid giving very strict answers at all times, help them to come up with answers on their own.

One of the most crucial aspects mentors sometimes don’t get is that the hackathon is not about them and getting their ideas come to life, it’s about helping the team through the maze. It takes the ability and willingness to put your ego in the background and think what’s best for the team, how they can learn the most. For example, I’m a business mentor and the teams often ask me “what kind of revenue model should we use”. I give them a couple of hints but usually direct them to a resource where they can find revenue model examples and pick their own favorite. That’s the only way they can make a conscious decision and not just rely on what the mentor has been saying. Different mentors give them different advice anyway.

If they’re halfway through and you think they should change a critical part of their idea or prototype, hold yourself back and don’t do it, they won’t have time. Instead, help them to make the most of what they have been working on so far.

Often teams expect mentors to give them ready-made answers because “you’re the expert, tell us what to do”. It’s good to tell your rules for mentoring the very first time you meet the team. Specifically tell them to be critical of mentor’s advice and to make their own decisions about their team, their product, and their business. We all know that the best way to learn is to experience firsthand what implications different decisions have. Don’t rob them of that opportunity.

Encourage the teams, acknowledge their passion, don’t kill their ideas, however, crazy they may sound. When they’re low on energy or otherwise stuck, try to get their spirits back up. Celebrate successes, big and small, with them.