# Spotify-Modell: Was von Squads und Tribes übrig blieb

Autor: Marin Niehues, Niehues Consulting · Veröffentlicht: 2024-04-29 · Organisationsdesign
Quelle: https://www.niehuesconsulting.de/blog/spotify-modell-squads-tribes-uebrig-blieb/

Das Spotify-Modell ist die Momentaufnahme einer Organisation aus dem Jahr 2012. Übertragbar sind seine Prinzipien: kleine autonome Teams mit klarem Auftrag, Abstimmung über Ziele statt über Anweisungen und die Pflege von Fachwissen quer zu den Teams. Wer nur die Namen Squad und Tribe einführt, ändert Visitenkarten und Organigramme, während Entscheidungen und Arbeitsfluss gleich bleiben.

Dieser Beitrag ordnet das Modell ein, benennt die Gründe, warum viele Übernahmen im Mittelstand und in Konzernen ins Stocken geraten sind, und gibt Ihnen ein Prüfraster an die Hand, mit dem Sie entscheiden, welche Elemente für Ihre Organisation taugen.

**Das Spotify-Modell beantwortet die Frage, wie ein wachsendes Produktunternehmen autonome Teams koordiniert. Es beantwortet nicht die Frage, wie Ihr Unternehmen mit seinen Produkten und Abhängigkeiten organisiert sein sollte. Diese Antwort müssen Sie aus Ihrer eigenen Lage ableiten.**

## Was ist das Spotify-Modell?

Das Spotify-Modell ist die Beschreibung, wie die Produktentwicklung des Musikdienstes Spotify um das Jahr 2012 organisiert war. Henrik Kniberg und Anders Ivarsson veröffentlichten sie im Oktober 2012 unter dem Titel „Scaling Agile @ Spotify“. Zwei Jahre später folgten die Videos „Spotify Engineering Culture“, in denen das Unternehmen seine Arbeitsweise erläuterte. Beide Quellen verstehen sich ausdrücklich als Bestandsaufnahme eines Unternehmens, das sich laufend verändert, und nicht als Methode, die jemand anderes einführen soll.

Die Bausteine sind schnell erklärt. Ein Squad ist ein kleines, funktionsübergreifendes Team, das einen klar umrissenen Teil des Produkts verantwortet und selbst entscheidet, wie es arbeitet. Mehrere Squads, die an verwandten Themen arbeiten, bilden einen Tribe, der in der Beschreibung auf etwa hundert Personen begrenzt ist, damit sich die Beteiligten noch kennen. Ein Chapter fasst Menschen gleicher Fachrichtung innerhalb eines Tribes zusammen, etwa alle Entwickler für das Backend, unter einer fachlichen Führung. Eine Gilde ist eine freiwillige Gemeinschaft über Tribes hinweg, die ein Thema pflegt, zum Beispiel Testautomatisierung oder Webentwicklung.

Daraus entsteht eine Matrix, allerdings eine andere als die klassische. Die Squads führen die tägliche Arbeit, die Chapters sorgen für fachliche Qualität und Entwicklung der Menschen, und die Gilden verbreiten Wissen. Die Autonomie der Squads hängt an einer Bedingung, die in der Beschreibung selbst steht: Sie müssen die Ziele des Unternehmens verstehen und sich an ihnen ausrichten. Autonomie ohne gemeinsame Ausrichtung erzeugt Teams, die schnell in unterschiedliche Richtungen laufen.

## Warum scheitern viele Übernahmen des Spotify-Modells?

Viele Übernahmen scheitern, weil sie die Struktur kopieren und die Bedingungen weglassen, unter denen die Struktur funktioniert. Der Entwickler Jeremiah Lee beschrieb das 2020 in seinem Beitrag „Spotify’s Failed #SquadGoals“. Er schilderte aus seiner Zeit bei Spotify, dass die Organisation selbst nie so aufgestellt war, wie das Papier es nahelegt: Squads blieben voneinander abhängig, und die Koordination lief teils über genau die Mechanismen, die das Modell überflüssig machen sollte.

Für Unternehmen, die das Modell einführen, zeigen sich vier wiederkehrende Ursachen.

Die erste ist die Verwechslung von Beschreibung und Rezept. Das Papier erklärt nicht, wie ein Unternehmen von der Linienorganisation zu Squads kommt, welche Rollen dafür entfallen und wie Budgets neu verteilt werden. Wer den Übergang plant, muss diese Antworten selbst erarbeiten.

Die zweite ist die Umbenennung bestehender Einheiten. Aus der Abteilung wird ein Tribe, aus dem Projektteam ein Squad, aus dem Teamleiter ein Chapter Lead. Die Entscheidungsrechte bleiben, wo sie waren, und die Teams erkennen schnell, dass sich außer der Terminologie nichts geändert hat.

