Das Spotify Model: Squads, Tribes und Guilds erklärt

2012 veröffentlichten zwei Agile Coaches bei Spotify ein kurzes Whitepaper darüber, wie das Unternehmen seine Entwicklungsteams organisierte. Es war kein Manifest. Es war keine Methode. Es war eine Momentaufnahme, eine Beschreibung davon, wie ein Unternehmen zu einem bestimmten Zeitpunkt zufällig arbeitete. Die Autoren sagten das ausdrücklich.

Innerhalb weniger Jahre hatten Tausende von Organisationen es als vorschreibendes Framework übernommen. Sie nannten ihre Teams “Squads” um, gruppierten sie zu “Tribes”, schufen “Chapters” und “Guilds” und erwarteten, dass die Ergebnisse schon folgen würden. Viele mussten feststellen, dass das Kopieren einer Organisationsstruktur ohne Verständnis für die Kultur dahinter kaum mehr hervorbringt als neue Vokabeln für alte Probleme.

Die tiefere Ironie: Spotify selbst ist weitergezogen. Die eigenen Entwicklerinnen und Entwickler des Unternehmens haben öffentlich eingeräumt, dass das im Whitepaper beschriebene Modell nicht mehr abbildet, wie Spotify arbeitet. Trotzdem bleibt das “Spotify Model” einer der meistdiskutierten Ansätze zum Skalieren agiler Organisationen, gerade weil die Ideen in seinem Kern echte Probleme adressieren, die jedes wachsende Unternehmen kennt.

Dieser Leitfaden erklärt, was das Spotify Model tatsächlich beschrieb, wie seine vier Bausteine funktionieren, warum es sich so weit verbreitet hat, wo es an seine Grenzen kommt und wie du seine Prinzipien übernimmst, ohne in die häufigsten Fallen zu tappen.

Was ist das Spotify Model?

Das Spotify Model geht auf ein Whitepaper von 2012 mit dem Titel “Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds” zurück, geschrieben von Henrik Kniberg und Anders Ivarsson. Kniberg war Agile Coach bei Spotify, Ivarsson der Organisationscoach des Unternehmens. Das Papier, begleitet von einer zweiteiligen Videoreihe, beschrieb, wie Spotify damals seine rund 30 Entwicklungsteams organisierte: etwa 250 Personen, verteilt auf drei Städte.

Das Entscheidende an diesem Whitepaper ist, was es nicht war. Es war kein Framework zum Übernehmen. Es war keine Sammlung von Praktiken zum Befolgen. Die Autoren beschrieben sorgfältig, was Spotify zu diesem konkreten Zeitpunkt tat, nicht was andere Unternehmen tun sollten. Kniberg selbst hat diesen Unterschied wiederholt betont: Was sie beschrieben, war Spotifys Arbeitsweise, kein Modell von der Stange.

Das Whitepaper beschrieb eine Reihe organisationaler Strukturen (Squads, Tribes, Chapters und Guilds), die ein bestimmtes Problem lösen sollten: wie sich Tempo und Autonomie kleiner Teams erhalten lassen, während man auf Hunderte von Entwickelnden an einem gemeinsamen Produkt skaliert. Es war die Spannung zwischen Autonomie und Ausrichtung, in Struktur gegossen.

Was dann geschah, war absehbar. Das Whitepaper war klar, gut illustriert und sprach ein Problem an, vor dem Hunderte wachsender Tech-Unternehmen standen. Es verbreitete sich rasend schnell in der agilen Community. Konferenzvorträge zitierten es. Blogbeiträge erklärten es. Beratungsfirmen schnürten Pakete daraus. Innerhalb weniger Jahre war “das Spotify Model” ein anerkanntes Organisationsmuster, übernommen, angepasst und manchmal Organisationen mit völlig anderer Kultur, Grösse und Problemlage komplett übergestülpt.

Die Kluft zwischen dem, was Kniberg und Ivarsson beschrieben, und dem, wie die Branche es aufnahm, ist die prägende Spannung in der Geschichte des Spotify Model: eine beschreibende Momentaufnahme, behandelt wie ein vorschreibender Bauplan.

Die vier Bausteine

Das Spotify Model ordnet Menschen in vier einander überlappende Strukturen, von denen jede ein anderes Koordinationsproblem löst. Zu verstehen, wie diese vier Teile zueinander stehen, ist wesentlich: Sie sind keine unabhängigen Abteilungen, sondern sich kreuzende Ebenen einer Matrix.

Squads

Der Squad ist die grundlegende Einheit. Ein Squad ist ein kleines, bereichsübergreifendes Team von 6 bis 12 Personen mit durchgängiger Verantwortung für einen bestimmten Funktionsbereich, eine Produktkomponente oder eine Nutzerreise. Jeder Squad arbeitet wie ein Mini-Start-up: Er hat seine eigene Mission, entscheidet über seine eigene Arbeitsweise und steuert sein eigenes Backlog.

Ein Squad enthält typischerweise alle Fähigkeiten, die nötig sind, um seine Arbeit zu entwerfen, zu entwickeln, zu testen und auszuliefern: Entwickelnde, eine Person für Design, einen Product Owner und eine Person für Qualitätssicherung. Der Squad muss Arbeit nicht an ein anderes Team übergeben, um etwas fertigzustellen. Das ist Absicht: Die bereichsübergreifende Zusammensetzung beseitigt Übergaben, reduziert Abhängigkeiten und gibt dem Squad Autonomie über seine Auslieferung.

Der Product Owner legt fest, was der Squad baut und in welcher Reihenfolge. Wie gebaut wird, entscheidet der Squad selbst. Das Spotify Model schreibt keine formale Rolle als Scrum Master vor, auch wenn viele Squads eine solche einführen. Der Squad wählt seine eigene agile Methode: Scrum, Kanban, eine Mischung oder etwas ganz anderes.

Autonomie ist das prägende Merkmal. Squads geniessen das Vertrauen, ihre eigenen technischen Entscheidungen zu treffen, ihre Arbeit selbst zu steuern und unabhängig auszuliefern. Dieses Vertrauen ist nicht bedingungslos, es hängt von der Ausrichtung an der übergeordneten Produktrichtung ab, aber die Voreinstellung ist Autonomie, und die Koordination entsteht aus Kultur und gemeinsamen Zielen statt aus Steuerung von oben.

