Mentoren beim Hackathon: Wie gutes Mentoring aussieht

Ein guter Hackathon-Mentor hilft einem Team, klarer über die eigene Idee nachzudenken – mit Fragen, ehrlichem Feedback und hier und da dem Lösen einer Blockade –, ohne die Idee an sich zu reißen. Gutes Mentoring ist gestaltet: eine kleine Gruppe mit klaren Rollen, ein Plan von Check-ins genau an den Stellen, an denen Teams hängen bleiben, und ein kurzes Briefing, was zu tun ist und was nicht. So setzen Sie es auf.

Wofür Mentoren da sind

Mentoren sind dazu da, die Zeit zu verkürzen, in der Teams feststecken. In einer Veranstaltung von 36 oder 48 Stunden kann ein Team sechs Stunden an einer falschen Annahme, einer kaputten Datenverbindung oder einem zu breit gefassten Problem verlieren. Ein guter Mentor erkennt das früh und stellt die Frage, die das Team wieder in Bewegung bringt.

Wofür Mentoren nicht da sind: bewerten, die Lösung entwerfen oder eine Lieblingsidee mitbringen. Die besten Mentoren hinterlassen ein Team, das die Idee stärker als die eigene empfindet, nicht weniger. Das zählt für die Veranstaltung und darüber hinaus: Folgt ein Pilot, muss das Team an das Gebaute glauben – und eine Idee, die ihm ein hochrangiger Besucher in die Hand gedrückt hat, wird es nicht verteidigen.

Es gibt vier nützliche Mentorenrollen. Die meisten Veranstaltungen brauchen mindestens die ersten beiden:

• Fachmentoren kennen das Problem von innen: den Service, die Regulierung, die Geschichte dessen, was schon versucht wurde.
• Nutzermentoren sind selbst Betroffene oder sprechen für sie. In vielen Veranstaltungen sind sie die wertvollsten Menschen im Raum.
• Technische Mentoren helfen bei Daten, Tools, Integration und dem, was sich realistisch bauen lässt.
• Methoden- und Pitch-Mentoren helfen den Teams, Annahmen zu testen, die Geschichte zu strukturieren und auf den Punkt zu kommen.

Sieben Schritte zu einem Mentoringprogramm, das funktioniert

1. Klären Sie, was die Teams brauchen werden – und wann. Gehen Sie Ihre Agenda durch und markieren Sie, wo Teams typischerweise kämpfen: das Problem in den ersten Stunden rahmen, sich für eine Idee entscheiden, der erste Test, die technische Wand spät in der Nacht, die finale Story. Jeder dieser Punkte ist ein Mentoring-Moment. Wählen Sie die Mentorenrollen passend dazu. Geht es in der Challenge um einen öffentlichen Service, ist ein Fachmentor, der die Regeln kennt, mehr wert als zwei zusätzliche Entwickler. Das Challenge Statement (siehe So schreiben Sie ein Challenge Statement, das Menschen lösen wollen) zeigt Ihnen, welches Wissen knapp ist.

2. Gewinnen Sie weniger, aber bessere Mentoren. Etwa ein Mentor pro zwei oder drei Teams je Session reicht in der Regel, wenn die Zeit eingeplant ist. Achten Sie bei der Auswahl auf Zuhören und Geduld, nicht auf Seniorität. Eine Führungskraft kann eine gute Mentorin sein – aber nur, wenn sie zwanzig Minuten mit einem Team sitzen und mehr fragen als erzählen kann. Bitten Sie jede Kandidatin und jeden Kandidaten um eine konkrete zeitliche Zusage, mindestens zwei Blöcke, bevor Sie zusagen. Ein Name auf der Website, der zehn Minuten auftaucht, ist einer der 9 Hackathon-Fehler, die Veranstalter immer wieder machen.

