Spotify Modell erklärt: So verdient Spotify wirklich Geld

Ein Kollege hat mir vor ein paar Monaten stolz sein Organigramm gezeigt. Vier Tribes, elf Squads, zwei Chapters pro Tribe, dazu eine Guild für „Platform Engineering". Alles sauber gezeichnet. Ich habe ihn gefragt, wer eigentlich entscheidet, wenn zwei Squads sich uneinig sind. Er hat eine halbe Minute nachgedacht und dann gesagt: „Der Tribe Lead natürlich." Genau da war das Spotify-Modell schon tot, bevor es überhaupt lebte.

Diese Antwort bekomme ich oft, wenn ich über das Spotify-Modell rede. Auf dem Papier sieht es aus wie ein Rezept. In der Praxis ist es eine Sammlung von Prinzipien, die an sehr spezifische Bedingungen gebunden waren. Ich habe zwei Firmen begleitet, die es eingeführt haben – eine hat es nach 14 Monaten wieder eingerissen, die andere hat einen Teil behalten und den Rest weggeschmissen. Beides war richtig.

Das Spotify-Modell einfach erklärt: vier Begriffe, ein Versprechen

Die Grundidee ist ein Satz: kleine, eigenständige Teams sollen Produkte von Anfang bis Ende verantworten, ohne für jede Entscheidung nach oben zu laufen. Henrik Kniberg und Anders Ivarsson haben das 2012 in einem Whitepaper beschrieben, das ursprünglich als interne Dokumentation gedacht war. Dass es zum weltweiten Vorbild wurde, war ein Unfall der Geschichte.

Squads: das eigentliche Team

Ein Squad ist ein crossfunktionales Team von meist sechs bis zwölf Menschen – Entwicklung, Design, Product, manchmal Data. Es hat ein langfristiges Ziel und, das ist der entscheidende Punkt, die Befugnis, dieses Ziel selbst zu erreichen. Kein Projektleiter, der dazwischensteht. Kein Ticket, das durch eine Fremdabteilung wandert.

Der Vergleich, den ich am hilfreichsten finde: ein Squad ist wie eine kleine Firma, die einem größeren Konzern gehört. Sie hat Budget, Auftrag und Rechenschaftspflicht – aber nicht bei jedem Schritt eine Rückfrage.

Tribes, Chapters, Guilds – und warum der Chapter der unterschätzte Held ist

Mehrere Squads mit ähnlichem Themenfeld bilden einen Tribe. Die Faustregel laut Whitepaper: rund 40 bis über 100 Personen, mehr als das und die informellen Absprachen brechen weg. Dann kommen die beiden Querstrukturen, die in der Debatte oft untergehen:

• Chapter – alle mit derselben Fachrolle (etwa alle iOS-Entwickler eines Tribes) treffen sich regelmäßig. Der Chapter Lead ist fachliche Führungskraft, nicht disziplinarische Vorgesetzte:r. Genau hier liegt in Deutschland der Sprengstoff.
• Guild – ein freiwilliger, offener Kreis zu einem Thema quer durch die Firma. Wer will, kommt. Kein Reporting, keine Zielvorgabe.
• Tribe Lead – verantwortet das Ganze, soll aber laut Modell möglichst wenig operativ eingreifen.

Kurz gesagt: Das Modell versucht, zwei Dinge gleichzeitig zu lösen, die sich normalerweise beißen – Autonomie in der Breite und Fachlichkeit in der Tiefe. Der Chapter ist die Brücke. Und in fast jedem gescheiterten Versuch, den ich gesehen habe, war der Chapter der erste Baustein, der wegrationalisiert wurde. „Wir haben ja schon eine Fachabteilung", hieß es dann. Und damit war die Fachlichkeit wieder hierarchisch, und die Squads wurden zu Projektteams mit neuem Namen.

Ist das Spotify-Modell gescheitert?

Die ehrliche Antwort: Das Modell als Blaupause ist gescheitert. Das Modell als Denkanstoß lebt weiter.

