Warum die meisten Hackathon-Gewinner nie umgesetzt werden – und was nach dem Hackathon zu tun ist

Die meisten Hackathon-Gewinner werden nie umgesetzt, weil das Event darauf ausgelegt war, zu enden, nicht zu übergeben. Dahinter steht der Glaube, eine starke Idee werde, sobald sie öffentlich gewonnen hat, von selbst einen Sponsor, ein Budget und ein Team finden. Das tut sie selten. Was stattdessen funktioniert: Verantwortliche, Budget und Entscheidungstermin vor dem Event festlegen und dann einen bewussten 90-Tage-Weg vom Prototyp zum Piloten gehen.

Der Glaube, fair formuliert

Der Glaube lautet etwa so: „Wir veranstalten den Hackathon, die beste Idee gewinnt, und die Führung, die sie gesehen hat, wird sie selbstverständlich unterstützen. Gute Ideen verkaufen sich von selbst.“

Das ist kein dummer Glaube. Hackathons erzeugen echte Energie und einige starke Konzepte. Führungskräfte besuchen die Abschlusspräsentationen und sagen oft ermutigende Dinge. Und es gibt bekannte Geschichten von Produkten, die bei Hack-Events begonnen haben. Also gehen Veranstalter verständlicherweise davon aus, dass Sichtbarkeit plus Qualität gleich Übernahme ist.

Warum er in der Praxis scheitert

Am Montag hat sich niemandes Job verändert. Das Siegerteam kehrt zu seinen Alltagsaufgaben zurück. Die Vorgesetzten haben nicht zugestimmt, es freizustellen. Der Prototyp liegt auf einem Laptop. Sichtbarkeit hat Wohlwollen erzeugt, aber keine Zeit – und ohne Zeit bewegt sich nichts.

Applaus ist kein Budget. Wenn eine Führungskraft vor vollem Saal sagt „Das ist hervorragend, lassen Sie uns das weiterverfolgen“, ist das eine soziale Geste, keine Finanzierungsentscheidung. Das Budget für das kommende Jahr wurde vor Monaten festgelegt, und nichts darin trägt den Namen des Gewinners.

Der Prototyp wurde auf Sand gebaut. Um in 48 Stunden fertig zu werden, täuschen Teams Dinge vor: fest einprogrammierte Daten, übersprungene Sicherheit, ein manueller Schritt hinter dem Bildschirm. So baut man einen Prototyp richtig, aber es bedeutet, dass die Lücke zwischen Demo und Produktivbetrieb viel größer ist, als der Saal glaubt. Wenn das IT-Team den Code sieht, lautet die ehrliche Antwort „Das müssten wir neu bauen“, und die Begeisterung versiegt.

Die Jury waren nicht die Verantwortlichen. Viele Jurys werden nach Rang und Sichtbarkeit zusammengestellt. Die Menschen, die die Lösung betreiben müssten, deren Systeme sie berührt und deren Beschäftigte sie nutzen würden, sehen sie dann Wochen später zum ersten Mal – ohne jeden eigenen Anteil daran.

Gewinnen war die Ziellinie. Den Teams wurde gesagt, das Ziel sei zu gewinnen. Sobald sie gewonnen haben, ist die Geschichte zu Ende. Niemand hat ihnen gesagt, dass der Sieg der Beginn eines Tests war.

Nichts davon ist ein Versagen der Idee. Es ist ein Versagen der Gestaltung: Das Event war darauf ausgelegt, eine Zeremonie hervorzubringen, und genau das hat es getan.

Was stattdessen funktioniert

Vor dem Event: die Landung vorbereiten

Die wichtigsten Entscheidungen fallen Wochen, bevor jemand Code schreibt.

1. Verantwortliche und Landezone benennen. Eine Person, die den Gewinner weiterführt, und die Budgetposition oder das Programm, das ihn aufnimmt. Wie Sie einen Hackathon organisieren, der etwas Echtes hervorbringt nennt das die einseitige Vereinbarung.
2. Freistellungszeit im Voraus vereinbaren. Die Vorgesetzten der voraussichtlich Teilnehmenden sagen vor dem Event zu, dass Siegerteams eine festgelegte Zeit bekommen, zum Beispiel einen Tag pro Woche über sechs Wochen.
3. Verantwortliche in die Jury holen. Zur Jury gehören die Person, die die Lösung betreiben wird, und die Person, deren Systeme sie berührt. Nutzen Sie Kriterien, die Übernahmefähigkeit belohnen, nicht nur Ehrgeiz; siehe Bewertungskriterien, die den richtigen Gewinner finden.
4. Ein Pre-Mortem durchführen. Fragen Sie das Organisationsteam: „Es ist sechs Monate später, und nichts aus diesem Hackathon wurde umgesetzt. Warum?“ Ein Pre-Mortem bringt die Probleme mit Zugängen, Budget und Freistellung meist ans Licht, solange noch Zeit ist, sie zu beheben.

Die 90 Tage danach

Behandeln Sie die Zeit nach dem Event als eigenes Projekt.