Die dritte ist der Zuschnitt. Spotify schnitt Squads entlang von Produktbereichen, die sich weitgehend unabhängig verändern lassen. Eine Organisation mit starken Abhängigkeiten, etwa durch eine gemeinsame Kernplattform oder regulierte Prozesse, kann dasselbe Muster nicht ohne Weiteres anwenden. Hier hilft das Gesetz von Melvin Conway aus dem Jahr 1968: Organisationen erzeugen Systeme, die ihre Kommunikationsstrukturen abbilden. Wer die Teams anders schneidet als die Architektur, produziert Abstimmungsbedarf an jeder Schnittstelle.

Die vierte ist die fehlende Führungsarbeit. Autonome Teams brauchen Ziele, an denen sie ihre Entscheidungen ausrichten, und eine Führung, die Prioritäten setzt und Aufgaben dem Team überlässt. Fehlt das, entstehen Teams mit viel Freiheit und ohne Richtung.

## Welche Unternehmen haben das Modell übernommen?

Bekannt ist der Fall der niederländischen Bank ING, die ab 2015 ihre niederländische Zentrale nach Squads, Tribes und Chapters neu organisierte, angelehnt an das Vorbild aus Schweden. Das Unternehmen selbst sprach später von eigenen Anpassungen und davon, dass die Arbeitsweise sich weiterentwickelte. Die Lehre aus diesem Fall ist, dass eine Übernahme Jahre dauert, die Führung einbezieht und Anpassungen erfordert, die in keinem Papier stehen.

Im deutschsprachigen Raum berichten Unternehmen unterschiedlicher Größe von ähnlichen Erfahrungen: Der Beginn ist leicht, weil sich Squads schnell bilden lassen. Die Schwierigkeit beginnt, wenn Budgets und Karrierewege dieselbe Veränderung mitvollziehen müssen. Solange die Personalführung in Abteilungen denkt und die Finanzplanung in Kostenstellen, bleibt das Squad eine Projektgruppe mit neuem Namen.

## Was bleibt vom Spotify-Modell nützlich?

Nützlich bleiben vier Prinzipien, die sich unabhängig von den Begriffen anwenden lassen.

Das erste ist der klare Auftrag. Ein Team, das für einen abgegrenzten Teil des Produkts oder des Kundenerlebnisses verantwortlich ist und die Mittel für seine Arbeit selbst hat, liefert schneller als ein Team, das Anfragen aus fünf Abteilungen abarbeitet. Das zweite ist die Trennung von Arbeitsführung und fachlicher Entwicklung: Wer im Alltag Prioritäten setzt, muss nicht auch die Karriere und das Können der Beteiligten verantworten. Das dritte ist der freiwillige Austausch über Teamgrenzen hinweg, der Wissen verbreitet, ohne eine neue Hierarchie zu bauen. Das vierte ist die Ausrichtung über Ziele und Wetten, die Teams ein gemeinsames Bild vom Warum geben.

Wer diese Prinzipien auf die eigene Organisation übertragen will, findet in anderen Modellen ausgearbeitete Rezepte. Team Topologies von Matthew Skelton und Manuel Pais beschreibt vier Teamtypen und drei Interaktionsformen und liefert damit, was dem Spotify-Papier fehlt: Regeln für den Zuschnitt und für die Zusammenarbeit zwischen Teams. Wie das aussieht, zeigt der Beitrag zu [Team Topologies](/blog/team-topologies-teams-fluss-arbeit-schneiden/). Wo Abhängigkeiten viele Teams betreffen, bieten [Flight Levels](/blog/flight-levels-arbeit-drei-ebenen-koordinieren/) eine Sicht auf die Koordination über drei Ebenen, und das [unFIX-Modell](/blog/unfix-modell-organisationsbausteine-starrer-strukturen/) stellt Organisationsbausteine bereit, die sich kombinieren lassen.

## Wann lohnt sich ein Spotify-ähnlicher Ansatz?

Ein Spotify-ähnlicher Ansatz lohnt sich, wenn drei Voraussetzungen zusammentreffen: Das Unternehmen entwickelt ein Produkt oder eine Plattform mit mehreren Bereichen, die sich weitgehend getrennt verändern lassen, die Führung ist bereit, Entscheidungsrechte abzugeben, und es gibt eine kritische Masse von etwa fünf bis zehn Teams, die tatsächlich Abstimmungsprobleme haben. Mit weniger Teams reicht ein gut geführtes Scrum- oder Kanban-System, bei dem eine gemeinsame Liste die Reihenfolge klärt.