Tribes

Ein Tribe ist eine Ansammlung von Squads, die an einem verwandten Produktbereich arbeiten. Wenn Squads die Mini-Start-ups sind, ist der Tribe der Inkubator. Tribes umfassen typischerweise zwischen 40 und 150 Personen. Die Obergrenze ist bewusst gewählt und stützt sich auf die Forschung von Robin Dunbar, wonach Menschen zu etwa 150 Personen stabile soziale Beziehungen unterhalten können. Darüber hinaus beginnt vertrauensbasierte Koordination zu bröckeln, und formalisierte Prozesse werden nötig.

Jeder Tribe hat einen Tribe Lead, der dafür verantwortlich ist, ein produktives Umfeld für die Squads zu schaffen. Der Tribe Lead führt weder einzelne Squads noch trifft er ihre Entscheidungen. Seine Aufgabe ist es, Hindernisse zu beseitigen, die Koordination zwischen den Squads zu erleichtern und die Ausrichtung an der übergeordneten Richtung der Organisation sicherzustellen.

Tribes erzeugen räumliche und soziale Nähe. Im ursprünglichen Spotify Model sassen die Squads eines Tribes zusammen, teilten gemeinsame Flächen und trafen sich regelmässig im ganzen Tribe. Diese Nähe ist kein Zufall, sie ist ein bewusster Mechanismus für informelle Koordination. Wenn Menschen im selben Bereich arbeiten, hören sie Gespräche mit, laufen sich an der Kaffeemaschine über den Weg und teilen Kontext, ohne dafür Meetings zu brauchen.

Die Grenze des Tribes definiert einen Koordinationsraum. Squads im selben Tribe stimmen sich häufig und informell ab. Squads in verschiedenen Tribes stimmen sich seltener und bewusster ab. Daraus entsteht eine natürliche Spannung: Gut gezogene Tribe-Grenzen verringern interne Reibung, schlecht gezogene erzeugen Silos.

Chapters

Chapters lösen das Kompetenzproblem, das Squads erzeugen. Wenn du Menschen in bereichsübergreifende Squads einteilst, verteilen sich die Fachleute. Deine iOS-Entwickelnden sitzen verstreut in zehn verschiedenen Squads und arbeiten je an einer anderen Funktion. Wer stellt sicher, dass sie einheitliche technische Standards einhalten? Wer coacht sie fachlich? Wer kümmert sich um Laufbahnentwicklung und Lohngespräche?

Ein Chapter ist eine Gruppe von Menschen mit demselben Fähigkeitsprofil, die im selben Tribe, aber in verschiedenen Squads arbeiten. Alle Backend-Entwickelnden eines Tribes bilden ein Chapter. Alle Designerinnen und Designer bilden ein weiteres. Alle Testenden noch eines. Jedes Chapter hat einen Chapter Lead, und genau hier führt das Modell seine grösste strukturelle Spannung ein.

Der Chapter Lead ist die formale Führungskraft der Chapter-Mitglieder. Er führt Leistungsgespräche, kümmert sich um Laufbahnentwicklung und Lohnfragen. Gleichzeitig ist der Chapter Lead aber ein mitarbeitendes Mitglied eines Squads und leistet operative Arbeit neben seinen Führungsaufgaben. Diese Doppelrolle ist Absicht: Sie hält den Chapter Lead mit der täglichen Realität der Arbeit verbunden. Sie bedeutet aber auch, dass er zwei Jobs trägt.

Chapters treffen sich regelmässig, um Wissen zu teilen, sich über technische Praktiken abzustimmen, Werkzeugentscheidungen zu diskutieren und Anliegen über Squad-Grenzen hinweg zu klären. Sie sind der Mechanismus, über den technische Einheitlichkeit und fachliches Wachstum über Squad-Grenzen hinweg entstehen.

Guilds

Guilds erweitern das Konzept der Community of Practice über die Tribe-Grenzen hinaus. Eine Guild ist eine freiwillige, tribeübergreifende Gruppe von Menschen, die ein Interesse, eine Fähigkeit oder ein Wissensgebiet teilen. Anders als Chapters stehen Guilds allen offen. Du musst keine Backend-Entwicklerin sein, um der Backend-Guild beizutreten. Du musst nur interessiert sein.

Jede Guild hat eine Guild Coordinator-Rolle, die Aktivitäten organisiert (Meetups, Workshops, gemeinsame Kanäle, Dokumentationsarbeit), aber keine formale Autorität besitzt. Die Mitgliedschaft ist freiwillig, die Teilnahme selbstbestimmt, und die Guild existiert nur so lange, wie sie ihren Mitgliedern Wert bringt.

Guilds sind das Gegenmittel gegen Silos zwischen den Tribes. Wenn Tribes gross und in sich geschlossen sind, kann Wissen innerhalb ihrer Grenzen gefangen bleiben. Guilds schaffen Kanäle für Querbestäubung: Eine Test-Guild teilt Automatisierungspraktiken über alle Tribes hinweg, eine Webentwicklungs-Guild stimmt Frontend-Standards unternehmensweit ab, eine Leadership-Guild teilt Führungspraktiken über die ganze Organisation.

Wie sich die vier Strukturen überschneiden

Die vier Strukturen bilden eine Matrix, aber eine Matrix mit einer klaren Hauptachse. Der Squad ist die primäre Organisationseinheit. Dort geschieht die Arbeit, dort verbringen die Menschen die meiste Zeit, dort fallen die alltäglichen Entscheidungen.

Tribes gruppieren Squads zur Koordination. Chapters gruppieren Fachleute für die Kompetenz. Guilds gruppieren Interessierte für den Wissensaustausch.

Jede entwickelnde Person gehört zu genau einem Squad und einem Chapter. Sie kann zu einer oder mehreren Guilds gehören. Das heisst, jede Person hat zwei Berichtslinien: ihren Squad (für die Produktauslieferung) und ihr Chapter (für Personalführung und technische Standards). Das ist die Matrixorganisation nach Spotify Model, gebaut, um die Vorteile von fachlicher Expertise und bereichsübergreifender Auslieferung gleichzeitig zu ernten.

