Het Spotify-model: squads, tribes en guilds uitgelegd

In 2012 publiceerden twee agile coaches bij Spotify een korte whitepaper over hoe het bedrijf zijn engineeringteams organiseerde. Het was geen manifest. Het was geen methode. Het was een momentopname, een beschrijving van hoe één bedrijf op één bepaald moment toevallig werkte. De auteurs zeiden dat er met zoveel woorden bij.

Binnen een paar jaar hadden duizenden organisaties het overgenomen als voorschrijvend kader. Ze doopten hun teams om tot “squads”, groepeerden die in “tribes”, richtten “chapters” en “guilds” op en gingen ervan uit dat de resultaten vanzelf zouden volgen. Velen ontdekten dat een organisatiestructuur kopiëren zonder de cultuur erachter te begrijpen weinig meer oplevert dan nieuwe woorden voor oude problemen.

De diepere ironie: Spotify zelf ging verder. De eigen engineers van het bedrijf hebben publiekelijk erkend dat het model uit de whitepaper niet langer weergeeft hoe Spotify werkt. Toch blijft het “Spotify-model” een van de meest besproken benaderingen om agile organisaties op te schalen, juist omdat de ideeën in de kern echte problemen adresseren waar elk groeiend bedrijf mee te maken krijgt.

Deze gids legt uit wat het Spotify-model werkelijk beschreef, hoe de vier bouwstenen werken, waarom het zich zo ver verspreidde, waar het spaak loopt en hoe je de principes kunt aanpassen zonder in de bekendste valkuilen te stappen.

Wat is het Spotify-model?

Het Spotify-model komt uit een whitepaper uit 2012 met de titel “Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds”, geschreven door Henrik Kniberg en Anders Ivarsson. Kniberg was een agile coach die met Spotify werkte; Ivarsson was de organisatiecoach van het bedrijf. Het stuk, dat vergezeld ging van een tweedelige videoreeks, beschreef hoe Spotify destijds zijn ongeveer 30 engineeringteams organiseerde, zo’n 250 mensen verspreid over drie steden.

Het belangrijkste om over die whitepaper te begrijpen is wat het níét was. Het was geen kader om over te nemen. Het was geen set praktijken om te volgen. De auteurs beschreven zorgvuldig wat Spotify op dat specifieke moment deed, niet wat andere bedrijven zouden moeten doen. Kniberg heeft dat onderscheid herhaaldelijk benadrukt: wat zij beschreven was de werkwijze van Spotify, geen model dat iedereen past.

De whitepaper beschreef een aantal organisatiestructuren (squads, tribes, chapters en guilds) die één specifiek probleem moesten oplossen: hoe houd je de snelheid en de autonomie van kleine teams overeind terwijl je opschaalt naar honderden engineers die aan één gedeeld product werken? Het was de spanning tussen autonomie en afstemming, vertaald naar structuur.

Wat er daarna gebeurde, was voorspelbaar. De whitepaper was helder, goed geïllustreerd en ging over een probleem waar honderden groeiende techbedrijven mee worstelden. Het verspreidde zich razendsnel door de agile gemeenschap. Congresverhalen verwezen ernaar. Blogposts legden het uit. Adviesbureaus verpakten het. Binnen een paar jaar was “het Spotify-model” een erkend organisatiepatroon: overgenomen, aangepast en soms integraal opgelegd aan organisaties met totaal andere culturen, groottes en uitdagingen.

De kloof tussen wat Kniberg en Ivarsson beschreven en hoe de branche het ontving, is de bepalende spanning in het verhaal van het Spotify-model: een beschrijvende momentopname die als voorschrijvende blauwdruk werd behandeld.

De vier bouwstenen

Het Spotify-model brengt mensen onder in vier overlappende structuren, die elk een ander coördinatieprobleem oplossen. Begrijpen hoe die vier zich tot elkaar verhouden is essentieel; het zijn geen losse afdelingen, maar elkaar snijdende lagen van een matrix.

Squads

De squad is de basiseenheid. Een squad is een klein, multidisciplinair team van 6 tot 12 mensen met verantwoordelijkheid van begin tot eind voor een specifiek functiegebied, productonderdeel of gebruikersreis. Elke squad werkt als een mini-start-up: hij heeft een eigen missie, bepaalt zijn eigen werkwijze en beheert zijn eigen backlog.

In een squad zitten doorgaans alle vaardigheden die nodig zijn om het werk te ontwerpen, te bouwen, te testen en uit te brengen: ontwikkelaars, een ontwerper, een Product Owner en een QA-specialist. De squad hoeft het werk niet over te dragen aan een ander team om iets af te krijgen. Dat is bewust zo: de multidisciplinaire samenstelling schrapt overdrachtsmomenten, vermindert afhankelijkheden en geeft de squad autonomie over wat hij oplevert.

De Product Owner bepaalt wat de squad bouwt en in welke volgorde. De squad zelf bepaalt hoe hij het bouwt. Het Spotify-model schrijft geen formele rol van Scrum Master voor, al kiezen veel squads er wel een. De squad kiest zijn eigen agile methode: Scrum, Kanban, een mengvorm of iets heel anders.

Autonomie is het bepalende kenmerk. Squads krijgen het vertrouwen om hun eigen technische keuzes te maken, hun eigen werk te beheren en zelfstandig op te leveren. Dat vertrouwen is niet onvoorwaardelijk (het hangt af van afstemming met de bredere productrichting), maar autonomie is het uitgangspunt, waarbij coördinatie ontstaat uit cultuur en gedeelde doelen in plaats van uit sturing van bovenaf.