Spotify selbst hat die starre Struktur über die Jahre verändert. Die Gründe sind wenig spektakulär und sehr lehrreich: Das Unternehmen wurde größer, das Produktportfolio breiter, der Druck von Wettbewerbern härter. Eine Organisation, die 2012 mit einer Handvoll Squads eine App gebaut hat, steht irgendwann vor Fragen, die sich nicht in autonome Einheiten zerlegen lassen – Plattforminvestitionen etwa, oder Sicherheitsarchitektur, oder die Entscheidung, welches Feature man nicht baut.

Warum die Kopie scheitert, nicht das Original

Was ich in beiden begleiteten Firmen gesehen habe, war ein identisches Muster. Die Struktur wurde übernommen, die Machtfrage nicht. Zwei Beobachtungen:

1. Die alten Abteilungsleiter wurden zu „Tribe Leads" umbenannt und behielten ihr Budgetrecht. Damit war jede Squad-Entscheidung faktisch vorläufig.
2. Die Chapters wurden mit den bestehenden Fachabteilungen zusammengelegt – mit dem Ergebnis, dass der Chapter Lead plötzlich Personalgespräche führte und Zielvereinbarungen schrieb. Das Modell kennt das ausdrücklich nicht.

Bei einer der beiden Firmen hat sich das in Zahlen gezeigt: Die Time-to-Market für ein einfaches Feature lag nach zwölf Monaten „agiler Transformation" bei 9 Wochen – vorher waren es 7. Man hatte Meetings reduziert und Entscheidungsschleifen eingebaut. Der Formalismus war weg, die Blockade geblieben.

Spoiler: Es lag nicht am Modell. Es lag daran, dass niemand bereit war, die Freigabe aufzugeben.

Spotify-Modell, SAFe, LeSS: worin sie sich wirklich unterscheiden

Wenn ich gefragt werde, welches Framework das richtige ist, stelle ich immer zuerst eine Gegenfrage: Wie viele Menschen sollen davon erfasst werden? Denn die Skalierungsansätze unterscheiden sich weniger in ihren Werten als in der Frage, wie viel Struktur sie überhaupt zulassen.

Ansatz	Grundlogik	Führungsrolle	Passt zu
Spotify-Modell	Autonome Squads, lose gekoppelt	Fachlich statt disziplinarisch	Produktorganisationen mit echter Entscheidungsfreiheit
SAFe	Skalierte Planung in Zyklen, viele definierte Rollen	Aufgabenverteilung, Planungsgremien	Regulierte Umgebungen, große Programmportfolios
LeSS	Viele Teams, ein Product Backlog, ein Product Owner	Radikal reduziert	Ein Produkt, viele Teams, hohe Reife
Scrum@Scale	Scrum-Muster rekursiv auf allen Ebenen	Moderat, pro Ebene ein Kreis	Organisationen, die Scrum schon ernst nehmen

Meine Meinung, und dafür würde ich mich auf einen Berg stellen: Das Spotify-Modell ist kein Skalierungsframework. Es ist ein Bericht darüber, wie ein bestimmtes Unternehmen mit einem bestimmten Produkt zu einer bestimmten Zeit gearbeitet hat. SAFe hingegen ist ein Framework – mit allem, was dazugehört, inklusive der Gefahr, dass man Prozess mit Fortschritt verwechselt.

Nachteile, über die zu wenig geredet wird

Die Kritik am Spotify-Modell bleibt meistens bei „ist nicht eins zu eins übertragbar" stehen. Das ist zu bequem. Es gibt konkrete strukturelle Schwächen, die schon im Original angelegt sind.

Was passiert mit den Führungskräften?

Das Modell sagt sehr klar, was ein Chapter Lead nicht ist. Es sagt erstaunlich wenig darüber, wer dann die Personalentwicklung, die Gehaltsentscheidung, die Konfliktmoderation macht. In deutschen Unternehmen mit Betriebsrat und klassischen Arbeitsverträgen ist das kein Detail, sondern ein Problem, das man nicht wegmoderieren kann. Bei der Firma, die es nach 14 Monaten eingerissen hat, war das der Hauptgrund – nicht die Technik, nicht die Kultur, sondern arbeitsrechtliche Zuständigkeiten, die plötzlich niemandem zugeordnet waren.