Tribe A
├── Squad 1: [Designer, iOS Dev, Backend Dev, Tester, Product Owner]
├── Squad 2: [Designer, iOS Dev, Backend Dev, Android Dev, Product Owner]
├── Squad 3: [Designer, Backend Dev, Backend Dev, Tester, Product Owner]
│
├── Chapter: iOS Developers (umfasst Squad 1 + Squad 2)
├── Chapter: Backend Developers (umfasst alle Squads)
├── Chapter: Designers (umfasst alle Squads)
└── Chapter: Testers (umfasst Squad 1 + Squad 3)

Guild: Web Development (umfasst Tribe A + Tribe B + Tribe C)
Guild: Testing Practices (umfasst alle Tribes)

Die Kernprinzipien hinter dem Modell

Die strukturellen Bestandteile (Squads, Tribes, Chapters, Guilds) sind der sichtbare Teil des Spotify Model. Sie sind aber nicht das, was es bei Spotify zum Funktionieren gebracht hat. Das waren kulturelle Prinzipien, die die Struktur stützen sollte. Kopiere die Struktur ohne diese Prinzipien, und du bekommst eine Hierarchie in Spotify-Form.

Autonomie mit Ausrichtung

Das ist die zentrale Spannung, um die herum das ganze Modell gebaut ist. Squads sind autonom: Sie wählen ihre Methoden, steuern ihre Arbeit und treffen ihre technischen Entscheidungen selbst. Aber sie sind nicht unabhängig. Sie sind auf eine gemeinsame Produktvision und einen gemeinsamen Satz strategischer Prioritäten ausgerichtet.

Kniberg beschrieb das als Spektrum. Am einen Ende hohe Ausrichtung und hohe Autonomie: Führungspersonen kommunizieren das zu lösende Problem und warum es zählt, die Squads finden heraus, wie sie es lösen. Am anderen Ende niedrige Ausrichtung und hohe Autonomie: Squads tun, was sie wollen, und das Ergebnis ist eine Ansammlung unverbundener Anstrengungen. Das Ziel ist, im Quadranten mit hoher Ausrichtung und hoher Autonomie zu bleiben, in dem Squads frei entscheiden, wie sie arbeiten, aber klar wissen, was die Organisation erreichen will.

Das verlangt Führungspersonen, die Richtung formulieren können, ohne Lösungen zu diktieren. Es verlangt Squads, die den Kontext des grösseren Bildes suchen, statt lokal zu optimieren. Und es verlangt Transparenz in der Organisation, damit Squads sich selbst ausrichten können, statt von Vorgesetzten ausgerichtet werden zu müssen.

Kultur vor Prozess

Das Spotify Model bevorzugte kulturelle Normen ausdrücklich gegenüber formalisierten Prozessen. Regeln blieben minimal. Vertrauen war die Voreinstellung. Die Annahme lautete: Gute Leute einstellen, ihnen Kontext geben und ihnen zutrauen, vernünftig zu entscheiden, bringt bessere Ergebnisse als detaillierte Prozessdokumentation.

Bei Spotify funktionierte das, weil das Unternehmen stark in seine Entwicklungskultur investiert hatte. Psychologische Sicherheit, offene Kommunikation und Toleranz für Experimente waren keine Slogans, sondern gelebtes Verhalten. Die Kultur formte das Modell, nicht umgekehrt.

Vertrauen als Voreinstellung

Squads wurde standardmässig vertraut. Sie mussten sich Autonomie nicht über eine Erfolgsbilanz verdienen oder ihre Entscheidungen gegenüber dem Management rechtfertigen. Die organisationale Annahme war, dass Squads gute Entscheidungen treffen und dass gelegentliche Fehler ein akzeptabler Preis für das Tempo sind, das Autonomie bringt.

Das ist schwerer umzusetzen, als es klingt. Die meisten Organisationen arbeiten mit der umgekehrten Voreinstellung: Vertrauen muss verdient werden, Autonomie wird schrittweise gewährt. Auf Vertrauen als Voreinstellung umzustellen verlangt von Führungspersonen, zu akzeptieren, dass manche Squads Entscheidungen treffen werden, mit denen sie nicht einverstanden sind, und nur dann einzugreifen, wenn die Folgen gewichtig sind, nicht schon dann, wenn sie selbst anders entschieden hätten.

Querbestäubung statt Silos

Chapters und Guilds gab es genau deshalb, um den Silo-Effekt zu verhindern, den autonome Teams erzeugen können. Wenn Squads vollständig autonom sind, lösen sie dasselbe Problem womöglich auf drei verschiedene Arten, setzen unvereinbare Technologien ein oder bauen Wissen auf, das nie über den Squad hinausdringt.

Das Modell begegnete dem mit strukturellen Querschnitten: Chapters für die technische Abstimmung innerhalb der Tribes, Guilds für den Wissensaustausch über die Tribes hinweg. Der Schwerpunkt lag auf organischem Austausch (geteilte Praktiken, freiwillige Teilnahme, Lernen unter Gleichen) statt auf von oben verordneten Standards.

Ständige Verbesserung statt Playbook

Das Spotify Model war nie statisch. Das Whitepaper beschrieb einen bestimmten Moment in der Entwicklung des Unternehmens. Spotify entwickelte seine Organisationsstruktur nach der Veröffentlichung weiter. Das Modell selbst sollte als Ausgangspunkt für fortlaufendes Experimentieren dienen, nicht als Ziel.

Dieses Prinzip ist zugleich die grösste Stärke des Modells und die Quelle seiner häufigsten Fehlübernahme. Wenn das Modell eine Einladung zum Experimentieren ist, verstösst schon das exakte Kopieren gegen seine Grundphilosophie.

Das Spotify Model im Vergleich mit anderen Organisationsmodellen

Das Spotify Model steht in einer breiteren Landschaft von Ansätzen zur Organisationsgestaltung. Jeder adressiert andere Probleme, arbeitet mit einem anderen Formalisierungsgrad und passt in andere Kontexte. Der folgende Vergleich hilft zu klären, was das Spotify Model gegenüber den Alternativen bietet und was nicht.