3. Briefen Sie die Mentoren vor der Veranstaltung. Dreißig bis sechzig Minuten, idealerweise am Vortag. Behandeln Sie die Challenge und ihre Einschränkungen, die Bewertungskriterien (damit Mentoren auf das Wesentliche hinlenken, siehe Bewertungskriterien, die den richtigen Gewinner küren), den Zeitplan und die Spielregeln. Die wichtigste Regel ist einfach: Fragen, nicht vorgeben. Geben Sie ihnen ein paar Fragen an die Hand, etwa:

• Für wen genau ist das, und welchen Moment in ihrem Tag verbessern Sie?
• Was ist Ihre riskanteste Annahme? Wie könnten Sie sie heute noch prüfen?
• Was würden Sie streichen, wenn Sie nur die halbe Zeit hätten?
• Was haben Sie in den letzten drei Stunden gelernt, das Ihre Meinung geändert hat?

Diese Fragen führen direkt zu Assumption Mapping und einem schnellen Hypothesentest; Mentoren sollten beides gut genug kennen, um es vorzuschlagen.

4. Planen Sie die Zeit, statt sie dem Zufall zu überlassen. Unstrukturiertes „Die Mentoren sind da, fragt einfach“ scheitert auf zweierlei Weise: Selbstbewusste Teams beschlagnahmen die Mentoren, und stille Teams fragen nie. Arbeiten Sie stattdessen mit festen Runden: zum Beispiel ein 15-minütiger Check-in mit jedem Team nach dem Block zur Problemrahmung, ein zweiter nach dem ersten Test und ein dritter vor dem Pitch. Zwischen den Runden lassen sich Mentoren über eine einfache Warteliste auf Anfrage holen. Lassen Sie die Mentoren rotieren, damit jedes Team mehr als eine Sicht hört, behalten Sie aber einen benannten Hauptmentor als festen Ansprechpartner, damit die Ratschläge nicht in fünf Richtungen ziehen.

5. Geben Sie den Mentoren einen Weg, ihre Beobachtungen zu teilen. Holen Sie die Mentoren nach jeder Runde für zehn Minuten zusammen. Welche Teams stecken fest? Welche sind dabei, etwas zu bauen, das eine Einschränkung verletzt? Welche haben noch mit keinem einzigen Nutzer gesprochen? So kann das Organisationsteam früh handeln – etwa einen Nutzermentor zu dem Team schicken, das einen braucht. Es verhindert auch, dass Mentoren einander wiederholen. Notizen der Mentoren dürfen nie als Bewertung an die Jury gehen; Mentoring und Bewertung müssen getrennt bleiben, sonst sind die Teams den Mentoren gegenüber nicht mehr ehrlich.

6. Schützen Sie die Eigenverantwortung des Teams. Achten Sie auf die üblichen Fehlformen: der Mentor, der die Idee neu entwirft; die Mentorin, die auf ihrer eigenen Technologie besteht; der Mentor, dessen Rang das Team dazu bringt, eine gute Richtung aufzugeben, um ihm zu gefallen. Sagen Sie den Mentoren im Briefing, dass das Team entscheidet. Sagen Sie es auch den Teams: „Mentoren geben Rat. Sie entscheiden, was Sie annehmen.“ Setzt sich ein Mentor immer wieder darüber hinweg, geben Sie ihm unauffällig eine andere Rolle.

7. Schließen Sie den Kreis nach der Veranstaltung. Fragen Sie die Teams mit einem Feedback-Capture-Grid, welches Mentoring geholfen hat und welches nicht. Danken Sie den Mentoren mit etwas Konkretem: dem Team, dem sie geholfen haben, und was sich dadurch verändert hat. Geht eine Gewinneridee in einen Pilot, ist der Mentor mit dem Fachwissen oft die beste Person, um in den ersten Wochen dabeizubleiben. Diese Kontinuität gehört zu dem, was nach dem Hackathon zu tun ist.

Do's and Don'ts für Mentoren

Do