• Woche 1–2: Übergabe. Die verantwortliche Person trifft jedes ausgewählte Team. Rollen mit einer RACI-Matrix vereinbaren, die Freistellung schriftlich bestätigen und auflisten, was im Prototyp vorgetäuscht wurde.
• Woche 2–4: die riskanten Annahmen benennen. Sortieren Sie mit Assumption Mapping, was der Prototyp über Nutzer, Systeme und Kosten annimmt. Wählen Sie die zwei gefährlichsten aus.
• Woche 4–8: sie testen. Formulieren Sie jede als Hypothesentest mit vorab festgelegter Erfolgsschwelle und führen Sie ihn im kleinen Maßstab mit echten Nutzern oder echten Daten durch.
• Woche 8–12: entscheiden. Mit einer Rollout-Checkliste in den Piloten gehen, anpassen und erneut testen oder stoppen. Alle drei sind gute Ergebnisse, wenn sie bewusst gewählt sind.

Halten Sie Teilnehmende und Sponsoren durchgehend mit einem einfachen Stakeholder-Kommunikationsplan auf dem Laufenden. Schweigen nach einem Hackathon wird – zu Recht – als Aufgabe verstanden und entscheidet mit darüber, ob sich Menschen beim nächsten Mal anmelden.

Das Stoppen salonfähig machen

Manche Gewinner sollten nicht umgesetzt werden. Ein Test in Woche sechs kann zeigen, dass Nutzer es nicht wollen oder die Kosten zu hoch sind. Das ist ein gutes, günstig erkauftes Ergebnis. Sagen Sie das öffentlich, würdigen Sie das Team für das Gelernte und halten Sie es fest. Wird Stoppen als Scheitern behandelt, weichen Verantwortliche der Entscheidung aus, und Projekte dümpeln halb lebendig vor sich hin – schlimmer als jedes der beiden Ergebnisse. Wie Sie ein Projekt gut beenden behandelt das.

Beispiel

Illustrativ. Eine Universitätsklinikgruppe in den Niederlanden veranstaltete einen internen Hackathon zur Reduzierung versäumter ambulanter Termine. Das Siegerteam – zwei Pflegekräfte, eine Terminplanerin und ein Entwickler – baute einen Erinnerungsablauf, mit dem Patienten per einziger Antwort umbuchen konnten. Der Chief Operating Officer lobte es von der Bühne. Drei Monate später war nichts passiert: Der Entwickler war in ein anderes Projekt gewechselt, und niemand verantwortete das System für Patientennachrichten.

Im Jahr darauf änderte die Gruppe die Gestaltung, nicht das Event. Die Leiterin der Ambulanzen wurde als Verantwortliche benannt, bevor die Anmeldung öffnete. Die Vorgesetzten sagten den Gewinnern einen Tag pro Woche über acht Wochen zu. Der Verantwortliche für das Nachrichtensystem saß in der Jury. Nach dem Event führte das Siegerteam eine Retrospektive zum Prototyp durch, bildete seine Annahmen ab und testete die riskanteste – ob ältere Patienten auf eine SMS antworten würden – in einer Ambulanz. Sie taten es, größtenteils. Der Pilot wurde in Woche zwölf auf drei Ambulanzen ausgeweitet.

Häufige Fehler

• Einen Gewinner verkünden, ohne einen nächsten Schritt zu verkünden. Sagen Sie immer, was an welchem Datum passiert.
• Den Preis als die Belohnung behandeln. Für die meisten Teams ist die eigentliche Belohnung, ihre Arbeit genutzt zu sehen. Preisgeld ohne Weg sagt ihnen, dass ihre Arbeit nicht zählte.
• Den Prototyp zum Produkt werden lassen. Bauen Sie sauber neu, sobald das Konzept bewiesen ist; dehnen Sie Hackathon-Code nicht bis in den Produktivbetrieb.
• Die Teams vergessen, die nicht gewonnen haben. Ihre Befunde enthalten oft die beste Evidenz des Events. Halten Sie sie fest.
• Den nächsten Hackathon veranstalten, bevor die Gewinner des letzten eine Entscheidung haben. Das fällt auf. Mehr dazu in 9 Hackathon-Fehler, die Veranstalter immer wieder machen.

Häufige Fragen

Was sollte nach einem Hackathon passieren? Innerhalb von zwei Wochen sollte die benannte verantwortliche Person die ausgewählten Teams treffen, Rollen und Zeit vereinbaren und auflisten, was der Prototyp vorgetäuscht hat. Dann die riskantesten Annahmen in den folgenden zwei Monaten testen und klar entscheiden: pilotieren, anpassen oder stoppen.

Warum scheitern Hackathon-Projekte nach dem Event? Meist, weil niemand sie verantwortet, kein Budget daran hängt und das Team keine Freistellung von seiner regulären Arbeit hat. Die Idee ist selten das Problem; die fehlende Übergabe schon.

Wie hält man den Schwung nach einem Hackathon aufrecht? Buchen Sie das erste Folgetreffen, bevor das Event endet, informieren Sie die Teilnehmenden alle paar Wochen über den Fortschritt und veröffentlichen Sie die Entscheidung zu jedem Gewinner, auch Stopps. Schwung entsteht durch sichtbare Entscheidungen, nicht durch Begeisterung.

Wie es weitergeht

Die Guides, die einen Prototyp über das Event hinaustragen, sind Pre-Mortem, Assumption Mapping, Hypothesentest und Rollout-Checkliste. Für den vollständigen Überblick über die Formate siehe Hackathons, Jams und Challenges: alle Formate erklärt.