Zwei Perspektiven auf unseren internen Hackathon im Schaltzeit-Team
Wie konzipiert man einen Vibecoding-Hackathon für ein Unternehmen, in dem die eine Hälfte des Teams gute Programmierkenntnisse hat und die andere nicht? Diese Frage hat uns bei Schaltzeit selbst beschäftigt, also haben wir es ausprobiert: einen internen Hackathon, an dem alle Teammitglieder mitbauen, unabhängig von ihrem technischen Hintergrund und Aufgabenbereichen. Was uns überrascht hat: Die unterschiedlichen IT-Vorkenntnissen waren nicht die Hürde, sondern der Motor für Lösungsideen. In diesem Blog berichten zwei Perspektiven aus unserem Team, Lucas (Konzeption, Moderation und Vibecoding-Experte) und Fenja (ohne IT-Background), wie daraus echte Prototypen wurden und was wir daraus allgemein für Hackathon-Konzeptionen mitnehmen.
Warum ein Hackathon – und warum so?
Lucas – Konzept, Moderation & Teilnehmer
Die Idee: Wir nehmen uns als Team einen ganzen Tag, bilden Zweier-Teams und lösen echte, interne Probleme – mit digitalen Mitteln. Kein theoretisches Planspiel, kein externer Use Case. Sondern Herausforderungen, die wir alle kennen: das Dateimanagement, das niemand wirklich durchschaut. Die Content-Planung, die in drei verschiedenen Tools lebt. Das Task-Tracking, das mehr Aufwand erzeugt als es spart.
Wir sind ein Team, das zur Hälfte aus Softwareentwicklung und Webentwicklung kommt – und zur anderen Hälfte aus Zukunftsforschung, Design und Betriebswirtschaft. Wir arbeiten täglich zusammen, aber oft in parallelen Welten. Die einen bauen Tools, die anderen nutzen sie. Oder auch nicht. Dazwischen liegt manchmal ein Übersetzungsproblem, das größer ist, als man denkt. Der Hackathon sollte genau diesen Zwischenraum öffnen – nicht als Teambuilding-Event mit Post-its und Pizza, sondern als gemeinsames Arbeiten an konkreten Lösungen.
Der Fokus lag dabei auf Vibecoding: der Möglichkeit, mithilfe von KI-gestützten Tools auch ohne tiefe Programmierkenntnisse digitale Prototypen zu entwickeln. Wir wollten verstehen, was das in der Praxis verändert. Wir wollten die verschiedenen Zugänge zu KI, die im Team existieren, zusammenbringen. Und wir wollten prototypische Lösungen entwickeln, die wir intern tatsächlich weiterverfolgen können.
Der Ablauf: Zwei Etappen statt eines Sprints
Schon vor dem eigentlichen Hackathon hatten wir in einem Teammeeting interne Probleme und Herausforderungen gesammelt – ein gemeinsamer Problemspeicher, aus dem sich die Teams später bedienen konnten. Den Hackathon selbst haben wir dann in zwei halbe Tage aufgeteilt, mit mehreren Wochen Abstand dazwischen.
Am ersten halben Tag ging es darum, Teams zu bilden, sich ein Problem aus dem Speicher auszuwählen und es wirklich zu durchdringen. Der Prozess zur Lösungsskizze wurde pro Team schriftlich dokumentiert – vom Ist-Zustand über die Anforderungen bis zum Lösungsansatz. Der Tag endete mit einer Kurzvorstellung aller Lösungsskizzen im Team und einer ersten Phase, in der die Teams ihre Ideen initial angehen konnten.
In den Wochen zwischen den beiden Etappen haben die Teams die Möglichkeit, an ihren Prototypen weiterzubauen. Der zweite halbe Tag ist bewusst als Abschluss angelegt: Prototypen fertigstellen, im Team präsentieren und testen. Und vor allem: den Austausch über die genutzten Tools und den Weg zum Prototyp führen – um aus den Erfahrungen mit KI und dem Prozess gemeinsam zu lernen.
Mittendrin statt nur dabei
Ich hatte den Hackathon konzipiert, die Teams zusammengestellt und den Tag moderiert – war aber bewusst auch selbst Teil einer Gruppe. Ein Spagat: Als Moderator achtest du auf Zeitrahmen und Energie im Raum. Als Teilnehmer willst du dich auf dein eigenes Problem einlassen.
Was mich aus dieser Doppelrolle heraus am meisten überrascht hat: Bevor überhaupt eine Zeile Code entstand, haben alle Teams zunächst um das Problemverständnis gerungen. Was genau ist eigentlich das Problem? Was wäre ein guter Zustand? Welche Annahmen stecken in der bisherigen Lösung? Dieses Sichtbarmachen von implizitem Wissen war rückblickend der produktivste Moment des ersten Tages – und die Voraussetzung dafür, dass die KI überhaupt sinnvoll weiterhelfen konnte.
Ob alle Prototypen am Ende weiterverfolgt werden? Das wird sich nach dem zweiten Hackathon-Tag zeigen. Aber der Denkraum, der sich geöffnet hat – über die Frage, wie wir als diverses Team gemeinsam digitale Lösungen entwickeln – der bleibt.
Ich bin keine Entwicklerin. Und trotzdem habe ich mitgebaut.
Fenja – Nicht-IT-Perspektive
Ich bin keine Entwicklerin. Und ich wäre nie auf die Idee gekommen, dass ich am Ende des ersten Hackathon-Tages an einem Prototyp mitgebaut habe – der tatsächlich schon läuft.
Mein Kollege Tim und ich haben uns ein Problem vorgenommen, das viele kennen: wiederkehrende Aufgaben, für die jedes Mal aufs Neue eine Timeline gebaut wird – obwohl das Muster immer dasselbe ist. Bevor wir auch nur angefangen haben zu bauen, haben wir versucht, das Problem so genau wie möglich zu beschreiben: Ist-Zustand, Soll-Zustand, Trigger, Häufigkeit, Rahmenbedingungen.
Das war schon die erste Herausforderung. Wir wissen beide um das Problem und die Möglichkeit zum Optimieren – aber es ist gar nicht so leicht, das Ganze konkret und ohne viel Prosa zu beschreiben. Rückblickend war genau dieses Problemverständnis der Grundstein für die Anwendung, an der wir jetzt immer noch tüfteln.
Denn genau das hat die KI gebraucht, um uns sinnvoll weiterzuführen. Sie hat Lösungsansätze vorgeschlagen, von denen ich allein nicht mal gewusst hätte, dass es sie gibt. Programmiersprachen, die ich nicht spreche. Entscheidungen, die Tim einordnen und treffen konnte – und mir erklärt hat. Gemeinsam haben wir die Anwendung weiterentwickelt: nutzer:innenfreundlicher, mit mehr Logik, mit editierbaren Einstellungen. Und je länger wir daran arbeiten, desto mehr Kleinigkeiten tauchen auf, die wir optimieren wollen. Das UI machen wir ganz am Ende schön.
Was mich überrascht hat: Am Ende des ersten Tages lief ein erster Prototyp. Zwar mit vielen Bugs und Anpassungsbedarf – aber er lief. Ohne dass ich eine Zeile Code geschrieben hätte. Das verändert etwas daran, wie ich über technische Umsetzbarkeit nachdenke – und darüber, was crossfunktionale Zusammenarbeit wirklich bedeutet.
Was einen guten Hackathon ausmacht:
Was uns dieser Tag gezeigt hat: Ein Hackathon lebt nicht nur vom Format, sondern auch von dessen Vorbereitung. Die richtigen Teams, eine gut recherchierte Problemsammlung, der passende Rahmen für KI-gestütztes Arbeiten – das entscheidet, ob am Ende echte Prototypen stehen oder nur ein Post-it-Friedhof.
Genauso entscheidend ist das Setting während des Hackathons: nicht nur, ob die Technik für technische und nicht-technische Teammitglieder zugänglich ist, sondern auch, ob genug Raum für reflektierte Diskussionen im kleinen Kreis bleibt. Denn einige der produktivsten Momente waren bei uns keine technischen. Es waren die Momente, in denen Teams aufgehört haben zu bauen – und angefangen haben zu klären.
Genau das gestalten wir auch gerne für andere Teams. Wir schauen mit euch im Vorfeld genau hin, welche Probleme sich für einen Hackathon anbieten. Wir gestalten dein Format, in dem technische und nicht-technische Perspektiven für die Erarbeitung von Lösungsideen zusammengebracht werden. Wir evaluieren gemeinsam die Ergebnisse. Kurz: Wir konzipieren, moderieren und begleiten Hackathons, die zu euch passen.
Meldet euch gerne!