Dimension	Klassische Hierarchie	Spotify Model	Holacracy	Sociocracy	RenDanHeYi	Beta Codex / Peach	DSO (Bayer)	SAFe	Buurtzorg
Autoritätsstruktur	Befehlskette von oben nach unten	Squad-Autonomie innerhalb der Ausrichtung des Tribes	Rollen und Kreise, geregelt durch eine Verfassung	Konsentbasierte Kreise mit doppelter Verknüpfung	Verteilt auf Mikrounternehmen	Dezentral, Zentrum und Peripherie	Verteilt auf autonome Teams	Hierarchisch mit agilen Ebenen	Selbstorganisierte Quartierteams
Grundeinheit	Abteilung / Division	Squad (6-12, bereichsübergreifend)	Kreis mit definierten Rollen	Kreis mit doppelter Verknüpfung	Mikrounternehmen (10-15 Personen)	Autonome Zelle an der Peripherie	Kunden- oder Produktteam (6-10)	Agile Release Train	Selbstorganisiertes Team (10-12 Pflegefachpersonen)
Entscheidungsfindung	Freigabe durch Vorgesetzte	Autonomie auf Squad-Ebene	Integrativer Entscheidungsprozess	Konsent (keine begründeten Einwände)	Marktgetrieben, Autonomie der Mikrounternehmen	Auf Können gestützt, an der Peripherie	95 % auf Teamebene	PI Planning und Teamentscheidungen	Konsens auf Teamebene
Skalierungsmechanismus	Weitere Führungsebenen	Tribes (max. ~150), Chapters, Guilds	Verschachtelte Kreise	Verschachtelte Kreise mit doppelter Verknüpfung	Ökosysteme von Mikrogemeinschaften	Föderalisierte Zellen	90-Tage-Zyklen, VACC-Coaching	ARTs, Solution Trains, Portfolio	Regionales Coaching und Backoffice
Führungsmodell	Hierarchische Führungskräfte	Tribe Leads, Chapter Leads	Lead Links und Rep Links	Moderierende und Delegierte	”Jede Person ist ihr eigener CEO”	Verteilt, auf Können gestützt	VACC (Visionaries, Architects, Catalysts, Coaches)	RTE, System Architect, Product Management	Coach (keine Führungskraft)
Formalisierungsgrad	Hoch (Richtlinien, Verfahren)	Niedrig bis mittel (kulturgetrieben)	Sehr hoch (geschriebene Verfassung)	Mittel (prinzipienbasiert)	Mittel (Marktdisziplin)	Niedrig (Netzwerkprinzipien)	Mittel (VACC und 90-Tage-Struktur)	Sehr hoch (SAFe-Framework)	Niedrig (prinzipienbasiert)
Passt am besten zu	Stabilen Umfeldern, viel Compliance	Produktorientierten Tech-Unternehmen, 50-500 Entwickelnde	Organisationen, die explizite Governance wollen	Organisationen, denen einbeziehende Entscheidungen wichtig sind	Grosskonzernen, die unternehmerisches Tempo suchen	Marktnahen Organisationen, die dezentralisieren wollen	Grosskonzernen, die Bürokratie abbauen	Grosskonzernen, die agile Lieferung skalieren	Pflege- und Dienstleistungsorganisationen
Erprobte Grössenordnung	Jede Grösse	Hunderte bis wenige Tausend	Hunderte bis wenige Tausend	Hunderte bis wenige Tausend	80’000+ Mitarbeitende	Unterschiedlich	100’000+ (laufend)	Zehntausende	15’000+ Fachpersonen

Die wichtigsten Unterschiede

Spotify Model vs. SAFe: SAFe (Scaled Agile Framework) ist vorschreibend, wo das Spotify Model beschreibend ist. SAFe liefert detaillierte Zeremonien, Rollen und Planungsereignisse auf jeder Ebene der Organisation. Das Spotify Model liefert strukturelle Konzepte und traut den Teams zu, die Details zu füllen. SAFe funktioniert gut für Organisationen, die Prozessstrenge und Nachvollziehbarkeit für Compliance brauchen. Das Spotify Model funktioniert besser für Organisationen mit starker Entwicklungskultur, die sich gegen schwere Prozesse sträuben. Viele Organisationen nutzen Elemente von beidem.

Spotify Model vs. Holacracy: Holacracy liefert eine formale Governance-Verfassung mit expliziten Regeln dafür, wie Rollen entstehen, wie Entscheidungen fallen und wie Meetings ablaufen. Das Spotify Model hat keine Verfassung. Seine Governance ist kulturell, nicht prozedural. Organisationen, die klare, dokumentierte Governance-Prozesse wollen, finden Holacracy strukturierter. Organisationen, die kulturelle Normen formalen Regeln vorziehen, empfinden das Spotify Model als natürlicher.

Spotify Model vs. Sociocracy: Sociocracy stellt konsentbasierte Entscheidungen und die doppelte Verknüpfung zwischen Governance-Ebenen ins Zentrum. Das Spotify Model schreibt keinen Entscheidungsprozess vor; die Squads entscheiden, wie sie entscheiden. Sociocracy passt besser zu Organisationen, die strukturierte Governance über alle Ebenen wollen. Das Spotify Model passt besser in die Produktentwicklung, wo das Liefertempo mehr zählt als formale Governance.

Spotify Model vs. RenDanHeYi: RenDanHeYi bei Haier treibt die Autonomie weiter als das Spotify Model. Jedes Mikrounternehmen arbeitet mit voller Ergebnisverantwortung und stellt sein eigenes Team ein. Spotifys Squads sind autonom darin, wie sie arbeiten, aber nicht darin, wie sie besetzt oder finanziert werden. RenDanHeYi ist für marktgetriebene Konzerne gedacht, in denen jede Einheit direkt mit Kundinnen und Kunden verbunden ist. Das Spotify Model ist für Produktentwicklungsorganisationen gedacht, in denen Squads zu einem gemeinsamen Produkt beitragen.

Spotify Model vs. Beta Codex: Beta Codex arbeitet auf einer höheren Abstraktionsebene. Es definiert 12 Gesetze dazu, wie Organisationen strukturiert sein, arbeiten und sich anpassen sollten, ohne konkrete Teamformen vorzugeben. Das Spotify Model ist konkreter: Es definiert bestimmte strukturelle Einheiten (Squads, Tribes, Chapters, Guilds) mit bestimmten Grössen und Beziehungen. Beta Codex kann eine Struktur nach Spotify-Art in seinen peripheren Zellen umfassen, adressiert aber das gesamte Organisationsmodell und nicht nur die Produktentwicklung.

