Hetzner Cloud, einer der führenden Anbieter für Cloud- und Hosting-Services, hat gemeinsam mit uns ein unternehmensweites Projekt- und Wissensmanagement eingeführt — ohne den Remote-Teams ihre Autonomie zu nehmen. Mit unserem Seven Day Sprint Model haben wir ein zweistufiges Projektmanagement entwickelt, das zentrale Steuerung und die Freiheit der einzelnen Teams in Balance hält. Herausgekommen ist ein skalierbares System, das die teamübergreifende Zusammenarbeit verbessert, ohne die Teamkultur von Hetzner Cloud anzutasten.
Das ist Hetzner Cloud
Hetzner Cloud ist einer der führenden Anbieter für Cloud- und Hosting-Services und liefert hoch skalierbare, bezahlbare Cloud-Lösungen. Das Unternehmen ist eine Tochter der Hetzner Online GmbH, die 1997 in Deutschland gegründet wurde, und hat sich auf virtuelle Server (VPS), Storage-Lösungen und Managed Hosting für Unternehmen jeder Größe spezialisiert.
Hetzner Cloud betreibt hochmoderne Rechenzentren in Deutschland, Finnland und den USA und ist zuletzt nach Singapur expandiert, um die Region Asien-Pazifik zu bedienen. Bekannt ist das Unternehmen vor allem für seine leistungsstarke Infrastruktur. Die Services decken alles ab, von der kleinen Anwendung bis zum Enterprise-Deployment — und sind damit eine beliebte Wahl für Entwicklerinnen und Entwickler sowie Unternehmen, die verlässliches Cloud-Hosting suchen.
Zum Zeitpunkt unserer Zusammenarbeit hatte Hetzner Cloud rund 70 Teammitglieder in etwa einem Dutzend interner Teams.
Die Herausforderung
Hetzner Cloud setzt von Anfang an auf Eigenverantwortung und Unabhängigkeit der Engineering-Teams. Jedes Team organisiert seine tägliche Arbeit selbst und wählt den Tech-Stack, den es für am sinnvollsten hält. Dazu arbeitet Hetzner Cloud vollständig remote.
Diese hohe Autonomie heißt: Alle können so arbeiten, wie es für sie am besten passt. Gleichzeitig bringt sie einiges an Herausforderungen mit sich — bei der teamübergreifenden Zusammenarbeit, bei geteilter Verantwortung und bei langfristiger Planung.
Als wir mit der Zusammenarbeit starteten, wollten wir an dieser Teamkultur nichts ändern — sie ist einer der Gründe für den Erfolg von Hetzner Cloud.
Klar war aber auch: Damit Hetzner Cloud weiter wachsen und ein ständig größer werdendes Geflecht aus verbundenen Tools und Services steuern kann, musste die Zusammenarbeit zwischen den Teams besser werden.
Dazu kommt: Hetzner Cloud gehört zu einem großen Konzern. Jede Lösung muss also in die übergeordnete Strategie und in die Anforderungen an Datensicherheit einer großen Organisation passen.
Die zentrale Frage in unserem ersten Projekt als Notion Berater war:
Wie führst Du ein unternehmensweites Projektmanagement ein, ohne den Teams ihre Autonomie zu nehmen?
So haben wir die Notion Beratung aufgesetzt
Hetzner Cloud hatte Notion bereits teilweise eingeführt und einen ersten Systementwurf gebaut, der schon im Einsatz war.
Bei Projekten wie diesem arbeiten wir an einem „lebenden System“ — und dürfen den laufenden Betrieb auf keinen Fall unterbrechen. In solchen Situationen setzen wir in der Regel auf unser Seven Day Sprint Model.
Diese Notion Beratung lief in der Praxis so ab:
- Wöchentliche Sprint-Zyklen: Wir haben wöchentliche 60-Minuten-Calls mit der Projektleitung und den Führungskräften eingeführt, die Änderungen wiederum in ihre Teams getragen haben. In diesen Sessions haben wir vorgeschlagene Änderungen besprochen, uns abgestimmt und 2–3 Prioritäten für den kommenden Sprint festgelegt. Dieses agile Vorgehen hat dafür gesorgt, dass wir immer an den wirkungsvollsten Aufgaben gearbeitet haben.
- Kleine Fokusgruppen: In regelmäßigen kleinen Fokusgruppen mit 2–3 Führungskräften sind wir tiefer in einzelne Workflows eingestiegen. So haben wir ein echtes Gefühl für die unterschiedlichen Arbeitsweisen bekommen und sichergestellt, dass wir die richtige Lösung bauen.
- Wirkung ab Woche eins: Durch die kurzen Sprints konnten wir schon in der ersten Woche spürbare Verbesserungen an den Workflows ausliefern. Das hat lange Anlaufzeiten erspart und die Akzeptanz im Team erhöht.
- Issue-Tracking in Echtzeit: Während des gesamten Projekts lief ein Issue Tracker in Notion. Darüber haben wir Prioritäten koordiniert, und alle im Team konnten unkompliziert Engpässe melden oder Feature-Wünsche eintragen.
- Direkte Kommunikationswege: Wir sind in das Kollaborations-Tool von Hetzner Cloud gegangen, um eine direkte Leitung zum gesamten Team zu haben. So konnten wir Änderungen sofort kommunizieren und Fragen oder Blocker schnell klären.
Unser Seven Day Sprint Model ist auf schnelle Umfelder wie Engineering und SaaS zugeschnitten, in denen jede Minute zählt. Für Teams, die schon ein Notion-System im Einsatz haben, passt es besonders gut — es unterbricht den laufenden Betrieb nicht.
Aus kurzen Sprints, direkter Kommunikation und gezielten Fokusgruppen ist ein teamübergreifendes Projektmanagement entstanden: eines, das die hohe Autonomie der Teams respektiert und trotzdem die Brücken baut, die Hetzner Cloud zum Skalieren braucht.
Was wir umgesetzt haben
Unsere Lösung stand auf drei Elementen:
- Ein zweistufiges Projektmanagement: Planung getrennt von der Umsetzung
- Ein flexibles Notion-Setup für Engineering-Teams
- Eine Balance zwischen „Single Player“- und „Multi Player“-Systemen
Ein zentrales Projektmanagement für Remote-Teams
Im ersten Schritt ging es um die grobe Struktur des Projektmanagement-Systems von Hetzner Cloud.
Statt direkt in den Aufbau zu springen, haben wir uns Zeit genommen und mehrere Modelle geprüft — um das zu finden, das am besten zu dieser besonderen Ausgangslage passt.
Am Ende stand ein zweistufiges Projektmanagement, das Planung & Reporting von der eigentlichen Umsetzung trennt.
In diesem Modell liefen größere Initiativen, Projekte und die verantworteten Services alle über ein unternehmensweites Planungssystem in Notion.
Jedes Element ließ sich weiter in Milestones und Epics herunterbrechen. Epics waren dabei das zentrale Planungselement, um Arbeit zu verteilen und Fortschritt sichtbar zu machen.
Unterhalb der Epics — bei der Aufteilung in einzelne Aufgaben und Tickets — blieb die Unabhängigkeit der Teams erhalten.
Jedes Team konnte diesen Teil seiner Arbeit in dem Tech-Stack und mit dem System organisieren, das es selbst bevorzugte.
Die Führungsebene musste nur sicherstellen, dass die zentralen Planungselemente (Epics) einmal pro Woche den tatsächlichen Fortschritt abbilden.
So hatten andere Teams und das zentrale Projektmanagement alle Informationen, um teamübergreifende Projekte zu planen und zu organisieren — während die tägliche Umsetzung dieser Pläne in den Teams blieb.
Ein Notion-Setup für Engineering-Teams
Jedes Team konnte seinen Arbeitsbereich frei organisieren. Trotzdem wollten wir ein erstklassiges Notion-System als Rückfalloption bereitstellen.
Teams, die zu Notion wechseln wollten, hatten drei Vorteile gegenüber Teams mit einem anderen Tech-Stack:
- Ein fertiges System, das speziell für Engineering-Teams entworfen wurde
- Einfacheres Reporting an die Planungsebene, weil sie „Notion First“ arbeiteten
- Volle Autonomie über die interne Organisation — das System ließ sich jederzeit anpassen
Dafür haben wir ein eigenständiges Action-Template rund um Aufgaben und Sprints entworfen. Jedes Team hatte sein eigenes Datenbank-Backend, das es an seinen Workflow anpassen konnte. Angebunden waren aber alle an dasselbe zentrale Planungssystem.
So konnte jedes Team frei zwischen seinen bestehenden Systemen und Notion wählen.
Single Player vs. Multi Player Systeme
Das System, das wir entwickelt haben, ist einzigartig und auf die Anforderungen von Hetzner Cloud zugeschnitten. Die Philosophie dahinter lässt sich aber leicht auf andere Teams in ähnlichen Situationen übertragen.
Bei Hetzner Cloud waren an dieser Notion Beratung mehr als 10 Teams und Dutzende Mitarbeitende beteiligt. Genauso relevant ist der Ansatz aber für ein Team mit 12 Personen wie für eines mit 120.
Im Kern läuft dieser Ansatz — Planungsebene und Umsetzungsebene zu trennen — auf das Single Player vs. Multi Player System Design hinaus.
Im Team müssen wir uns auf gemeinsame Prinzipien und Arbeitsweisen einigen, auch wenn sie für die einzelne Person nicht der ideale Weg sind. Das ist der Trade-off, der zu Zusammenarbeit dazugehört.
In solchen Fällen priorisieren wir das Multi Player Design.
Aber nicht jeder Bereich der Arbeit muss „Multi Player First“ sein. An anderen Stellen ist es Overkill, auf Zusammenarbeit zu optimieren.
Am deutlichsten zeigt sich das auf der Ebene „Aufgabe vs. Projekt“.
Dein Team muss auf jeden Fall wissen, an welchen größeren Projekten ihr arbeitet und welche Blocker die eigene Arbeit treffen könnten.
Deine tägliche To-do-Liste muss dagegen wahrscheinlich nicht mit allen geteilt werden. Solange jede Person gut genug selbstorganisiert ist, spielt es keine Rolle, ob sie in Notion, in Apple Reminders oder mit Stift & Papier arbeitet.
Wie immer ist das selten schwarz-weiß. Hilfreicher ist es, Single vs. Multi Player Systeme als Skala zu denken. Verschiedene Bereiche Deines Unternehmens liegen an unterschiedlichen Punkten dieser Skala — und Deine Systeme sollten das abbilden.
Und genau hier kommen Notion und die Notion Beratung ins Spiel. Anders als andere Tools erlaubt Dir Notion, sehr bewusst und präzise zu bauen — damit Dein Operating System genau die richtige Balance trifft.