Tribes

Een tribe is een verzameling squads die aan een verwant productgebied werken. Zijn de squads de mini-start-ups, dan is de tribe de broedplaats. Tribes tellen doorgaans tussen de 40 en 150 mensen. Die bovengrens is bewust gekozen en steunt op het onderzoek van Robin Dunbar, dat suggereert dat mensen stabiele sociale relaties kunnen onderhouden met ongeveer 150 anderen. Boven dat aantal begint coördinatie op basis van vertrouwen te haperen en worden geformaliseerde processen nodig.

Elke tribe heeft een Tribe Lead die verantwoordelijk is voor een productieve omgeving voor de squads. De Tribe Lead stuurt geen individuele squads aan en neemt hun beslissingen niet over. Zijn taak is obstakels wegnemen, de coördinatie tussen squads faciliteren en zorgen dat alles aansluit op de bredere richting van de organisatie.

Tribes zorgen voor fysieke en sociale nabijheid. In het oorspronkelijke Spotify-model zaten de squads binnen dezelfde tribe bij elkaar, deelden ze gemeenschappelijke ruimtes en kwamen ze regelmatig als hele tribe samen. Die nabijheid is geen toeval; het is een bewust mechanisme voor informele coördinatie. Als mensen in dezelfde ruimte werken, vangen ze gesprekken op, lopen ze elkaar tegen het lijf bij het koffiezetapparaat en delen ze context zonder dat er een vergadering voor nodig is.

De grens van de tribe bakent een coördinatieruimte af. Squads binnen dezelfde tribe stemmen vaak en informeel af. Squads in verschillende tribes stemmen minder vaak en bewuster af. Daardoor ontstaat een natuurlijke spanning: goed getrokken tribegrenzen verminderen interne wrijving; slecht getrokken grenzen creëren silo’s.

Chapters

Chapters lossen het competentieprobleem op dat squads veroorzaken. Zodra je mensen in multidisciplinaire squads onderbrengt, raken specialisten verspreid. Je iOS-ontwikkelaars zitten uitgesmeerd over tien verschillende squads, elk bezig met een andere functionaliteit. Wie zorgt ervoor dat ze dezelfde technische standaarden aanhouden? Wie coacht hen vakinhoudelijk? Wie regelt loopbaanontwikkeling en salarisgesprekken?

Een chapter is een groep mensen met dezelfde vaardigheden die binnen dezelfde tribe werken, maar in verschillende squads. Alle backendontwikkelaars in een tribe vormen samen een chapter. Alle ontwerpers vormen er een. Alle testers weer een. Elke chapter heeft een Chapter Lead, en dit is waar het model zijn grootste structurele spanning introduceert.

De Chapter Lead is de formele leidinggevende van de chapterleden. Hij voert de beoordelingsgesprekken, begeleidt de loopbaanontwikkeling en voert de salarisgesprekken. Maar de Chapter Lead werkt daarnaast gewoon mee in een squad, met de handen in het werk, náást zijn taken als leidinggevende. Die dubbelrol is bewust gekozen: ze houdt de Chapter Lead verbonden met de dagelijkse werkelijkheid van het werk. Ze betekent ook dat hij twee banen draagt.

Chapters komen regelmatig bijeen om kennis te delen, technische praktijken op elkaar af te stemmen, keuzes rond gereedschap te bespreken en zaken aan te pakken die meerdere squads raken. Ze zijn het mechanisme waarmee technische consistentie en vakinhoudelijke groei over de grenzen van squads heen tot stand komen.

Guilds

Guilds trekken het idee van een community of practice over de grenzen van tribes heen. Een guild is een vrijwillige groep die tribes overstijgt en waarvan de leden een interesse, vaardigheid of kennisgebied delen. Anders dan bij chapters staan guilds open voor iedereen. Je hoeft geen backendontwikkelaar te zijn om lid te worden van de backend guild. Je hoeft er alleen belangstelling voor te hebben.

Elke guild heeft een Guild Coordinator die de activiteiten faciliteert (meetups, workshops, gedeelde kanalen, documentatie), maar geen formeel gezag heeft. Lidmaatschap is vrijwillig, deelname bepaal je zelf, en de guild bestaat alleen zolang hij waarde oplevert voor zijn leden.

Guilds zijn het tegengif tegen silo’s per tribe. Als tribes groot en zelfvoorzienend zijn, kan kennis binnen de tribegrenzen opgesloten raken. Guilds creëren kanalen voor kruisbestuiving: een testing guild deelt automatiseringspraktijken over alle tribes heen; een webdevelopment guild stemt frontendstandaarden bedrijfsbreed af; een leadership guild deelt managementpraktijken door de hele organisatie.

Hoe de vier structuren elkaar snijden

De vier structuren vormen een matrix, maar wel een matrix met een duidelijke hoofdas. De squad is de belangrijkste organisatorische eenheid. Daar gebeurt het werk, daar brengen mensen het grootste deel van hun tijd door en daar vallen de dagelijkse beslissingen.

Tribes groeperen squads voor coördinatie. Chapters groeperen specialisten voor competentie. Guilds groeperen liefhebbers voor kennisdeling.

Elke engineer hoort bij precies één squad en één chapter. Daarnaast kan hij bij een of meer guilds horen. Dat betekent dat iedereen twee lijnen heeft: zijn squad (voor het opleveren van product) en zijn chapter (voor personeelszaken en technische standaarden). Dit is de matrixorganisatie zoals het Spotify-model die invult, bedoeld om de voordelen van vakinhoudelijke expertise en multidisciplinaire levering tegelijk te vangen.

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 (omvat Squad 1 + Squad 2)
├── Chapter: Backend Developers (omvat alle squads)
├── Chapter: Designers (omvat alle squads)
└── Chapter: Testers (omvat Squad 1 + Squad 3)