Spotify Model vs. DSO: Dynamic Shared Ownership bei Bayer teilt die Betonung autonomer Teams mit dem Spotify Model, ergänzt sie aber um einen strukturierten Planungstakt (90-Tage-Zyklen) und einen expliziten Führungsrahmen (VACC). DSO war von Anfang an für Konzerngrösse gedacht; das Spotify Model entstand in einer mittelgrossen Entwicklungsorganisation und hat in grösseren Massstäben zu kämpfen.

Warum Spotify weitergezogen ist

Zu verstehen, warum Spotify über sein eigenes Modell hinausgewachsen ist, ist wesentlicher Kontext für alle, die eine Übernahme erwägen. Das Modell war eine Momentaufnahme, und die beschriebene Organisation veränderte sich weiter.

Die Kritik von Jeremiah Lee

2020 veröffentlichte Jeremiah Lee, ein ehemaliger Spotify-Mitarbeiter, eine viel geteilte Kritik mit dem Titel “Spotify’s Failed Squad Goals”. Lee argumentierte, dass das im Whitepaper beschriebene Modell nicht einmal bei Spotify wie beabsichtigt funktioniert habe. Seine wichtigsten Beobachtungen:

• Autonome Squads erzeugten Koordinationsprobleme. Wenn Squads unabhängig ihre eigenen Werkzeuge, Architekturen und Ansätze wählten, war das Ergebnis Zersplitterung: uneinheitliche Codebasen, doppelte Arbeit und Kopfschmerzen bei der Integration.
• Die Chapter-Struktur hielt ihr Versprechen nicht. Chapter Leads waren zwischen ihrer Squad-Arbeit und ihrer Führungsrolle zerrissen, und Chapter-Treffen fühlten sich oft wie ein Nachgedanke an.
• Tribe-Grenzen wurden zu Silos. Tribes, gedacht für fokussierte Koordination, erzeugten auch Mauern. Zusammenarbeit über Tribes hinweg war schwieriger, als das Modell annahm.
• Die Kultur, die das Ganze trug, liess sich nicht übertragen. Spotify hatte eine bestimmte Entwicklungskultur (hohes Vertrauen, starke Autonomienormen, Toleranz für Unordnung), von der das Modell geprägt war. Andere Unternehmen übernahmen die Struktur ohne diese Kultur und erhielten andere Ergebnisse.

Lees Kritik traf einen Nerv, weil sie aussprach, was viele Unternehmen erlebt hatten: Das Spotify Model klang richtig, fühlte sich in einem anderen Kontext umgesetzt aber falsch an.

Die Matrixfalle

Die Rolle des Chapter Lead ist das strukturell fragilste Element des Modells. Ein Chapter Lead ist gleichzeitig mitarbeitendes Mitglied eines Squads (mit Beitrag zur Produktauslieferung) und Führungskraft für Chapter-Mitglieder in mehreren Squads (zuständig für Laufbahnentwicklung, Leistungsrückmeldungen und Lohnentscheide).

Das ist eine Halbzeitrolle in beide Richtungen, und sie erzeugt absehbare Spannungen. In hektischen Sprintphasen dominiert die Squad-Arbeit, und die Chapter-Pflichten werden verschoben. In Zyklen der Leistungsbeurteilung frisst die Führungsarbeit Zeit, die dem Squad zugesagt war. Chapter Leads, die zur Führung neigen, verlieren den Bezug zum Code. Wer zur Technik neigt, wird zur schwachen Führungskraft.

Das Ergebnis ist häufig ein Chapter Lead, der keinen der beiden Jobs gut macht, nicht weil es ihm an Fähigkeit fehlt, sondern weil das strukturelle Design zwei widersprüchliche Verwendungen derselben Zeit verlangt.

Silos zwischen den Tribes

Tribes wurden aus einem sozialpsychologisch begründeten Grund auf etwa 150 Personen ausgelegt. Doch der soziale Zusammenhalt, den Dunbars Zahl innerhalb eines Tribes fördert, kann zwischen Tribes auch ein Wir-und-die-Denken erzeugen. Wenn ein Tribe sich selbst genügt, mit eigenen Squads, eigenen Prioritäten und eigenem Tribe Lead, sinkt der Anreiz, mit anderen Tribes zusammenzuarbeiten.

Guilds sollten diese Lücke überbrücken, aber die Teilnahme an einer Guild ist freiwillig. Wenn Termine drücken, sind Guild-Aktivitäten das Erste, was gestrichen wird. Ohne kräftige Investition in die Koordination zwischen den Tribes wird die Tribe-Grenze zur Informationsmauer.

Was Spotify heute tut

Spotify hat kein Nachfolgemodell mit derselben Klarheit wie das Whitepaper von 2012 veröffentlicht. Bekannt ist, dass sich das Unternehmen zu einer flexibleren, weniger etikettierten Struktur bewegt hat. Die Sprache von Squads und Tribes hält sich in manchen Bereichen, ist aber nicht mehr der prägende organisationale Rahmen. Das Unternehmen experimentiert weiter damit, wie es Arbeit organisiert, was ironischerweise genau das ist, was das ursprüngliche Whitepaper empfahl.

Wo das Spotify Model funktioniert (und wo nicht)

Wo es funktioniert

Produktorientierte Technologieunternehmen mit 50 bis 500 Entwickelnden. Das ist der Sweetspot. Das Modell wurde für eine Produktentwicklungsorganisation in etwa dieser Grösse entworfen, und seine Mechanismen (Autonomie der Squads, Koordination auf Tribe-Ebene, technische Abstimmung über Chapters) passen gut in diesen Kontext. Unternehmen, die Softwareprodukte mit mehreren Funktionsbereichen und bereichsübergreifenden Teams bauen, finden das Modell intuitiv.

Organisationen mit starker Entwicklungskultur. Das Modell hängt an kulturellen Normen, die sich nicht verordnen lassen: Vertrauen, Autonomie, psychologische Sicherheit und die Bereitschaft, Teams Fehler machen zu lassen. Organisationen, in denen Entwickelnde Selbststeuerung gewohnt sind und in denen Führung dienend praktiziert wird, tun sich mit der Einführung leichter.

Unternehmen, die bereit sind anzupassen statt zu kopieren. Die Organisationen, die mit dem Spotify Model erfolgreich sind, behandeln es als Ausgangsvokabular und nicht als starren Bauplan. Sie übernehmen die strukturellen Konzepte, stimmen die Details auf ihren Kontext ab und entwickeln das Modell weiter, während sie lernen. Die niederländische Bankengruppe ING übernahm bekanntlich ein vom Spotify Model inspiriertes Modell, passte es aber deutlich an ein reguliertes Finanzdienstleistungsumfeld an.