**Prüfraster: Welches Element passt zu Ihrer Organisation?**
Kriterium | Das Spotify-Modell als Vorbild | Ein anderer Weg | Mit Niehues Consulting
Zuschnitt der Teams | Produktbereiche mit wenigen Abhängigkeiten | Starke Abhängigkeiten: Plattform- und Unterstützungsteams nach Team Topologies | Zuschnitt aus Wertströmen und Systemlandschaft abgeleitet
Entscheidungsrechte | Teams entscheiden über Lösung und Arbeitsweise | Zentrale Vorgaben, etwa durch Regulierung: klare Leitplanken statt voller Autonomie | Entscheidungsrechte je Thema schriftlich festgelegt
Fachliche Führung | Chapter mit eigener Führung | Kleine Organisation: Fachverantwortung im Team | Rollen nach Größe und Reifegrad gewählt
Wissensaustausch | Gilden und freiwillige Gemeinschaften | Wenige Teams: regelmäßiger Austausch im Kalender | Austauschformate je Bedarf
Koordination | Gemeinsame Ziele und Quartalsabstimmung | Viele Abhängigkeiten: Big Room Planning und Schnittstellenvereinbarung | Koordination nach Anzahl und Art der Abhängigkeiten

## Wie führen Sie Elemente des Modells schrittweise ein?

Sie führen Elemente schrittweise ein, indem Sie mit einem Bereich beginnen, in dem der Zuschnitt klar ist, und die Veränderung an Entscheidungen statt an Namen messen. In fünf Schritten gelingt das in einer überschaubaren Organisation.

1. Ein Pilotbereich: Wählen Sie einen Produktbereich mit überschaubaren Abhängigkeiten und einer Führungskraft, die Entscheidungsrechte tatsächlich abgeben will.
2. Auftrag und Ziele: Schreiben Sie für jedes Team auf, welchen Teil des Produkts es verantwortet, welche Kennzahl es verändern soll und welche Entscheidungen es ohne Rückfrage trifft.
3. Fachliche Führung klären: Legen Sie fest, wer die Entwicklung der Menschen verantwortet, wenn die Linie nicht mehr den Alltag steuert, und wie Beurteilungen entstehen.
4. Abhängigkeiten zählen: Erfassen Sie vier Wochen lang, wie oft ein Team auf ein anderes wartet. Die Zahl zeigt, ob der Zuschnitt stimmt.
5. Nach drei Monaten bewerten: Prüfen Sie Durchlaufzeit und Wartezeit gegen den Ausgangswert und entscheiden Sie über die Ausweitung.

**Woran Sie eine reine Umbenennung erkennen**
- Die Teams haben neue Namen, aber dieselben Vorgesetzten und Genehmigungswege.
- Budgets liegen weiter bei Abteilungen, nicht bei Produkten.
- Zielvereinbarungen und Bonusregeln folgen der alten Struktur.
- Das Team wartet auf Freigaben für Entscheidungen, die es laut Auftrag selbst treffen soll.

## Spotify-Modell und Delivery: Was Entscheider prüfen sollten

Aus der Lieferperspektive zählt am Ende, ob Ergebnisse schneller und verlässlicher beim Kunden ankommen. Ein Organisationsmodell ist dafür ein Mittel. Die Prüfung gelingt über wenige Kennzahlen: die Durchlaufzeit von der Idee bis zur Auslieferung, die Zahl der Übergaben und die Zeit, die Arbeit in Warteschlangen verbringt. Verbessern sich diese Werte nach der Reorganisation nicht, war die Reorganisation Kosmetik. Mehr zu den Messgrößen steht im Beitrag über [Flow Metrics](/blog/flow-metrics-durchsatz-work-progress-wartezeit/).

## Organisationsdesign mit Niehues Consulting

[Niehues Consulting](/) ist eine Beratung für KI-Management und Organisationsdesign aus der Lieferperspektive mit Sitz in Düsseldorf. Gründer Marin Niehues baut Organisationen, die liefern, in Projekten von VC-finanzierten Scaleups bis zu DAX-40-Konzernen und in über 20 Ländern auf sechs Kontinenten. Im Leistungsfeld Delivery Management und Organisationsdesign übernimmt er die Rolle als Delivery Manager oder Product Owner und entwirft Teamzuschnitt und Entscheidungswege.

