9 Hackathon-Fehler, die Veranstalter immer wieder machen

Die meisten enttäuschenden Hackathons scheitern aus denselben wenigen Gründen – und fast keiner davon liegt in der Veranstaltung selbst. Entschieden wird Wochen vorher: wenn die Challenge formuliert, die Jury ausgewählt und niemand benannt wird, der für das Ergebnis verantwortlich ist. Hier sind die neun Fehler, die uns immer wieder begegnen, und was Sie stattdessen tun sollten.

Die neun Fehler

1. Einen Hackathon veranstalten, weil jemand einen Hackathon will. Die Veranstaltung wird gebucht, bevor irgendjemand gefragt hat, wozu sie dient. Ein Datum, ein Ort und ein Hashtag stehen fest – ein Zweck nicht. Ohne Zweck können Sie keine Challenge formulieren, keine Jury auswählen und nicht festlegen, was ein gutes Ergebnis ist; jede spätere Entscheidung wird zur Vermutung. Stattdessen: Schreiben Sie vor allem anderen einen Satz: „Nach dieser Veranstaltung wollen wir ___ haben, und ___ wird damit weiterarbeiten.“ Wenn Sie nicht beide Lücken füllen können, brauchen Sie vielleicht ein ganz anderes Format. Der Vergleich Hackathon, Design Jam oder Innovation Challenge hilft Ihnen bei der Prüfung.

2. Ein Thema statt einer Challenge. „Smart Cities“, „die Zukunft des Bankings“, „Nachhaltigkeit“. Themen wirken großzügig, weil sie Spielraum lassen – doch die Teams streiten die ersten sechs Stunden darüber, woran sie arbeiten sollen, und bauen dann das, was sie ohnehin schon können. Stattdessen: Geben Sie den Teams ein echtes Problem, das einer echten Person gehört und eine echte Einschränkung hat. Eine gute Challenge benennt, wer betroffen ist, was schiefläuft und was ausgeschlossen ist. Wie das gelingt, zeigen wir in So formulieren Sie ein Challenge Statement, das Menschen lösen wollen. Ein vorab mit dem Challenge Owner erarbeiteter Problembaum ist der schnellste Weg zur richtigen Flughöhe.

3. Niemand ist für das Ergebnis verantwortlich. Dieser Fehler erklärt, warum so viele Gewinnerideen nie umgesetzt werden. Ein Team gewinnt, bekommt eine Trophäe, schüttelt Hände – und am Sonntagmorgen gibt es weder Budgetposten noch Sponsor noch ein nächstes Meeting. Stattdessen: Benennen Sie vor der Veranstaltung die Person, die die Gewinnerarbeit übernimmt, und vereinbaren Sie, was sie damit zu tun bereit ist: einen Pilot, eine 90-tägige Umsetzungsphase, einen finanzierten Test. Schreiben Sie diese Zusage ins Briefing, damit die Teams wissen, worum sie antreten. Wie es danach weitergeht, steht in Was nach dem Hackathon zu tun ist.

4. Bewertungskriterien erst beim Pitch verkünden. Erfahren die Teams die Kriterien erst bei der Abschlusspräsentation, optimieren sie auf das, was der Jury vermutlich gefällt – meist Folien und Hochglanz. Die Jury ist sich dann uneins, weil jedes Mitglied stillschweigend eigene Kriterien anlegt. Stattdessen: Veröffentlichen Sie die Kriterien zusammen mit der Challenge, erklären Sie jedes in einfachen Worten und briefen Sie die Jury am Vortag. Gewichten Sie die Kriterien nach dem Zweck, den Sie bei Fehler 1 festgehalten haben. Unser Beitrag über Bewertungskriterien, die den richtigen Gewinner küren behandelt Bewertungsbögen und Kalibrierung; eine Gewichtete Entscheidungsmatrix ist die einfachste Struktur für den Einstieg.

