Jede Start-up-Teamstruktur, die wir ausprobiert haben (und warum sie alle gescheitert sind)
Es gibt keine perfekte Teamstruktur, nur verschiedene Arten festzustecken.
Letzten Monat fragte uns ein Gründer: „Wie sollen wir unser Engineering-Team organisieren?“
Wir haben gelacht. Die Frage ist gut, aber wir haben Teams jede mögliche Antwort ausprobieren sehen, und irgendwann scheitern sie alle.
Wir sind bei Norveon 14 Leute. Alle Generalisten. Funktioniert für uns. Aber wir haben mit einem Kunden gearbeitet, der in zwei Jahren von 8 auf 32 Entwickler gewachsen ist. Wir durften jede Umstrukturierung miterleben. So lief es tatsächlich.
Aufteilung nach Tech-Stack
Bei etwa 10 Leuten teilen sich die meisten Teams nach Technologie auf. Frontend zum Frontend, Backend zum Backend, Mobile zusammen.
Dieser Kunde hat das im Juni 2023 gemacht. 18 Entwickler insgesamt. React-Web-App, Swift- und Kotlin-Mobile-Apps, Node.js-Backend. Drei Teams.
Hat drei Monate funktioniert.
Warum es gescheitert ist
Jedes Feature brauchte alle drei Teams.
Neuer Onboarding-Flow? Backend baut APIs, Frontend baut Formulare, Mobile aktualisiert die Apps. Drei Teams müssen sich für ein einziges Feature abstimmen.
Frontend beschwerte sich, die APIs seien nicht fertig. Mobile beschwerte sich, die APIs seien fürs Web gebaut. Backend hatte keine Ahnung, warum es die Hälfte dieser Endpunkte überhaupt baute.
Niemand war für irgendeinen Teil des Produkts verantwortlich. Alle fassten alles an, also verstand niemand wirklich, wie irgendetwas funktionierte.
Ab Monat vier bestand jedes Stand-up aus „warten auf Backend“ oder „blockiert durch API-Änderungen“.
Squads (wie bei Spotify)
Nächster Versuch: Organisation nach Produktbereichen.
Squad A: Nutzerverwaltung. Squad B: Kernfunktionen. Squad C: Abrechnung. Jede Squad bekam Frontend-, Backend- und Mobile-Leute.
Fühlte sich deutlich besser an. Die Teams waren für ihren Bereich verantwortlich. Konnten liefern, ohne auf andere zu warten.
Hielt ein Jahr.
Woran die Squads gescheitert sind
Niemand kümmerte sich um technische Themen.
Das React-Router-Upgrade lag acht Monate im Backlog. Die Test-Suite wuchs von 3 Minuten auf 55 Minuten. Wessen Aufgabe war es, das zu beheben? Niemandes.
Der iOS-Entwickler in Squad A hatte niemanden, mit dem er über iOS-Probleme reden konnte. Squad B wählte eine State-Library, Squad C eine andere.
Technische Schulden häuften sich an. Jede Squad wurde an Features gemessen, nicht an Codequalität.
In Monat 11 waren drei Entwickler ausgebrannt.
Chapters kommen dazu
Also kamen Chapters dazu. Alle Frontend-Leute in einem Frontend-Chapter. Alle Backend-Leute im Backend-Chapter.
Die Chapter-Leads drängten auf 20 % Zeit für technische Arbeit. Framework-Updates, Wissensaustausch, Technologieentscheidungen.
Die ersten zwei Monate waren großartig. Updates wurden erledigt. Tech-Talks fanden statt.
Dann begann der Streit.
Das Chapter-Problem
Produktmanager gegen Chapter-Leads. Jeden Sprint.
„Warum aktualisiert Alice Abhängigkeiten, statt Features zu bauen?“
„Warum hat Bob das Sprint-Planning für ein Chapter-Meeting geschwänzt?“
Sie fingen an, Prozentsätze zu erfassen. Alice: 23 % Chapter-Zeit. Bob: 11 %. Alle hassten es.
Die Entwickler wurden in zwei Richtungen gezogen. Der Squad-PM will das Feature bis Freitag. Der Chapter-Lead will Sie im Workshop. Entscheiden Sie sich.
Nach sechs Monaten begannen die ersten zu kündigen.
Plattform-Team
Als Nächstes: ein eigenes Team für technische Arbeit.
Der Backend-Lead wechselte dorthin, dazu zwei Mobile-Entwickler und ein Frontend-Entwickler.
Dadurch waren die Produkt-Squads unterbesetzt. Squad A hatte nur noch einen Backend-Entwickler. Squad B verlor die Hälfte seiner Mobile-Kapazität.
Aber der Streit hörte auf. Das Plattform-Team machte die technische Arbeit. Die Produkt-Squads bauten Features.
Allerdings.
Neue Probleme
Der Backend-Lead hatte nie Zeit, seiner alten Squad zu helfen. Squad A fiel zurück. Ihr einziger Backend-Entwickler ging unter.
Die Mobile-Entwickler wurden ständig zurück in die Produktarbeit gezogen. Kunden beschwerten sich, dass iOS und Android nicht synchron waren.
Der Frontend-Entwickler im Plattform-Team wollte nach drei Monaten kündigen. Libraries aktualisieren macht nicht so viel Spaß wie Features bauen.
Das Schlimmste: Den anderen Entwicklern wurde Codequalität egal. „Das Plattform-Team richtet das schon“ wurde zur Ausrede für unordentlichen Code.
Das Plattform-Team führte mehr Prozesse ein. Das sorgte für böses Blut zwischen den „Architekten“ und den „Leuten, die die echte Arbeit machen“.
Temporäre Projektteams
Plattform-Team aufgelöst. Neuer Plan: temporäre Teams für große Projekte.
Projekt Alpha: React-Upgrade. Drei Frontend-Leute, zwei Monate.
Projekt Beta: APIs für Mobile neu bauen. Zwei Backend, zwei Mobile, zwei Monate.
Projekt Beta brauchte vier Monate statt zwei. Falscher Umfang. Zu spät zum Abbrechen.
Projekt Alpha verlor nach einem Monat jemanden. Ersatz kam dazu. Das Onboarding dauerte drei Wochen. Das Projekt lief sieben Monate statt zwei.
Der Entwickler, der alle sieben Monate dabeiblieb, brannte aus. Kündigte einen Monat nach Abschluss.
Projekt Beta wurde in Monat drei abgebrochen. Zu komplex.
Sechs Monate später mussten sie etwas aus Projekt Alpha ändern. Das Team war weg. Der ursprüngliche Entwickler hatte gekündigt. Niemand wusste, wie es funktionierte.
Staff Engineers
Aktuelle Aufstellung: Zwei Leute wurden zum Staff Engineer befördert. Einer Backend, einer Frontend. Sie sind frei beweglich. Helfen, wo es nötig ist.
Die Chapters kamen zurück. 20-%-Regel. Aber diesmal ohne Erfassung. Nur Vertrauen.
Läuft seit acht Monaten.
Der Backend-Staff-Engineer half Squad A, bis jemand eingestellt war. Der Frontend-Staff-Engineer leitete das React-Update.
Die Staff Engineers veranstalten monatliche „Update-Tage“. Ein paar Leute aus jeder Squad verbringen einen Tag damit, Abhängigkeiten zu aktualisieren und Tests zu ergänzen.
Die Chapters treffen sich alle zwei Wochen. Wissensaustausch. Technologieentscheidungen. Keine Arbeitszuweisungen.
Nicht perfekt. Die Staff Engineers sind auf zu viele Baustellen verteilt. Solche Leute einzustellen ist schwer.
Was wir gelernt haben
Jede Struktur scheitert irgendwann.
Technologie-Teams scheitern am Koordinationsaufwand. Squads scheitern, wenn technische Arbeit ignoriert wird. Chapters erzeugen Konflikte. Plattform-Teams verlieren den Bezug zur Realität. Projektteams reißen Deadlines.
Wir sind bei Norveon 14 Leute. Alle Generalisten. Funktioniert in unserer Größe. Würde bei 50 nicht funktionieren.
Dieser Kunde hat jetzt 32 Entwickler. Im Staff-Engineer-Modell zeigen sich bereits erste Risse.
Wenn Sie das gerade durchmachen
Kopieren Sie nicht Spotify. Kopieren Sie nicht Google. Deren Kontext ist nicht Ihrer.
Reparieren Sie, was jetzt kaputt ist. Nicht, was bei 100 Leuten kaputtgehen könnte.
Wenn Koordination das Problem ist, teilen Sie nicht nach Tech-Stack auf. Wenn sich technische Schulden anhäufen, setzen Sie nicht auf reine Squads. Wenn Leute ausbrennen, lassen Sie das Chapter-Modell vielleicht lieber aus.
Probieren Sie etwas aus. Geben Sie ihm sechs Monate. Achten Sie auf Probleme. Ändern Sie es, wenn es eindeutig nicht mehr funktioniert.
Teamstruktur ist kein Problem, das man einmal löst. Es gibt nur unterschiedliche Kompromisse für unterschiedliche Größen.
Derzeit helfen wir einem anderen Kunden, genau das herauszufinden. Fragen Sie uns in sechs Monaten, ob es funktioniert hat.