Guild: Web Development (omvat Tribe A + Tribe B + Tribe C)
Guild: Testing Practices (omvat alle tribes)

De kernprincipes achter het model

De structuuronderdelen (squads, tribes, chapters, guilds) zijn het zichtbare deel van het Spotify-model. Maar ze zijn niet wat het bij Spotify liet werken. Wat het liet werken, was een set culturele principes die de structuur moest ondersteunen. Kopieer de structuur zonder die principes en je houdt een hiërarchie in Spotify-vorm over.

Autonomie met afstemming

Dit is de centrale spanning waar het hele model omheen is gebouwd. Squads zijn autonoom: ze kiezen hun eigen methoden, beheren hun eigen werk en maken hun eigen technische keuzes. Maar ze staan niet los. Ze zijn afgestemd op een gedeelde productvisie en een gemeenschappelijke set strategische prioriteiten.

Kniberg beschreef dit als een spectrum. Aan de ene kant veel afstemming en veel autonomie: leiders maken duidelijk welk probleem opgelost moet worden en waarom dat ertoe doet; de squads bedenken hoe. Aan de andere kant weinig afstemming en veel autonomie: squads doen wat ze willen, en het resultaat is een verzameling losse inspanningen. Het doel is om in het kwadrant van veel afstemming én veel autonomie te blijven, waar squads vrij zijn om te bepalen hoe ze werken, maar helder hebben wat de organisatie probeert te bereiken.

Dat vraagt om leiders die richting kunnen geven zonder oplossingen te dicteren. Het vraagt om squads die actief context zoeken over het grotere geheel in plaats van lokaal te optimaliseren. En het vraagt om transparantie in de organisatie, zodat squads zichzelf kunnen afstemmen in plaats van door managers te moeten worden afgestemd.

Cultuur boven proces

Het Spotify-model gaf uitdrukkelijk de voorkeur aan culturele normen boven geformaliseerde processen. Regels bleven minimaal. Vertrouwen was het uitgangspunt. De aanname was dat goede mensen aannemen, hun context geven en erop vertrouwen dat ze redelijke beslissingen nemen betere resultaten oplevert dan uitgebreide procesdocumentatie.

Dat werkte bij Spotify omdat het bedrijf fors had geïnvesteerd in zijn engineeringcultuur. Psychologische veiligheid, open communicatie en ruimte om te experimenteren waren geen slogans; het was geleefd gedrag. Het model is door die cultuur gevormd, niet andersom.

Vertrouwen als uitgangspunt

Squads kregen standaard vertrouwen. Ze hoefden autonomie niet te verdienen met een track record en hoefden hun beslissingen niet bij het management te verantwoorden. De organisatie ging ervan uit dat squads goede beslissingen zouden nemen en dat een enkele misser een aanvaardbare prijs was voor de snelheid die autonomie oplevert.

Dat is lastiger in te voeren dan het klinkt. De meeste organisaties werken vanuit het omgekeerde uitgangspunt: vertrouwen moet worden verdiend en autonomie wordt stukje bij beetje gegeven. Overstappen op vertrouwen als uitgangspunt vraagt van leiders dat ze accepteren dat sommige squads beslissingen nemen waar ze het niet mee eens zijn, en dat ze alleen ingrijpen als de gevolgen groot zijn, niet zodra ze zelf iets anders hadden gekozen.

Kruisbestuiving boven silo’s

Chapters en guilds bestonden juist om het silo-effect te voorkomen dat autonome teams kunnen veroorzaken. Als squads volledig autonoom zijn, lossen ze hetzelfde probleem misschien op drie manieren op, kiezen ze technologieën die niet samengaan, of bouwen ze kennis op die nooit verder komt dan de squad.

Het model pakte dat aan met structuren die dwars door de organisatie sneden: chapters voor technische afstemming binnen tribes, guilds voor kennisdeling over tribes heen. De nadruk lag op organische uitwisseling (gedeelde praktijken, vrijwillige deelname, van elkaar leren) in plaats van op standaarden die van bovenaf worden opgelegd.

Continu verbeteren boven een draaiboek volgen

Het Spotify-model was nooit statisch. De whitepaper beschreef een specifiek moment in de ontwikkeling van het bedrijf. Spotify bleef zijn organisatiestructuur ook daarna aanpassen. Het model was bedoeld als vertrekpunt voor doorlopend experimenteren, niet als eindbestemming.

Dat principe is tegelijk de grootste kracht van het model en de bron van de meest voorkomende verkeerde toepassing. Als het model een uitnodiging is om te experimenteren, dan is het exact kopiëren ervan al een schending van de eigen kernfilosofie.

Het Spotify-model versus andere organisatiekaders

Het Spotify-model staat in een breder landschap van benaderingen van organisatieontwerp. Elk daarvan pakt andere problemen aan, kent een andere mate van formaliteit en past bij een andere context. De vergelijking hieronder verheldert wat het Spotify-model wel en niet biedt ten opzichte van de alternatieven.