Wo es sich schwertut

Kontexte ausserhalb der Technologie. Das Modell wurde für die Softwareentwicklung entworfen. Seine Annahmen (bereichsübergreifende Lieferteams, iterative Entwicklung, häufige Releases, technische Autonomie) lassen sich nicht sauber auf Produktion, Logistik, Gesundheitswesen oder andere Bereiche übertragen, in denen Arbeit sequenziell, physisch oder stark reguliert ist. Eine Pflegestation in “Squad” umzubenennen macht sie in keiner sinnvollen Hinsicht autonom.

Organisationen ohne Autonomiekultur. Das Spotify Model in einer Organisation einzuführen, in der Entscheidungen derzeit von Vorgesetzten getroffen und die Umsetzung von oben gesteuert wird, verlangt eine kulturelle Transformation, die das Modell selbst nicht liefert. Die Struktur setzt die Kultur voraus. Fehlt sie, wird die Struktur zur Fassade: Squads dem Namen nach, Befehl und Kontrolle in der Praxis.

Stark regulierte Branchen. Compliance-Anforderungen in Pharma, Finanzwesen und Luftfahrt verlangen oft dokumentierte Freigabeketten, Prüfpfade und standardisierte Prozesse. Autonomie auf Squad-Ebene bei der Wahl von Werkzeugen, Ansätzen und Architekturen kann mit regulatorischen Vorgaben kollidieren, die Einheitlichkeit und Nachvollziehbarkeit verlangen.

Sehr grosse Organisationen (1000+ Entwickelnde). Das Modell skaliert über Tribes, aber jenseits von 5 bis 10 Tribes wird die Koordination zwischen ihnen zur ernsten Herausforderung. Das Modell schreibt oberhalb der Tribe-Ebene keine Struktur vor. Organisationen dieser Grösse brauchen häufig zusätzliche Koordinationsebenen, was sie in Richtung von Frameworks wie SAFe, LeSS oder eigener Mischformen drängt.

Das Prinzip der Anpassung

Die wichtigste Erkenntnis ist zugleich die einfachste: Nimm, was funktioniert, lass, was nicht funktioniert. Das Spotify Model ist kein Komplettpaket. Du kannst Squads ohne Tribes übernehmen. Du kannst Chapters ohne Guilds nutzen. Du kannst dich am Prinzip Autonomie mit Ausrichtung orientieren, ohne irgendetwas zu etikettieren. Der Wert liegt in den Ideen, nicht in den Etiketten.

Häufige Fehler bei der Einführung

Aus der Beobachtung vieler Einführungen des Spotify Model kehren einige Fehlermuster mit auffälliger Regelmässigkeit wieder.

Fehler 1: Eine Beschreibung als Vorschrift behandeln

Das Whitepaper beschrieb, wie Spotify arbeitete. Es empfahl anderen Unternehmen nicht, genauso zu arbeiten. Ein beschreibendes Dokument als vorschreibendes Framework zu behandeln (“Wir haben ab jetzt Squads, Tribes, Chapters und Guilds”) geht am Kern vorbei. Die konkreten strukturellen Entscheidungen von Spotify waren auf Spotifys Kontext, Grösse, Produkt und Kultur zugeschnitten.

Die Korrektur: Nutze das Modell als Inspiration und Vokabular. Frage, welche Probleme in deiner Organisation die Bestandteile des Modells adressieren. Übernimm die Teile, die deine Probleme lösen. Lass den Rest.

Fehler 2: Struktur ohne Kultur kopieren

Das ist der häufigste und schädlichste Fehler. Organisationen benennen Teams in Squads um, gruppieren sie zu Tribes, ernennen Chapter Leads und Tribe Leads, und nichts ändert sich. Menschen warten weiterhin auf die Freigabe ihrer Vorgesetzten. Squads eskalieren Entscheidungen weiterhin nach oben. Chapter-Treffen finden statt, bringen aber keinen Wert.

Die Struktur ist ein Gefäss. Die Kultur ist, was hineinkommt. Autonomie, Vertrauen, psychologische Sicherheit, Transparenz und ein Hang zum Handeln sind keine strukturellen Eigenschaften, sondern Verhaltensweisen. Du kannst sie nicht installieren, indem du das Organigramm umbaust.

Fehler 3: Die Spannung im Chapter Lead ignorieren

Die Doppelrolle des Chapter Lead (teils Squad-Mitglied, teils Führungskraft) ist eine bekannte Schwäche des Modells. Organisationen, die das Modell übernehmen, ohne diese Spannung ausdrücklich zu adressieren, produzieren Chapter Leads, die ausbrennen, in einer oder beiden Rollen zu wenig leisten oder die Squad-Arbeit still aufgeben, um sich auf die Führung zu konzentrieren.

Manche Organisationen lösen das, indem sie Chapter Lead zu einer Vollzeit-Führungsrolle machen (und dabei die Verbindung zur täglichen Arbeit opfern). Andere teilen die Aufgaben zwischen einer technischen Leitung und einer Führungskraft auf. Wieder andere verringern die Führungslast, indem sie Laufbahngespräche an HR-Partner verlagern. Jeder Ansatz hat Nachteile, aber die Spannung zu ignorieren ist keine Option.

Fehler 4: Es Nicht-Produktteams aufzwingen

Unterstützende Funktionen (HR, Finanzen, Recht, Infrastruktur) passen nicht von selbst ins Squad-Modell. Ihre Arbeit ist oft reaktiv, querschnittlich und prozessorientiert statt funktionsorientiert. Diese Teams in Squads zu zwingen, erzeugt künstliche Grenzen und unnötigen Aufwand.

Manche Organisationen nehmen unterstützende Funktionen ganz vom Spotify Model aus und belassen sie in einer klassischeren Struktur. Andere bilden innerhalb dieser Funktionen serviceorientierte Squads, geordnet nach den Anfragetypen, die sie bearbeiten. Beide Wege sind gangbar. Der Fehler liegt darin, darauf zu beharren, dass jedes Team ein Squad sein muss.

Fehler 5: Das Modell nicht weiterentwickeln