Das Vorgehen folgt dem Niehues Delivery Model mit seinen drei Phasen Verstehen, Bauen und Einführen. Für eine Reorganisation zählen drei Prüffragen besonders: Wer entscheidet, wer liefert, wer nutzt? Welche Rollen, Entscheidungswege und Schnittstellen braucht der Betrieb? Wer verantwortet den Betrieb ab dem ersten Tag? Den Einstieg bildet eine kostenfreie Erstberatung von 30 Minuten, die Sie über den [Kontakt](/#kontakt) vereinbaren. Umfang und Konditionen eines Vorhabens werden in der kostenfreien Erstberatung besprochen.

**Fazit**
Das Spotify-Modell zeigt, wie ein Unternehmen mit autonomen Teams arbeitet, und es liefert Prinzipien, die sich übertragen lassen: klarer Auftrag, Abstimmung über Ziele, fachliche Führung getrennt von der Arbeitssteuerung und freiwilliger Austausch. Als Vorlage zum Kopieren taugt es nicht. Prüfen Sie jedes Element an Ihren Abhängigkeiten, Ihren Entscheidungsrechten und an den Kennzahlen zur Lieferung.

**Grundlage**
- Kniberg, Ivarsson: Scaling Agile @ Spotify, Whitepaper, 2012
- Spotify: Spotify Engineering Culture, Videoreihe, 2014
- Lee, Jeremiah: Spotify’s Failed #SquadGoals, Blogbeitrag, 2020
- Conway, Melvin: How Do Committees Invent?, Datamation, 1968
- Skelton, Pais: Team Topologies, Fachbuch, 2019

## Häufige Fragen

### Was ist der Unterschied zwischen Squad und Tribe?

Ein Squad ist ein kleines Team, das einen Teil des Produkts verantwortet, ein Tribe ist eine Gruppe verwandter Squads. Das Spotify-Papier begrenzt einen Tribe auf etwa hundert Personen, damit sich die Mitglieder noch kennen. Der Squad plant und liefert, der Tribe sorgt für die Abstimmung zwischen den Squads.

### Was ist ein Chapter und was ist eine Gilde?

Ein Chapter vereint Menschen gleicher Fachrichtung innerhalb eines Tribes unter einer fachlichen Führung, eine Gilde ist eine freiwillige Gemeinschaft über Tribes hinweg. Das Chapter kümmert sich um Qualität und Entwicklung der Fachleute, die Gilde um Wissensaustausch zu einem Thema. Beide führen die Squads nicht im Tagesgeschäft.

### Ist das Spotify-Modell ein Framework wie Scrum oder SAFe?

Nein, es ist die Beschreibung einer gewachsenen Organisation. Es hat weder ein Regelwerk noch einen Leitfaden mit Rollenbeschreibungen und Einführungsschritten wie der Scrum Guide. Seine Autoren haben es als Momentaufnahme veröffentlicht, die sich weiterentwickelt.

### Nutzt Spotify das Modell heute noch?

Spotify hat seine Organisation nach 2012 mehrfach angepasst. Ehemalige Mitarbeitende wie Jeremiah Lee berichten, dass das Modell auch zur Zeit der Veröffentlichung nur teilweise gelebt wurde. Sie sollten es deshalb als Anregung und nicht als aktuellen Stand eines Unternehmens lesen.

### Eignet sich das Spotify-Modell für den Mittelstand?

Es eignet sich, wenn das Unternehmen mehrere Produktbereiche mit eigenen Teams hat und die Führung Entscheidungsrechte abgibt. Bei weniger als fünf Teams reicht meist ein einfacheres System mit gemeinsamer Prioritätenliste. Entscheidend ist, ob Teams wegen Abstimmungen warten, nicht die Größe des Unternehmens.

### Welche Alternativen gibt es zum Spotify-Modell?

Alternativen sind Team Topologies und Flight Levels sowie das unFIX-Modell und Sociocracy 3.0. Team Topologies liefert Regeln für den Teamzuschnitt, Flight Levels ordnet Koordination über drei Ebenen, unFIX bietet kombinierbare Organisationsbausteine, und Sociocracy 3.0 beschreibt Entscheidungsmuster. Welche passt, hängt an Ihren Abhängigkeiten und der Zahl der Teams.

### Wie lange dauert die Einführung von Squads und Tribes?

Die Einführung eines Piloten dauert einige Wochen, die Veränderung von Budgets und Karrierewegen dauert Jahre. Der Beginn ist leicht, weil sich Teams schnell neu zuschneiden lassen. Die Zeit geht in die Anpassung der Führung und der Prozesse, die die Teams umgeben.

### Wer ist für die Karriere der Mitarbeitenden im Spotify-Modell zuständig?

Dafür ist der Chapter Lead zuständig, eine fachliche Führungskraft, die selbst im Squad mitarbeitet. Er verantwortet Entwicklung und Beurteilung der Fachleute seines Chapters. Der Squad steuert die tägliche Arbeit, der Chapter Lead die fachliche Laufbahn.