• Beginnen Sie jedes Gespräch mit der Frage, was das Team vorhat und wo es feststeckt.
• Drängen Sie früh auf Kontakt mit echten Nutzern und Daten, möglichst am ersten Tag.
• Schlagen Sie einen schnellen Test vor (einen Papierprototyp, ein Fünf-Minuten-Gespräch) statt einer langen Debatte.
• Sagen Sie ehrlich, wenn etwas eine Einschränkung verletzt, und erklären Sie, warum.
• Hinterlassen Sie jedem Team einen klaren nächsten Schritt.

Don't

• Nehmen Sie nicht den Stift in die Hand. Wer die Lösung zeichnet, entwirft sie.
• Bringen Sie keine eigene Idee mit, um ein Team zu suchen, das sie baut.
• Geben Sie nicht zu allem Rat; wählen Sie das eine, das gerade am wichtigsten ist.
• Widersprechen Sie einem anderen Mentor nicht vor dem Team; sprechen Sie es in der Mentorenrunde an.
• Mentoren Sie kein Team, das Sie auch bewerten.

Illustratives Beispiel

Illustrativ. Ein Trust des National Health Service im Vereinigten Königreich veranstaltete einen zweitägigen Hackathon, um versäumte ambulante Termine zu reduzieren. Bei der ersten Veranstaltung standen zwölf leitende Ärztinnen, Ärzte und Manager als Mentoren auf der Liste. Die meisten schauten einmal kurz vorbei. Drei Teams änderten ihre Richtung, nachdem ein Oberarzt eine Erinnerungs-App vorgeschlagen hatte; zum Pitch hatten vier Teams nahezu identische Erinnerungs-Apps gebaut.

Die nächste Veranstaltung wurde rund um die Momente neu gestaltet, in denen Teams kämpfen. Die Organisatoren gewannen sieben Mentoren: zwei Mitarbeitende der Ambulanzverwaltung, die täglich Termine umlegten, zwei Patienten aus dem Patientenbeirat des Trusts, eine Datenanalystin, einen Arzt und eine Moderatorin für Tests und Pitches. Alle sieben wurden am Vorabend mit einer Seite Fragen und einer Regel gebrieft: Fragen, nicht vorgeben. Jedes Team hatte drei geplante Check-ins und einen Hauptmentor. In der ersten Mentorenrunde meldeten die Mentoren, dass fünf Teams angenommen hatten, Patienten vergäßen ihre Termine; die Verwaltungsmitarbeitenden wussten, dass viele Patienten zu den angebotenen Zeiten schlicht nicht freibekamen. Die Patientenmentoren bestätigten das. Teams, die das mit den Patientenmentoren testeten, bewegten sich weg von Erinnerungen hin zu flexiblem Termintausch. Die Gewinneridee ging in einen kleinen Pilot mit der Leiterin der Ambulanz als Owner, und eine der Verwaltungsmitarbeitenden blieb als Beraterin an Bord.

Häufige Fragen

Was macht ein Hackathon-Mentor? Ein Mentor hilft Teams voranzukommen, indem er Fragen stellt, ehrliches Feedback gibt, Fach- oder Technikwissen teilt und Blockaden löst. Er bewertet nicht und entwirft die Lösung nicht für das Team.

Wie viele Mentoren braucht ein Hackathon? Das hängt von der Zahl der Teams und der Dauer der Veranstaltung ab, aber etwa ein Mentor pro zwei oder drei Teams je Session funktioniert, wenn die Zeit eingeplant ist. Die Mischung der Rollen ist wichtiger als die Gesamtzahl.

Kann ein Mentor auch in der Jury sitzen? Besser nicht. Teams müssen Mentoren gegenüber Zweifel zugeben können, ohne zu fürchten, dass es sie Punkte kostet. Wenn es sich überschneiden muss, stellen Sie sicher, dass niemand ein Team bewertet, das er betreut hat.

Wie es weitergeht

Für das Gesamtdesign der Veranstaltung lesen Sie So führen Sie einen Hackathon durch, der echte Ergebnisse liefert und die Formatübersicht in Hackathons, Jams und Challenges: alle Formate erklärt. Die Guides Assumption Mapping, Hypothesentest und Papierprototyp sind die drei, die jeder Mentor kennen sollte.