5. Mentoren, die nur fürs Foto auftauchen. Eine Liste beeindruckender Namen ist noch kein Mentoringprogramm. Führungskräfte, die zwanzig Minuten vorbeischauen, drei widersprüchliche Meinungen abgeben und wieder gehen, schaden mehr, als sie nützen – denn die Teams ändern ihre Richtung, um ihnen zu gefallen. Stattdessen: Gewinnen Sie weniger Mentoren, geben Sie jedem eine klare Rolle (Fachgebiet, Technik, Nutzer, Pitch), planen Sie ihre Zeit in festen Slots und sagen Sie ihnen, dass ihre Aufgabe darin besteht, Fragen zu stellen – nicht die Idee neu zu entwerfen. Mehr dazu in Mentoren beim Hackathon: Wie gutes Mentoring aussieht.

6. Kein Zugang zu den Menschen oder Daten, um die es geht. Die Teams sollen einen Service für Patienten, Bürgerinnen oder Kunden verbessern, die nirgends im Gebäude sind, und zwar mit Beispieldaten, die mit der Realität nichts zu tun haben. Am Ende lösen sie ein imaginäres Problem. Stattdessen: Sorgen Sie dafür, dass am ersten Tag echte Nutzer auf Abruf bereitstehen – schon drei oder vier reichen – und bereiten Sie rechtzeitig einen realistischen, bereinigten Datensatz vor. Wenn rechtliche oder datenschutzrechtliche Prüfungen nötig sind, starten Sie diese in der Woche, in der Sie das Datum festlegen, nicht in der Woche der Veranstaltung.

7. Den besten Pitch statt der besten Arbeit belohnen. Die letzte Stunde ist Theater. Teams mit souveräner Präsentatorin und schickem Deck gewinnen, während ein Team, das seine Idee mit fünf Nutzern getestet und zweimal umgesteuert hat, verliert, weil seine Folien schlicht waren. Stattdessen: Bitten Sie jedes Team, Belege zu zeigen: was es getestet hat, mit wem, was sich dadurch geändert hat. Geben Sie der Jury vor den Pitches Zeit mit dem funktionierenden Prototyp jedes Teams. Begrenzen Sie die Folien. Sie suchen die Idee, die es am meisten wert ist, verfolgt zu werden – nicht den besten Auftritt.

8. Zu kurz zum Bauen, zu lang, um fokussiert zu bleiben. Manche Veranstalter quetschen einen Hackathon in einen Nachmittag, andere ziehen ihn über drei erschöpfende Tage ohne Struktur. Ersteres liefert Skizzen, Letzteres müde Menschen, die spätestens in der zweiten Nacht nicht mehr klar denken. Stattdessen: Richten Sie die Dauer danach aus, was am Ende stehen soll. Ein getestetes Konzept braucht etwa anderthalb Tage reine Arbeitszeit. Ein funktionierender Prototyp mit echten Daten braucht mehr – und Check-in-Punkte, damit die Teams nicht abdriften. Planen Sie die Agenda rückwärts von der Abschlussdemo aus.

9. Keine Dokumentation, wer was geleistet hat. Nach der Veranstaltung bleibt als einzige Spur ein Foto der Gewinner. Teilnehmende, die ernsthaft gearbeitet haben – auch in Teams, die nicht gewonnen haben –, gehen mit nichts nach Hause, auf das sie verweisen können, und die Organisation verliert den Überblick, wen sie wieder einladen oder in den Pilot einbinden sollte. Stattdessen: Halten Sie für jedes Team die Problemrahmung fest, was es getestet und gebaut hat und wer was beigetragen hat. Schicken Sie das an die Teilnehmenden und ihre Führungskräfte. Es ist der günstigste Weg, Menschen Lust auf ein nächstes Mal zu machen.

Do's and Don'ts

Do