Dimensie	Traditionele hiërarchie	Spotify-model	Holacracy	Sociocratie	RenDanHeYi	Beta Codex / Peach	DSO (Bayer)	SAFe	Buurtzorg
Gezagsstructuur	Bevelslijn van boven naar beneden	Autonomie van squads binnen de afstemming van de tribe	Rollen en cirkels bestuurd door een grondwet	Cirkels op basis van consent met dubbele koppeling	Verdeeld over micro-ondernemingen	Gedecentraliseerd, centrum en periferie	Verdeeld over autonome teams	Hiërarchisch met agile lagen	Zelfsturende wijkteams
Basiseenheid	Afdeling / divisie	Squad (6-12, multidisciplinair)	Cirkel met vastgelegde rollen	Cirkel met dubbele koppeling	Micro-onderneming (10-15 mensen)	Autonome cel aan de periferie	Klant- of productteam (6-10)	Agile Release Train	Zelfsturend team (10-12 verpleegkundigen)
Besluitvorming	Goedkeuring door de manager	Autonomie op squadniveau	Integratief besluitvormingsproces	Consent (geen beargumenteerde bezwaren)	Marktgedreven, autonomie van de micro-onderneming	Op meesterschap, aan de periferie	95% op teamniveau	PI Planning plus teambeslissingen	Consensus op teamniveau
Schaalmechanisme	Managementlagen toevoegen	Tribes (max. ~150), chapters, guilds	Geneste cirkels	Geneste cirkels met dubbele koppeling	Ecosystemen van microgemeenschappen	Gefedereerde cellen	Cycli van 90 dagen, VACC-coaching	ARTs, Solution Trains, Portfolio	Regionale coaching plus backoffice
Leiderschapsmodel	Hiërarchische managers	Tribe leads, chapter leads	Lead links en rep links	Facilitatoren en afgevaardigden	”Iedereen is zijn eigen CEO”	Verdeeld, op meesterschap	VACC (Visionaries, Architects, Catalysts, Coaches)	RTE, System Architect, Product Management	Coach (geen manager)
Formaliteit	Hoog (beleid, procedures)	Laag tot gemiddeld (cultuurgedreven)	Zeer hoog (geschreven grondwet)	Gemiddeld (op principes gebaseerd)	Gemiddeld (marktdiscipline)	Laag (netwerkprincipes)	Gemiddeld (VACC plus de structuur van 90 dagen)	Zeer hoog (het SAFe-kader)	Laag (op principes gebaseerd)
Past het best bij	Stabiele omgevingen, veel compliance	Productgerichte techbedrijven, 50-500 engineers	Organisaties die expliciete governance willen	Organisaties die inclusieve besluitvorming vooropstellen	Grote ondernemingen die ondernemende snelheid zoeken	Marktgerichte organisaties die willen decentraliseren	Grote ondernemingen die bureaucratie afbouwen	Grote ondernemingen die agile levering opschalen	Zorg- en dienstverlenende organisaties
Beproefd op schaal	Elke schaal	Honderden tot enkele duizenden	Honderden tot enkele duizenden	Honderden tot enkele duizenden	80.000+ medewerkers	Wisselend	100.000+ (in uitvoering)	Tienduizenden	15.000+ professionals

Belangrijkste verschillen

Spotify-model versus SAFe: SAFe (Scaled Agile Framework) is voorschrijvend waar het Spotify-model beschrijvend is. SAFe levert gedetailleerde ceremonies, rollen en planningsevenementen op elk niveau van de organisatie. Het Spotify-model levert structurele begrippen en vertrouwt erop dat teams de details invullen. SAFe werkt goed voor organisaties die procesdiscipline en traceerbaarheid voor compliance nodig hebben. Het Spotify-model werkt beter voor organisaties met een sterke engineeringcultuur die zich verzet tegen zware processen. Veel organisaties gebruiken elementen van allebei.

Spotify-model versus holacracy: Holacracy biedt een formele grondwet voor governance met expliciete regels voor hoe rollen ontstaan, hoe beslissingen worden genomen en hoe vergaderingen verlopen. Het Spotify-model heeft geen grondwet. De governance is cultureel, niet procedureel. Organisaties die duidelijke, gedocumenteerde governanceprocessen willen, vinden holacracy gestructureerder. Organisaties die culturele normen verkiezen boven formele regels, vinden het Spotify-model natuurlijker.

Spotify-model versus sociocratie: Sociocratie draait om besluitvorming op basis van consent en om dubbele koppelingen tussen governancelagen. Het Spotify-model schrijft geen besluitvormingsproces voor; squads bepalen zelf hoe ze beslissen. Sociocratie past beter bij organisaties die op alle niveaus gestructureerde governance willen. Het Spotify-model past beter bij productengineering, waar snelheid van leveren zwaarder weegt dan formele governance.

Spotify-model versus RenDanHeYi: RenDanHeYi bij Haier drijft autonomie verder door dan het Spotify-model. Elke micro-onderneming draagt volledige winst-en-verliesverantwoordelijkheid en neemt haar eigen mensen aan. De squads van Spotify zijn autonoom in hoe ze werken, maar niet in hoe ze worden bemenst of gefinancierd. RenDanHeYi is ontworpen voor marktgedreven ondernemingen waarin elke eenheid rechtstreeks in verbinding staat met klanten. Het Spotify-model is ontworpen voor productengineeringorganisaties waarin squads bijdragen aan één gedeeld product.

Spotify-model versus Beta Codex: Beta Codex opereert op een hoger abstractieniveau. Het formuleert 12 wetten over hoe organisaties zouden moeten zijn opgebouwd, presteren en zich aanpassen, zonder specifieke teamvormen voor te schrijven. Het Spotify-model is concreter: het benoemt specifieke structurele eenheden (squads, tribes, chapters, guilds) met specifieke groottes en verhoudingen. Beta Codex kan een structuur in Spotify-stijl omvatten binnen zijn perifere cellen, maar het gaat over het hele organisatiemodel en niet alleen over productengineering.

