Wie Sie einen Hackathon organisieren, der etwas Echtes hervorbringt

Wenn Ihr Hackathon etwas Echtes hervorbringen soll, entscheiden Sie zuerst, was mit den Gewinnern passiert – vor allem anderen: wer sie verantwortet, aus welchem Budget sie schöpfen und wann entschieden wird. Bereiten Sie dann Problem, Daten und Menschen so vor, dass die Teams während des Events bauen statt warten. Das Event selbst ist der leichte Teil; der Großteil der Arbeit liegt in den sechs Wochen davor und den zwölf Wochen danach.

Die folgenden Schritte gehen von einem internen oder Ökosystem-Hackathon mit einem bis drei Tagen aus. Wenn Sie noch zwischen Formaten wählen, beginnen Sie mit Hackathons, Jams und Challenges: alle Formate erklärt.

Bevor Sie beginnen: die einseitige Vereinbarung

Schreiben Sie eine einzige Seite und lassen Sie sie vom verantwortlichen Sponsor freigeben. Sie enthält fünf Zeilen:

• Das Problem in einem Satz, und warum es jetzt wichtig ist.
• Die verantwortliche Person, die den Siegerprototyp weiterführt, namentlich.
• Die Landezone: die Budgetposition, das Team oder das Programm, das den Gewinner aufnimmt.
• Der Entscheidungstermin: wann die verantwortliche Person nach dem Event Weitermachen, Anpassen oder Stoppen sagt.
• Was „echt“ heißt: ein Pilot mit 50 Nutzern, ein Integrationstest, eine Beschaffungsanfrage. Seien Sie konkret.

Können Sie diese Seite nicht ausfüllen, sind Sie nicht bereit für einen Hackathon. Vielleicht für einen Ideathon oder eine Discovery-Phase.

Schritt für Schritt

1. Das Problem sechs Wochen vorher rahmen

Interviewen Sie die Menschen, die mit dem Problem leben: Beschäftigte an der Front, Kunden, die Systemverantwortlichen. Fünf bis acht Stakeholder-Interviews reichen, damit Sie nicht das falsche Problem briefen. Legen Sie Ursachen und Wirkungen mit einem Problembaum dar und schreiben Sie dann zwei bis vier Wie-könnten-wir-Fragen als Challenge-Tracks. Jeder Track sollte eng genug sein, dass ein Fünferteam in 48 Stunden etwas Sinnvolles bauen kann, und breit genug, dass nicht zwei Teams dasselbe bauen. Wie Sie das Briefing selbst schreiben, steht in Wie Sie eine Challenge-Fragestellung schreiben, die Menschen lösen wollen.

2. Zugänge vier Wochen vorher klären

Hier scheitern die meisten Corporate Hackathons still und leise. Teams kommen an und stellen fest, dass sie die API nicht erreichen, die Daten nicht freigegeben sind oder die Sandbox nicht existiert. Listen Sie vier Wochen vorher alles auf, worauf ein Team zugreifen muss, und holen Sie schriftliche Freigaben von IT, Datenschutz und IT-Sicherheit ein. Bereiten Sie eine Sandbox mit realistischen Testdaten vor. Dürfen echte Daten ihr System nicht verlassen, erstellen Sie einen synthetischen Datensatz mit derselben Struktur.

3. Für gemischte Teams rekrutieren

Öffnen Sie die Anmeldung drei bis vier Wochen vorher und fragen Sie nach Fähigkeiten, nicht nach Titeln. Ein gutes Team aus vier bis sechs Personen hat mindestens eine Person, die baut, eine, die das Fachgebiet kennt, und eine, die mit Nutzern spricht. Lassen Sie Raum für Einzelanmeldungen, die Teams zugeteilt werden. Vermeiden Sie, dass ganze Abteilungen als ein Team antreten; Sie verlieren damit den silo-übergreifenden Wert, der das Event rechtfertigt.

4. Jury und Mentoren zwei Wochen vorher briefen

Zur Jury sollten die verantwortliche Person aus Ihrer einseitigen Vereinbarung gehören, jemand mit Budgethoheit und jemand, der die Nutzer vertritt. Vereinbaren Sie die Kriterien vor dem Event mit ihnen und veröffentlichen Sie sie für die Teilnehmenden. Ein sinnvolles Set: Stärke der Evidenz, dass das Problem real ist, Passung zur Landezone, Machbarkeit in bestehenden Systemen und Qualität des Prototyps. Gewichten Sie sie in einer gewichteten Entscheidungsmatrix. Mehr dazu in Bewertungskriterien, die den richtigen Gewinner finden.

Mentoren sind keine Juroren. Geben Sie jedem Mentor einen Track, einen Zeitplan für Check-ins und einen klaren Auftrag: Fragen stellen, Zugänge freiräumen, nicht übernehmen. Siehe Mentoren bei einem Hackathon.

5. Das Event um drei Checkpoints herum führen

Ein 48-Stunden-Plan, der funktioniert:

• Eröffnung (erste zwei Stunden). Der Sponsor erklärt Problem und Landezone persönlich. Dann beantworten die Problemverantwortlichen, nicht die Veranstalter, Fragen. Teams bilden sich und wählen einen Track.
• Checkpoint eins (etwa Stunde sechs). Jedes Team nennt seinen Nutzer, seine Annahme und was es bauen wird. Drängen Sie die Teams, ihre riskantesten Annahmen per Assumption Mapping aufzulisten. Streichen Sie Dubletten früh.
• Checkpoint zwei (etwa Stunde 24). Jedes Team zeigt etwas Funktionierendes, auch wenn es hässlich ist, und berichtet von einem Test mit einem echten Nutzer oder einem echten System. Ein Papierprototyp zählt bei Oberflächen, die noch nicht gebaut sind.
• Checkpoint drei (letzter Vormittag). Feature-Freeze. Der Rest ist Testen, Beheben und die Vorbereitung einer kurzen Demonstration.