Das ursprüngliche Whitepaper war eine Momentaufnahme. Spotify veränderte sich weiter. Organisationen, die das Modell übernehmen und dann einfrieren, die die erste Umsetzung als dauerhaft behandeln, verstossen gegen genau jenes Prinzip der ständigen Verbesserung, für das das Modell steht.

Baue regelmässige Retrospektiven auf struktureller Ebene ein. Frage: Stimmen die Tribe-Grenzen noch? Bringen die Chapters Wert? Sind die Guilds aktiv oder eingeschlafen? Sind die Squads wirklich autonom? Das Modell sollte sich mit der Organisation weiterentwickeln.

Wie du das Spotify Model für deine Organisation zum Funktionieren bringst

Wenn du dich entscheidest, aus dem Spotify Model zu schöpfen, hier ein praktisches Vorgehen, das die häufigsten Fallstricke umgeht.

Fang mit Squads an

Der Squad ist die stärkste Idee des Modells: ein kleines, bereichsübergreifendes Team mit klarer Mission und der Autonomie, sie einzulösen. Fang hier an. Bestimme einen Produktbereich, stelle einen Squad mit den nötigen Fähigkeiten zusammen, gib ihm eine klare Mission und Entscheidungsbefugnis, und schau, was passiert. Du brauchst weder Tribes noch Chapters noch Guilds, um das Kernkonzept zu testen.

Ziehe Tribe-Grenzen entlang von Produktbereichen

Wenn du über 3 bis 4 Squads hinauswächst, ergibt eine Gruppierung Sinn. Ziehe Tribe-Grenzen entlang von Produktbereichen, Kundensegmenten oder Plattformebenen, also entlang dessen, was zwischen den Squads innerhalb der Grenze natürlichen Abstimmungsbedarf erzeugt. Widerstehe der Versuchung, Tribes nach organisationaler Politik zu bilden. Die Grenze sollte Arbeitsabhängigkeiten spiegeln, nicht Berichtsbeziehungen.

Halte Tribes unter 150 Personen. Wächst ein Tribe darüber hinaus, teile ihn. Die sozialen Dynamiken, die Koordination auf Tribe-Ebene tragen, hängen daran, dass die Menschen einander kennen.

Löse das Chapter-Lead-Dilemma bewusst

Nimm die Rolle des Chapter Lead nicht so hin, wie das Whitepaper sie beschreibt, ohne sie an deinen Kontext anzupassen. Die Aufteilung in halb Squad-Mitglied, halb Führungskraft funktioniert in der Praxis schlecht. Wähle eine dieser Alternativen:

• Chapter Lead in Vollzeit: Der Chapter Lead konzentriert sich ganz auf Personalführung und technische Leitung. Er nimmt an Squad-Standups und -Reviews teil, trägt aber keine Squad-Arbeitslast.
• Aufgeteilte Rollen: Trenne die technische Leitung (eine erfahrene Person pro Squad) von der Personalführung (eine Engineering-Führungskraft für mehrere Squads).
• Rotierender Chapter Lead: Die Rolle wandert unter den erfahrenen Mitgliedern, verteilt so die Last und baut Führungskompetenz auf.

Was auch immer du wählst, triff die Entscheidung bewusst und ausdrücklich.

Nutze Guilds, um Silos zwischen Tribes zu verhindern

Investiere von Anfang an in Guilds. Warte nicht, bis Silos entstehen. Räume Zeit für Guild-Aktivitäten ein. Unterstütze die Guild Coordinators sichtbar. Mach die Ergebnisse der Guilds (technische Leitlinien, gemeinsame Werkzeuge, Dokumentation) sichtbar und wertgeschätzt.

Guilds funktionieren nur, wenn die Organisation die Teilnahme wirklich schätzt und nicht bloss duldet. Wenn Guild-Aktivitäten das Erste sind, was bei einem nahenden Termin abgesagt wird, ist die Botschaft klar: Querbestäubung ist optional. Das sollte sie nicht sein.

Mach die Struktur sichtbar

Jedes Organisationsmodell funktioniert nur, wenn die Menschen es sehen können. Wenn du dich in Squads, Tribes, Chapters und Guilds organisierst, ist die entstehende Struktur komplexer als eine klassische Hierarchie. Die Menschen müssen verstehen, zu welchem Squad sie gehören, zu welchem Tribe ihr Squad zählt, wer ihr Chapter Lead ist und welche Guilds es gibt.

Hier werden Organisationskarten unverzichtbar. Eine lebendige Karte, kein statisches Diagramm in einem Foliensatz, die den aktuellen Stand von Squads, Tribes, Chapters und Guilds zeigt, gibt allen einen gemeinsamen Bezugspunkt. Sie macht die Struktur begehbar statt abstrakt. Werkzeuge wie Peerdom sind genau dafür gebaut: Organisationsstrukturen sichtbar, durchsuchbar und aktuell zu halten, unabhängig davon, welches Modell du nutzt.

Entwickle es weiter

Setze einen Takt für strukturelle Retrospektiven. Quartalsweise ist ein guter Ausgangspunkt. Prüfe, ob die Tribe-Grenzen noch abbilden, wie die Arbeit tatsächlich fliesst. Schätze ein, ob Chapters Wert bringen oder nur Meetings. Schau, ob die Guilds aktiv sind. Frag die Squads, ob sie sich wirklich autonom fühlen.

Der ganze Punkt des Spotify Model ist, dass es nie dauerhaft sein sollte. Seine beste Version ist die, die du an deinen Kontext angepasst hast und weiter verfeinerst.

Häufige Fragen

Nutzt Spotify das Spotify Model noch?

Nicht in seiner ursprünglichen Form. Spotify hat seine Organisationsstruktur seit dem Whitepaper von 2012 deutlich weiterentwickelt. Ein Teil des Vokabulars hält sich (Squads und Tribes werden weiterhin genannt), aber die konkreten Strukturen und Praktiken aus dem Whitepaper bestimmen nicht mehr, wie das Unternehmen arbeitet. Jeremiah Lees Kritik von 2020 und Aussagen von Spotify-Entwickelnden bestätigen, dass das Unternehmen sich vom ursprünglich beschriebenen Modell entfernt hat. Das ist kein Scheitern, sondern deckt sich mit dem eigenen Prinzip des Modells, sich ständig weiterzuentwickeln.