Spotify-model versus DSO: Dynamic Shared Ownership bij Bayer deelt de nadruk van het Spotify-model op autonome teams, maar voegt een gestructureerd planningsritme toe (cycli van 90 dagen) en een expliciet leiderschapskader (VACC). DSO is vanaf het begin ontworpen voor ondernemingsschaal; het Spotify-model ontstond in een middelgrote engineeringorganisatie en loopt op grotere schaal tegen problemen aan.

Waarom Spotify verder is gegaan

Begrijpen waarom Spotify zijn eigen model ontgroeide is essentiële context voor iedereen die overweegt het over te nemen. Het model was een momentopname, en de organisatie die het beschreef bleef veranderen.

De kritiek van Jeremiah Lee

In 2020 publiceerde Jeremiah Lee, een voormalig medewerker van Spotify, een veelgelezen kritiek onder de titel “Spotify’s Failed Squad Goals”. Lee betoogde dat het model uit de whitepaper zelfs bij Spotify niet had gewerkt zoals bedoeld. Zijn belangrijkste observaties:

• Autonome squads veroorzaakten coördinatieproblemen. Toen squads zelfstandig hun eigen gereedschap, architectuur en aanpak kozen, was het resultaat versnippering: inconsistente codebases, dubbel werk en integratiehoofdpijn.
• De chapterstructuur maakte haar belofte niet waar. Chapter Leads werden heen en weer getrokken tussen hun werk in de squad en hun rol als leidinggevende, en chaptervergaderingen voelden vaak als bijzaak.
• Tribegrenzen werden silo’s. Tribes, bedoeld om gerichte coördinatie te scheppen, wierpen ook muren op. Samenwerken over tribes heen bleek moeilijker dan het model voorzag.
• De cultuur die het liet werken was niet overdraagbaar. Spotify had een specifieke engineeringcultuur (veel vertrouwen, sterke normen rond autonomie, tolerantie voor rommeligheid) die het model vormde. Andere bedrijven namen de structuur over zonder die cultuur en kregen andere resultaten.

Lee’s kritiek raakte een snaar omdat ze verwoordde wat veel bedrijven hadden ervaren: het Spotify-model klonk juist, maar voelde niet juist zodra het in een andere context werd ingevoerd.

De matrixval

De rol van Chapter Lead is het structureel meest kwetsbare onderdeel van het model. Een Chapter Lead is tegelijk meewerkend lid van een squad (die bijdraagt aan wat er wordt opgeleverd) en leidinggevende van chapterleden verspreid over meerdere squads (verantwoordelijk voor loopbaanontwikkeling, prestatiefeedback en salarisbeslissingen).

Dat is een rol die in beide richtingen halveert, en dat levert voorspelbare spanning op. In drukke sprintperiodes overheerst het squadwerk en blijven de chaptertaken liggen. Tijdens beoordelingsrondes slokken de managementtaken de tijd op die aan de squad was toegezegd. Chapter Leads die naar het management neigen, raken los van de code. Wie naar de techniek neigt, wordt een matige leidinggevende.

Het resultaat is vaak een Chapter Lead die geen van beide banen goed doet, niet uit gebrek aan kunnen, maar omdat het structurele ontwerp twee tegenstrijdige claims op de tijd van dezelfde persoon legt.

Silo’s per tribe

Tribes werden op ongeveer 150 mensen gehouden om een reden die in de sociale psychologie wortelt. Maar de sociale cohesie die het getal van Dunbar binnen een tribe aanmoedigt, kan tussen tribes ook een wij-zijgevoel opwekken. Als een tribe zelfvoorzienend is, met eigen squads, eigen prioriteiten en een eigen Tribe Lead, neemt de prikkel om met andere tribes samen te werken af.

Guilds moesten die kloof overbruggen, maar deelname aan een guild is vrijwillig. Zodra deadlines knellen, sneuvelen de guildactiviteiten als eerste. Zonder stevige investering in coördinatie tussen tribes wordt de tribegrens een informatiemuur.

Wat Spotify nu doet

Spotify heeft geen opvolger gepubliceerd met dezelfde helderheid als de whitepaper uit 2012. Wat bekend is, is dat het bedrijf naar een flexibelere structuur met minder etiketten is opgeschoven. De taal van squads en tribes leeft op sommige plekken voort, maar is niet langer het bepalende organisatiekader. Het bedrijf blijft experimenteren met hoe het zijn werk organiseert, wat ironisch genoeg precies is wat de oorspronkelijke whitepaper aanraadde.

Waar het Spotify-model werkt (en waar niet)

Waar het werkt

Productgerichte technologiebedrijven met 50 tot 500 engineers. Dit is de gouden zone. Het model is ontworpen voor een productengineeringorganisatie van ongeveer die omvang, en de mechanismen (autonomie van squads, coördinatie op tribeniveau, technische afstemming via chapters) passen goed bij die context. Bedrijven die softwareproducten bouwen met meerdere functiegebieden en multidisciplinaire teams zullen het model vanzelfsprekend vinden.

Organisaties met een sterke engineeringcultuur. Het model leunt op culturele normen die je niet kunt opleggen: vertrouwen, autonomie, psychologische veiligheid en de bereidheid om teams fouten te laten maken. In organisaties waar engineers gewend zijn aan zelfsturing en waar de leiding dienend leiderschap praktiseert, verloopt de invoering soepeler.