• Halten Sie Zweck und die Zusage für die Zeit danach fest, bevor Sie irgendetwas buchen.
• Führen Sie mit dem Organisationsteam ein Pre-Mortem durch: „Es ist drei Monate später, und der Hackathon hat nichts bewirkt. Warum?“
• Veröffentlichen Sie Challenge, Kriterien und Preise gemeinsam.
• Blocken Sie den Kalender der übernehmenden verantwortlichen Person für die Woche nach der Veranstaltung.
• Nutzen Sie für die Logistik eine Rollout-Checkliste, damit die Energie des Organisationsteams in die Challenge fließt, nicht ins Catering.

Don't

• Lassen Sie den Sponsor die Challenge nicht allein schreiben; wer mit dem Problem lebt, sollte sie mitgestalten.
• Laden Sie keine Jurymitglieder ein, die die Challenge nicht gelesen haben.
• Versprechen Sie keine Umsetzung, die Sie nicht finanzieren können.
• Messen Sie den Erfolg nicht an der Zahl der Teilnehmenden.

Illustratives Beispiel

Illustrativ. Ein regionaler Verkehrsverbund in einer mittelgroßen europäischen Stadt veranstaltete seinen ersten Hackathon zum Thema „bessere Mobilität“. Achtzig Menschen kamen, zwölf Teams pitchten, und das Gewinnerteam baute eine Routenplaner-App, die drei bereits verfügbaren sehr ähnlich war. Niemand wurde beauftragt, sie weiterzuführen.

Bei der zweiten Veranstaltung gingen die Organisatoren anders vor. Zuerst schrieben sie den Zweck auf: einen Weg finden, die Zahl der Fahrgäste zu senken, die nachts stranden, wenn sie den letzten Anschluss verpassen – mit der Zusage des Betriebsleiters, die Lösung auf zwei Linien zu pilotieren. Sie erarbeiteten mit Fahrern und Leitstellenpersonal einen Problembaum und formulierten die Challenge dann als Wie-könnten-wir-Frage mit klar benannten Einschränkungen: keine neuen Fahrzeuge, keine neue App. Die Kriterien wurden mit dem Briefing veröffentlicht. Drei Nachtschichtfahrer standen am ersten Tag auf Abruf bereit. Das Siegerkonzept – eine einfache Halte-und-Benachrichtigen-Regel zwischen Fahrern und Leitstelle – ging im Folgemonat in einen Pilot, mit dem Betriebsleiter als Verantwortlichem.

Die zweite Veranstaltung war kleiner. Sie war aber auch die erste, die etwas verändert hat.

Häufige Fragen

Was ist der häufigste Grund, warum Hackathons scheitern? Niemand ist für das Ergebnis verantwortlich. Ideen ohne jemanden, der bereit ist, sie zu finanzieren oder zu pilotieren, enden mit der Veranstaltung – so gut sie auch sind. Beheben Sie das zuerst, vor allem anderen.

Wie viele Jurymitglieder braucht ein Hackathon? Drei bis fünf reichen in der Regel. Mehr verlangsamt die Beratung und verwässert die Verantwortung. Wichtiger ist, dass mindestens ein Jurymitglied die Person ist, die die Gewinneridee danach verantwortet.

Sollte ein Hackathon eine Challenge haben oder mehrere? Bei internen Veranstaltungen schlagen ein oder zwei gut formulierte Challenges meist fünf vage. Mehrere Challenges sind sinnvoll, wenn jede einen eigenen Owner und eigene Ressourcen hat, um danach zu handeln.

Wie es weitergeht

Beginnen Sie mit der vollständigen Übersicht der Formate in Hackathons, Jams und Challenges: alle Formate erklärt, danach folgt die Schritt-für-Schritt-Anleitung So führen Sie einen Hackathon durch, der echte Ergebnisse liefert. Für die Vorbereitung decken die Guides Problembaum, Wie-könnten-wir-Fragen und Pre-Mortem das meiste ab, was schiefgehen kann, und die Gewichtete Entscheidungsmatrix gibt Ihrer Jury eine faire Struktur.