Autonomie, die zur Inselbildung führt

Ein zweiter Punkt, der in der Euphorie untergeht: Wenn Squads wirklich eigenständig entscheiden, entscheiden sie auch über ihre technische Basis. Zwei Jahre später hat man dann vier verschiedene Datenbankzugänge, drei Logging-Stacks und keine Person, die das Gesamtbild überblickt. Das Spotify-Modell kennt für dieses Problem die Guild – aber eine freiwillige Guild hat keine Entscheidungsmacht. Freiwilligkeit und Verbindlichkeit sind Gegensätze. Wer Plattformstandards braucht, kommt mit diesem Baustein allein nicht durch.

Und der dritte Nachteil ist der unangenehmste: Das Modell braucht Menschen, die mit echter Freiheit umgehen können. Nicht jeder will das. Es gibt Kolleginnen und Kollegen, die klare Vorgaben als Entlastung erleben – und die landen in einem Squad-Modell in einer Dauerunsicherheit, die niemand offen anspricht.

Wie Sie es einführen, ohne sich zu verbrennen

Hier ist die Vorgehensweise, die ich inzwischen empfehle – nicht die schönste, aber die, die überlebt.

1. Kein Organigramm in den ersten sechs Wochen. Suchen Sie einen echten Produktbereich mit echtem Auftrag. Einen. Nicht vier.
2. Macht vor Struktur. Bevor irgendwer „Squad" heißt, muss geklärt sein: Wer gibt Budget frei? Wer stoppt ein Feature? Wenn diese Antworten dieselben Personen sind wie vorher, sparen Sie sich den Rest.
3. Chapter zuerst, nicht zuletzt. Definieren Sie die Fachführung, bevor Sie die Teams zusammenstellen. Und trennen Sie sie sauber von der disziplinarischen Verantwortung – auch vertraglich.
4. Drei Monate messen. Eine Kennzahl reicht: Wie lange dauert es von der Entscheidung „wir bauen das" bis zum ersten Nutzerkontakt? Vorher und nachher. Bei der Firma, die es durchgezogen hat, ging diese Zeit von 11 auf 4 Wochen – aber erst im siebten Monat, nicht im zweiten.
5. Nach sechs Monaten bewusst prüfen, was Sie weglassen. Die meisten brauchen keine Guilds. Viele brauchen keine Tribes. Fast alle brauchen Squads und Chapters.

Was ich unterschätzt habe, als ich das erste Mal dabei war: Der Widerstand kommt nicht von oben. Er kommt aus der Mitte – von Teamleitern, die plötzlich keine Teamleitung mehr haben und das als Verlust erleben, nicht als Befreiung. Das habe ich beim ersten Mal nicht kommen sehen. Ich hatte nur das Organigramm im Kopf.

Am Rande: Spotify-Abo-Modelle haben mit alldem nichts zu tun

Weil die Suche nach „Spotify-Modell" auch bei Abos landet: Die Tarifstruktur des Streamingdienstes – werbefinanziert, Einzelabo, Familien- und Duo-Tarif – ist ein völlig separates Thema. Da geht es um Preisdiskriminierung und Kundenbindung, nicht um Organisationsdesign. Wenn Sie eigentlich das meinten, sind Sie hier falsch abgebogen.

Der Begriff taucht inzwischen für fast alles auf, was mit dem Unternehmen zu tun hat. Das ist ein gutes Zeichen dafür, wie stark die Marke wirkt – und ein schlechtes dafür, wie ungenau wir über Organisationen reden.

Was mich nach zwei Projekten am meisten beschäftigt, ist eine unbequeme Beobachtung. Beide Firmen wollten „wie Spotify" werden. Keine von beiden hat sich gefragt, ob sie überhaupt ein Produkt haben, das sich so zerlegen lässt. Bei der einen war die Antwort ja. Bei der anderen war das eigentliche Produkt ein Vertriebsprozess – und der lässt sich nicht in autonome Squads schneiden, egal wie oft man das Wort „agil" im Kickoff sagt. Vielleicht ist die erste Frage nicht, wie man das Spotify-Modell einführt. Sondern ob man überhaupt etwas besitzt, das man teilen kann.