Bedrijven die willen aanpassen in plaats van kopiëren. De organisaties die slagen met het Spotify-model behandelen het als een beginwoordenschat, niet als een strak keurslijf. Ze nemen de structurele begrippen over, stemmen de details af op hun context en laten het model meegroeien met wat ze leren. ING, de Nederlandse bankengroep, nam een model naar Spotify-voorbeeld over, maar paste het stevig aan om in een gereguleerde financiële omgeving te passen.

Waar het worstelt

Niet-technologische contexten. Het model is ontworpen voor softwareontwikkeling. De aannames (multidisciplinaire leverteams, iteratieve ontwikkeling, frequente releases, technische autonomie) laten zich niet zomaar vertalen naar productie, logistiek, zorg of andere domeinen waar het werk opeenvolgend, fysiek of streng gereguleerd is. Een verpleegafdeling omdopen tot “squad” maakt haar in geen enkel zinvol opzicht autonoom.

Organisaties zonder autonomiecultuur. Het Spotify-model invoeren in een organisatie waar beslissingen nu door managers worden genomen en de uitvoering van bovenaf wordt aangestuurd, vraagt om een cultuuromslag die het model zelf niet levert. De structuur veronderstelt dat de cultuur er al is. Is dat niet zo, dan wordt de structuur een façade: squads in naam, aansturing en controle in de praktijk.

Streng gereguleerde sectoren. Compliance-eisen in de farmacie, de financiële sector en de luchtvaart vragen vaak om gedocumenteerde goedkeuringsketens, auditsporen en gestandaardiseerde processen. Autonomie op squadniveau in de keuze van gereedschap, aanpak en architectuur kan botsen met regelgeving die consistentie en traceerbaarheid voorschrijft.

Zeer grote organisaties (1.000+ engineers). Het model schaalt via tribes, maar voorbij de 5 tot 10 tribes wordt coördinatie tussen tribes een serieuze uitdaging. Het model schrijft niets voor boven het niveau van de tribe. Organisaties van die omvang hebben vaak extra coördinatielagen nodig, wat ze richting kaders als SAFe of LeSS duwt, of richting eigen mengvormen.

Het aanpassingsprincipe

De belangrijkste les is meteen de eenvoudigste: neem wat werkt, laat de rest liggen. Het Spotify-model is geen alles-of-nietspakket. Je kunt squads invoeren zonder tribes. Je kunt chapters gebruiken zonder guilds. Je kunt putten uit het principe van autonomie met afstemming zonder ergens een etiket op te plakken. De waarde zit in de ideeën, niet in de etiketten.

Veelgemaakte fouten bij invoering

Wie de invoering van het Spotify-model in veel organisaties heeft gezien, ziet een aantal faalpatronen met opvallende regelmaat terugkomen.

Fout 1: een beschrijving als voorschrift behandelen

De whitepaper beschreef hoe Spotify werkte. Ze raadde andere bedrijven niet aan hetzelfde te doen. Een beschrijvend document als voorschrijvend kader behandelen (“We hebben voortaan squads, tribes, chapters en guilds”) mist de kern. De specifieke structuurkeuzes die Spotify maakte, waren toegesneden op de context, de omvang, het product en de cultuur van Spotify.

De oplossing: gebruik het model als inspiratie en als woordenschat. Vraag je af welke problemen in jouw organisatie de onderdelen van het model adresseren. Neem de delen over die jouw problemen oplossen. Laat de rest liggen.

Fout 2: de structuur kopiëren zonder de cultuur

Dit is de meest voorkomende en meest schadelijke fout. Organisaties dopen teams om tot squads, groeperen ze in tribes, benoemen Chapter Leads en Tribe Leads, en er verandert niets. Mensen wachten nog steeds op goedkeuring van hun manager. Squads schalen beslissingen nog steeds op naar boven. Chaptervergaderingen vinden plaats, maar leveren niets op.

De structuur is de verpakking. De cultuur is wat erin zit. Autonomie, vertrouwen, psychologische veiligheid, transparantie en een neiging tot handelen zijn geen structurele eigenschappen; het zijn gedragseigenschappen. Je installeert ze niet door het organogram te herschikken.

Fout 3: de spanning bij de Chapter Lead negeren

De dubbelrol van Chapter Lead (deels squadlid, deels leidinggevende) is een bekende zwakte van het model. Organisaties die het model overnemen zonder die spanning expliciet aan te pakken, krijgen Chapter Leads die opbranden, in een van beide rollen ondermaats presteren of het squadwerk stilletjes laten vallen om zich op het management te richten.

Sommige organisaties lossen dat op door Chapter Lead een voltijdse managementrol te maken (en zo de band met het dagelijkse werk op te geven). Andere splitsen de taken tussen een technisch leider en een leidinggevende. Weer andere verlichten de managementlast door loopbaangesprekken bij HR-partners te beleggen. Elke aanpak heeft zijn nadelen, maar de spanning negeren is geen optie.

Fout 4: het opdringen aan niet-productteams

Ondersteunende functies (HR, finance, juridische zaken, infrastructuur) passen van nature niet in het squadmodel. Hun werk is vaak reactief, dwarsdoorsnijdend en procesgericht in plaats van functiegericht. Die teams in squads persen levert kunstmatige grenzen en onnodige overhead op.

Sommige organisaties houden ondersteunende functies helemaal buiten het Spotify-model en laten ze in een klassiekere structuur werken. Andere vormen binnen die functies dienstgerichte squads, geordend rond de soorten verzoeken die ze afhandelen. Beide aanpakken zijn geldig. De fout is volhouden dat élk team een squad moet zijn.