Begrenzen Sie Präsentationen auf fünf Minuten plus Fragen und verlangen Sie eine Live-Demo. Folien darüber, was das Produkt tun würde, sind kein Prototyp.

6. Nach Umsetzbarkeit bewerten, nicht nach Applaus

Führen Sie die Bewertung als Challenge Panel durch: Jedes Jurymitglied bewertet vor jeder Diskussion einzeln anhand der veröffentlichten Kriterien, dann vergleicht das Panel die Werte und diskutiert nur die Abweichungen. Verkünden Sie nicht nur den Gewinner, sondern den nächsten Schritt: „Die verantwortliche Person trifft dieses Team am Dienstag, um einen vierwöchigen Piloten zu planen.“ Verkünden Sie einen Preis, aber keinen nächsten Schritt, verstehen alle genau, was das Event war.

7. Innerhalb von zehn Arbeitstagen übergeben

Innerhalb von zehn Arbeitstagen nach dem Event trifft die verantwortliche Person jedes ausgewählte Team, vereinbart mit einer RACI-Matrix, wer was tut, und sichert die Zeit, die das Team braucht, schriftlich bei den jeweiligen Vorgesetzten. Führen Sie die ersten Pilotschritte anhand einer Rollout-Checkliste durch. Am Entscheidungstermin sagt die verantwortliche Person Weitermachen, Anpassen oder Stoppen – und zwar öffentlich. Warum die meisten Hackathon-Gewinner nie umgesetzt werden vertieft diese Phase.

Beispiel

Illustrativ. Ein regionaler Versicherer in Südeuropa wollte die Zeit verkürzen, die zwischen der Meldung eines kleinen Kfz-Schadens und der Auszahlung vergeht. Seine Innovationsleiterin schrieb zuerst die einseitige Vereinbarung: Der Leiter Schaden verantwortete das Ergebnis, das digitale Schadenprogramm würde es aufnehmen, und sechs Wochen nach dem Event würde entschieden.

Vier Wochen vorher baute die IT eine Sandbox mit anonymisierten Schadenakten und einer Kopie des Dokumenten-Upload-Service. Fünferteams mischten Schadenregulierer, Entwickler und eine Callcenter-Mitarbeiterin. Bei Checkpoint zwei hatte ein Team durch Anrufe bei drei kürzlich Geschädigten herausgefunden, dass die Verzögerung nicht in der Prüfung lag, sondern darin, dass Kunden die falschen Fotos schickten. Es baute einen geführten Foto-Ablauf und testete ihn mit Callcenter-Personal, das Kunden spielte. Es gewann durch Evidenz und Passung, nicht durch Politur. Der Leiter Schaden traf das Team am folgenden Dienstag, und ein vierwöchiger Pilot lief in einer Filiale.

Was Sie tun und lassen sollten

Tun

• Die einseitige Vereinbarung freigeben lassen, bevor Sie das Datum ankündigen.
• Die Problemverantwortlichen die Teams briefen lassen, nicht die Veranstalter.
• Die Bewertungskriterien bei der Anmeldung veröffentlichen.
• Die Menschen gut verpflegen und schlafen lassen. Ein ausgeschlafenes Team baut am zweiten Tag besser.
• Festhalten, was jedes Team gelernt hat, auch die Teams, die nicht gewonnen haben; ihre Befunde bewahren den Gewinner oft davor, Fehler zu wiederholen.

Lassen

• Mit dem Veranstaltungsort, dem Branding oder dem Preis beginnen.
• Teams erst am Morgen merken lassen, dass sie nicht auf die Systeme zugreifen können.
• Ein Foliendeck anstelle einer Demonstration zulassen.
• Juroren wählen, die das Projekt nie wieder sehen werden.
• Am Freitag feiern und am Sonntag verstummen. 9 Hackathon-Fehler, die Veranstalter immer wieder machen listet den Rest auf.

Häufige Fragen

Wie lange sollte ein Corporate Hackathon dauern? Zwei Tage sind das praktische Minimum für etwas, das funktioniert; 24 Stunden passen nur für sehr enge Probleme. Länger als drei Tage, und Sie führen einen Sprint durch – das ist in Ordnung, aber planen Sie ihn dann auch als solchen.

Wie viele Leute braucht man, um einen Hackathon durchzuführen? Für 50 bis 80 Teilnehmende planen Sie eine Hauptorganisatorin, eine technische Leitung für Zugänge und Umgebungen, einen Mentor pro Track, eine Jury aus drei bis fünf Personen und jemanden, der sich ausschließlich um die Logistik kümmert. Die technische Leitung ist die Rolle, die am häufigsten fehlt.

Sollten Teilnehmende eines Hackathons bezahlt werden oder freibekommen? Interne Hackathons sollten in der Arbeitszeit stattfinden oder vergütet werden, und die Vorgesetzten sollten vorher zustimmen. Müssen Menschen unbezahlt ein Wochenende opfern, hören Sie nur von denen, die das können – und verlieren sie in der Pilotphase.

Wie es weitergeht

Die Guides, die hier den Großteil der Arbeit leisten, sind Problembaum, Assumption Mapping, gewichtete Entscheidungsmatrix und Rollout-Checkliste. Jeder lässt sich in weniger als einer Stunde mit einem Team durchführen.