Was ist der Unterschied zwischen einem Chapter und einer Guild?

Ein Chapter ist eine Gruppe von Menschen mit demselben Fähigkeitsprofil innerhalb desselben Tribes (zum Beispiel alle Backend-Entwickelnden in Tribe A). Es hat einen formalen Chapter Lead, der als Führungskraft fungiert. Die Mitgliedschaft ist verpflichtend: Wenn du Backend-Entwickler in Tribe A bist, bist du im Backend-Chapter. Eine Guild ist eine tribeübergreifende Interessengemeinschaft (zum Beispiel alle im ganzen Unternehmen, die sich für Testpraktiken interessieren). Die Mitgliedschaft in einer Guild ist freiwillig, und die Guild Coordinators haben keine Führungsbefugnis. Chapters dienen der technischen Abstimmung und der Personalführung. Guilds dienen dem Wissensaustausch und der Querbestäubung.

Wie gross sollte ein Squad sein?

Das Whitepaper schlug 6 bis 12 Personen vor. Dieser Bereich folgt der allgemeinen Forschung zu wirksamen Teamgrössen: gross genug, um die für eine durchgängige Lieferung nötigen Fähigkeiten zu enthalten, klein genug, damit sich alle kennen, direkt kommunizieren und gemeinsamen Kontext halten können. Unter 6 fehlen womöglich nötige Fähigkeiten. Über 12 beginnt der Koordinationsaufwand die Vorteile eines kleinen Teams aufzuzehren.

Können Unternehmen ausserhalb der Tech-Branche das Spotify Model nutzen?

Die strukturellen Konzepte (autonome bereichsübergreifende Teams, Gruppierungen zur Koordination, Communities of Practice für den Wissensaustausch) sind breit anwendbar. Die konkrete Umsetzung im Whitepaper war aber für die Softwareentwicklung gedacht, wo iteratives Liefern, technische Autonomie und häufige Releases die Norm sind. Unternehmen ausserhalb der Tech-Branche können aus den Prinzipien schöpfen, besonders aus Autonomie mit Ausrichtung und der bereichsübergreifenden Teamstruktur, sollten aber mit erheblichem Anpassungsbedarf rechnen. Für Organisationen ausserhalb der Technologie passen Modelle wie Sociocracy, Beta Codex oder das Buurtzorg-Modell womöglich besser.

Wie verhält sich das Spotify Model zu SAFe?

SAFe (Scaled Agile Framework) ist ein umfassendes, vorschreibendes Framework mit definierten Rollen, Zeremonien und Planungsereignissen auf Team-, Programm- und Portfolioebene. Das Spotify Model ist eine Sammlung struktureller Konzepte mit minimal vorgegebenem Prozess. SAFe funktioniert gut für grosse Organisationen, die Prozessstrenge, Nachvollziehbarkeit für Compliance und teamübergreifende Synchronisation brauchen. Das Spotify Model funktioniert besser für Organisationen mit starker Entwicklungskultur, die strukturelle Orientierung ohne schweren Prozess wollen. Beides schliesst sich nicht aus; manche Organisationen kombinieren den Planungstakt von SAFe mit Teamstrukturen nach Spotify-Art.

Was ist die Rolle eines Tribe Lead?

Der Tribe Lead schafft das Umfeld, in dem Squads erfolgreich sein können. Er führt weder einzelne Squads noch trifft er Produktentscheidungen für sie. Zu seinen Aufgaben gehören: Hindernisse beseitigen, die Squads nicht selbst lösen können, die Koordination zwischen den Squads im Tribe erleichtern, die Ausrichtung an der übergeordneten Richtung der Organisation sicherstellen und die Bedürfnisse des Tribes gegenüber anderen Teilen der Organisation vertreten. Ein Tribe Lead ist eher dienende Führungskraft als klassische Vorgesetzte.

Wie stimmen sich Squads über Tribes hinweg ab?

Die Koordination zwischen Tribes ist eine der schwächeren Stellen des Modells. Die wichtigsten Mechanismen sind Guilds (freiwillige Gemeinschaften, die Wissen über Tribe-Grenzen hinweg teilen) und informelle Kommunikation. Manche Organisationen ergänzen ausdrückliche Rollen für die Koordination zwischen Tribes, regelmässige tribeübergreifende Abstimmungen oder Architekturgremien. Andere setzen auf gemeinsame Plattformteams, die mehrere Tribes bedienen. Welcher Weg richtig ist, hängt davon ab, wie eng die Arbeit über die Tribes hinweg tatsächlich verzahnt ist.

Wie geht das Spotify Model mit rollenbasierter Governance um?

Das Spotify Model schreibt keinen formalen Governance-Prozess vor. Rollen innerhalb der Squads (Product Owner, Entwickelnde, Design) sind vom Modell definiert, aber wie diese Rollen entstehen, sich verändern oder aufgelöst werden, bleibt jedem Squad und Tribe überlassen. Organisationen, die explizite rollenbasierte Governance wollen, können sie über das Spotify Model legen und holakratische oder soziokratische Governance-Prozesse innerhalb der Squad- und Chapter-Struktur nutzen.

Beginne, deine Organisation zu kartieren

Ob du das Spotify Model übernimmst, ein paar seiner Ideen anpasst oder einen ganz anderen Ansatz erkundest: Der erste Schritt ist derselbe. Mach deine aktuelle Struktur sichtbar. Bilde deine Teams, Rollen und Beziehungen ab, damit alle dasselbe Verständnis davon haben, wie die Organisation tatsächlich arbeitet.

• Kartiere kostenlos los: Peerdom unterstützt das Spotify Model, Holacracy, Sociocracy, RenDanHeYi, Beta Codex, DSO und jedes Mischmodell. Bilde deine Squads, Tribes, Chapters und Guilds ab, oder deine Kreise, Zellen und Teams, alles auf einer Plattform.
• Vorlagen durchstöbern: Erkunde fertige Strukturen für verschiedene Organisationsmodelle.
• Den Leitfaden zu Software für Selbstorganisation lesen: Vergleiche Werkzeuge für Organisationen, die mit verteilter Autorität arbeiten.
• Unsicher, wo du anfangen sollst? Buche eine Demo, und wir gehen gemeinsam durch, wie sich die Struktur deiner Organisation auf das Modell abbildet, das dich interessiert.