Fout 5: het model niet laten meegroeien

De oorspronkelijke whitepaper was een momentopname. Spotify bleef veranderen. Organisaties die het model overnemen en het vervolgens bevriezen, alsof de eerste invulling voor altijd geldt, schenden juist het principe van continu verbeteren dat het model belichaamt.

Bouw regelmatige retrospectieven op structuurniveau in. Vraag: kloppen de tribegrenzen nog? Leveren de chapters waarde op? Zijn de guilds actief of slapend? Zijn de squads werkelijk autonoom? Het model hoort mee te bewegen met de organisatie.

Het Spotify-model laten werken voor jouw organisatie

Besluit je uit het Spotify-model te putten, dan is dit een praktische aanpak die de bekendste valkuilen omzeilt.

Begin bij squads

De squad is het sterkste idee van het model: een klein, multidisciplinair team met een heldere missie en de autonomie om die waar te maken. Begin daar. Kies een productgebied, stel een squad samen met de benodigde vaardigheden, geef die een duidelijke missie en beslissingsbevoegdheid, en kijk wat er gebeurt. Je hebt geen tribes, chapters of guilds nodig om het kernidee te beproeven.

Trek tribegrenzen langs productgebieden

Groei je voorbij 3 of 4 squads, dan wordt groeperen zinvol. Trek de tribegrenzen rond productgebieden, klantsegmenten of platformlagen: wat er ook maar natuurlijke coördinatiebehoefte schept tussen de squads binnen die grens. Weersta de verleiding om tribes langs organisatiepolitieke lijnen te vormen. De grens hoort de afhankelijkheden in het werk te volgen, niet de rapportagelijnen.

Houd tribes onder de 150 mensen. Groeit een tribe daarboven, splits hem dan. De sociale dynamiek die coördinatie op tribeniveau laat werken, drijft erop dat mensen elkaar kennen.

Los het dilemma van de Chapter Lead expliciet op

Neem de rol van Chapter Lead niet over zoals de whitepaper hem beschrijft zonder hem aan jouw context aan te passen. De splitsing half squadlid, half leidinggevende werkt in de praktijk slecht. Kies een van deze alternatieven:

• Voltijdse Chapter Lead: de Chapter Lead richt zich volledig op mensen en technisch leiderschap. Hij sluit aan bij standups en reviews van de squad, maar draagt geen squadwerklast.
• Gesplitste rollen: scheid technisch leiderschap (een senior engineer in elke squad) van leidinggeven (een engineering manager voor meerdere squads).
• Rouleren: de rol van Chapter Lead rouleert onder de senior leden, wat de last spreidt en leiderschapsvaardigheden opbouwt.

Wat je ook kiest, maak de keuze bewust en expliciet.

Gebruik guilds om silo’s per tribe te voorkomen

Investeer vanaf het begin in guilds. Wacht niet tot de silo’s er zijn. Reserveer tijd voor guildactiviteiten. Geef Guild Coordinators expliciete steun. Maak wat guilds opleveren (technische richtlijnen, gedeeld gereedschap, documentatie) zichtbaar en gewaardeerd.

Guilds werken alleen als de organisatie deelname echt waardeert en niet slechts toestaat. Als guildactiviteiten het eerste zijn dat sneuvelt zodra een deadline nadert, is de boodschap duidelijk: kruisbestuiving is optioneel. Dat hoort ze niet te zijn.

Maak de structuur zichtbaar

Elk organisatiemodel werkt alleen als mensen het kunnen zien. Organiseer je in squads, tribes, chapters en guilds, dan is de structuur die daaruit volgt ingewikkelder dan een traditionele hiërarchie. Mensen moeten weten bij welke squad ze horen, bij welke tribe hun squad zit, wie hun Chapter Lead is en welke guilds er zijn.

Hier wordt je organisatie in kaart brengen essentieel. Een levende kaart (geen statisch diagram in een presentatie) die de actuele stand van squads, tribes, chapters en guilds toont, geeft iedereen hetzelfde referentiepunt. Ze maakt de structuur doorloopbaar in plaats van abstract. Tools als Peerdom zijn daar precies voor gemaakt: organisatiestructuren zichtbaar, doorzoekbaar en actueel houden, welk model je ook gebruikt.

Laat het meegroeien

Spreek een ritme af voor retrospectieven op structuurniveau. Elk kwartaal is een goed begin. Kijk of de tribegrenzen nog weergeven hoe het werk werkelijk stroomt. Beoordeel of chapters waarde toevoegen of alleen vergaderingen. Ga na of guilds nog actief zijn. Vraag squads of ze zich echt autonoom voelen.

Het hele punt van het Spotify-model is dat het nooit permanent bedoeld was. De beste versie ervan is de versie die je aan jouw specifieke context hebt aangepast en blijft bijschaven.

Veelgestelde vragen

Gebruikt Spotify het Spotify-model nog?

Niet in de oorspronkelijke vorm. Spotify heeft zijn organisatiestructuur sinds de whitepaper uit 2012 flink laten evolueren. Een deel van de woordenschat leeft voort (squads en tribes worden nog genoemd), maar de specifieke structuren en praktijken uit de whitepaper bepalen niet langer hoe het bedrijf werkt. De kritiek van Jeremiah Lee uit 2020 en uitspraken van Spotify-engineers bevestigen dat het bedrijf het model zoals oorspronkelijk beschreven achter zich heeft gelaten. Dat is geen mislukking; het strookt met het eigen principe van continue evolutie.

Wat is het verschil tussen een chapter en een guild?

Een chapter is een groep mensen met dezelfde vaardigheden binnen dezelfde tribe (bijvoorbeeld alle backendontwikkelaars in Tribe A). Er is een formele Chapter Lead die als leidinggevende optreedt. Lidmaatschap is verplicht: ben je backendontwikkelaar in Tribe A, dan zit je in de backend chapter. Een guild is een interessegemeenschap die tribes overstijgt (bijvoorbeeld iedereen in het hele bedrijf die iets heeft met testpraktijken). Lidmaatschap van een guild is vrijwillig en de Guild Coordinator heeft geen leidinggevend gezag. Chapters zijn er voor technische afstemming en personeelszaken. Guilds zijn er voor kennisdeling en kruisbestuiving.

Hoe groot hoort een squad te zijn?

De whitepaper stelde 6 tot 12 mensen voor. Die bandbreedte volgt het algemene onderzoek naar effectieve teamgroottes: groot genoeg om alle vaardigheden voor levering van begin tot eind te bevatten, klein genoeg om elkaar te kennen, rechtstreeks te communiceren en gedeelde context vast te houden. Onder de 6 mis je misschien noodzakelijke vaardigheden. Boven de 12 begint de coördinatielast de voordelen van een klein team op te eten.

Kunnen niet-technologische bedrijven het Spotify-model gebruiken?

De structurele begrippen (autonome multidisciplinaire teams, groeperingen voor coördinatie, communities of practice voor kennisdeling) zijn breed toepasbaar. Maar de concrete invulling uit de whitepaper is ontworpen voor softwareontwikkeling, waar iteratief opleveren, technische autonomie en frequente releases de norm zijn. Bedrijven buiten de techsector kunnen putten uit de principes, vooral uit autonomie met afstemming en de multidisciplinaire teamopzet, maar moeten rekenen op stevige aanpassingen. Voor organisaties buiten de techsector passen modellen als sociocratie, Beta Codex of het Buurtzorg-model mogelijk beter.

Hoe verhoudt het Spotify-model zich tot SAFe?

SAFe (Scaled Agile Framework) is een allesomvattend, voorschrijvend kader met vastgelegde rollen, ceremonies en planningsevenementen op team-, programma- en portfolioniveau. Het Spotify-model is een set structurele begrippen met minimaal voorgeschreven proces. SAFe werkt goed voor grote organisaties die procesdiscipline, traceerbaarheid voor compliance en synchronisatie tussen teams nodig hebben. Het Spotify-model werkt beter voor organisaties met een sterke engineeringcultuur die structurele houvast willen zonder zware processen. De twee sluiten elkaar niet uit; sommige organisaties combineren het planningsritme van SAFe met teamstructuren in Spotify-stijl.

Wat is de rol van een Tribe Lead?

De Tribe Lead schept de omgeving waarin squads kunnen slagen. Hij stuurt geen individuele squads aan en neemt geen productbeslissingen voor hen. Zijn taken zijn onder meer: obstakels wegnemen die squads niet zelf kunnen oplossen, de coördinatie tussen squads binnen de tribe faciliteren, zorgen voor aansluiting op de bredere richting van de organisatie en de behoeften van de tribe vertegenwoordigen bij andere delen van de organisatie. De Tribe Lead staat dichter bij een dienend leider dan bij een traditionele manager.

Hoe stemmen squads over tribes heen af?

Coördinatie tussen tribes is een van de zwakkere kanten van het model. De belangrijkste mechanismen zijn guilds (vrijwillige gemeenschappen die kennis over tribegrenzen heen delen) en informele communicatie. Sommige organisaties voegen expliciete coördinatierollen tussen tribes toe, regelmatige overleggen tussen tribes of stuurgroepen voor architectuur. Andere leunen op gedeelde platformteams die diensten leveren aan meerdere tribes. Wat de juiste aanpak is, hangt af van hoe sterk het werk over tribes heen werkelijk verweven is.

Hoe gaat het Spotify-model om met rolgebaseerde governance?

Het Spotify-model schrijft geen formeel governanceproces voor. Rollen binnen squads (Product Owner, ontwikkelaar, ontwerper) worden door het model benoemd, maar hoe die rollen ontstaan, veranderen of verdwijnen laat het aan elke squad en tribe over. Organisaties die expliciete rolgebaseerde governance willen, kunnen die bovenop het Spotify-model leggen en holacratische of sociocratische governanceprocessen gebruiken binnen de structuur van squads en chapters.

Breng je organisatie in kaart

Of je nu het Spotify-model invoert, een paar van de ideeën overneemt of een heel andere aanpak verkent: de eerste stap is dezelfde. Maak je huidige structuur zichtbaar. Breng je teams, rollen en relaties in kaart, zodat iedereen hetzelfde beeld heeft van hoe de organisatie werkelijk werkt.

• Breng gratis je organisatie in kaart: Peerdom ondersteunt het Spotify-model, holacracy, sociocratie, RenDanHeYi, Beta Codex, DSO en elk hybride model. Breng je squads, tribes, chapters en guilds in kaart, of je cirkels, cellen en teams, in één platform.
• Bekijk de sjablonen: verken kant-en-klare structuren voor uiteenlopende organisatiemodellen.
• Lees de gids over software voor zelforganisatie: vergelijk tools voor organisaties met verdeelde bevoegdheid.
• Weet je niet waar je moet beginnen? Boek een demo en dan lopen we samen door hoe de structuur van jouw organisatie zich verhoudt tot het model dat je verkent.