Voordat je AI introduceert, reorganiseer je teams langs de waardestroom

Voordat je AI in je bedrijf brengt, is er één zet die meer oplevert dan welk tools of model dat je kunt kiezen: reorganiseer je technische teams langs de waardestroom. Ik heb te veel bedrijven gezien die de tools kochten, de modellen uitrolden, de mensen trainden — en de levering blijft sloom, terwijl het team er vermoeider uitziet dan ervoor. De oorzaak is vrijwel nooit dat de AI te zwak is. Het is dat de teams langs technischedlagen zijn opgesneden — frontend, backend, algoritmen, ops, security. Eén end-to-end-functie moet langs vier, vijf teams, en bij elke overdracht lekt er iets weg. Een stukje van de eis. Een stukje context. Een stukje eigenaarschap. Staan de teamgrenzen goed, dan heeft AI iets om te versterken. Staan ze verkeerd, dan versnelt AI alleen maar de schuldenberg op een kapotte structuur.

Dit artikel zet een methode uiteen die je echt kunt gebruiken — Team Topologies (Skelton & Pais, 2019). Drie ideeën vormen de kern: teams snijden langs de waardestroom, de cognitieve belasting van elk team in de gaten houden, interne platforms runnen als product. Ik pak het uit aan de hand van een echt scenario in de maakindustrie.

Een CIO in de maakindustrie (geanonimiseerd uit een echt project) vertelde me dit: een AI-functie voor slimme kwaliteitscontrole uitrollen was technisch niet moeilijk. Camera’s herkennen defecten, het model is kant-en-klaar. Moeilijk was de levering. Het frontendteam bouwde de interface, het MES-team werkte de werkorderflow om, het algoritmeteam zette het model uit, het opsteam beheerde de servers, en het securityteam moest er nog bovenop ook een beoordeling doen. Eén functie, 5 teams, 4 formele overdrachten, 3 maanden vertraging. Niemand schoot te kort. Elke overdracht liet gewoon iets vallen.

1. Conway’s Law vertelt maar de helft van het verhaal

Conway’s Law zegt: de architectuur van een systeem weerspiegelt de communicatiestructuur van het team dat het bouwt. Splits je teams in frontend en backend, dan krijg je een systeem met een frontend-backend-scheiding. Hoe het team communiceert, zo groeit het systeem. Dat is herhaaldelijk empirisch bevestigd.

Maar Conway vertelde ons alleen dat het zo gaat. Hij zei niet hoe je teams moet ontwerpen zodat een goede architectuur uit zichzelf ontstaat. Skelton en Pais hebben die kloof gedicht met Team Topologies (2019): vier basisteamtypen, drie interactiemodi, en één principe dat als een rode draad door alles loopt — houd de cognitieve belasting in de gaten.

2. De vier teamtypen: opties voor een reorganisatie, niet terminologie om uit je hoofd te leren

Ik behandel deze vier typen als opties waar je tijdens een reorganisatie naar kunt grijpen. Je hoeft geen definities te memoriseren.

Stroomgerichte teams (stream-aligned teams) — het werkpaard van je organisatie, en de grote meerderheid ervan. (Het boek zegt “most,” zonder een vaste verhouding.) Een “stroom” is een doorlopende waardestroom. Een stroomgericht team is eindverantwoordelijk voor een stuk van die stroom: van het begrijpen van de eis, via het bouwen, tot het uitrollen en draaiende houden. Eén test verraadt of een team in aanmerking komt: kan het waarde bij een gebruiker krijgen zonder afhankelijk te zijn van een ander team? Terug naar die CIO: als zijn slimme-inspectiefunctie onder één “kwaliteitsstroomteam” had gevallen — met mensen erin die frontend kennen, MES-integratie, modeluitrol en ops — dan had die functie zonder een enkele overdracht geleverd kunnen worden. Zo hoort het eruit te zien.

Het meest voorkomende probleem in grote bedrijven is dat het systeem end-to-end loopt, terwijl de teams zijn opgesneden in horizontale technologielagen. Elke end-to-end-levering moet zich een weg banen door de rapportagelijnen van meerdere teams. Het patroon geldt in elke sector, ook al wisselen de namen. In de financiële sector loopt een kredietrisicofunctie dwars door vier groepen heen — het app-team, het kernsysteemteam, het risicomodelteam en het datateam — met aan het eind van elke schakel een eigen aftekenronde. E-commerce en telecom pakken dezelfde pijn in een ander jargon: een promotiefunctie raakt catalogus, transactie, marketing en magazijn; een pakketwijziging raakt kanaal, billing, CRM en netwerk. Steeds wanneer horizontaal gesneden teams een waardestroom die verticaal loopt proberen te dragen, stapelen de overdrachten zich op. Dat is de ziekte.

Platformteams — de weg vrijmaken voor de stroomgerichte teams. Een platformteam levert infrastructuur, CI/CD en gedeelde services, zodat stroomgerichte teams de capaciteit self-service kunnen pakken in plaats van een ticket in te dienen en te wachten. Eén test: wordt je interne platform als product gerund — met gebruikers, een roadmap, een SLA — of is het afgegleden naar een interne outsourcingwinkel die van tickets leeft? De meeste IT-afdelingen van grote bedrijven zitten vast in die tweede vorm. Ze bouwen een platform dat niemand gebruikt, de bedrijfsteams werken eromheen en bouwen hun eigen ding, en het platformteam verwordt tot een externe dienstverlener in eigen huis. Netflix’ Spinnaker (continuous delivery) en Spotify’s Backstage (ontwikkelaarsportaal) zijn de schoolvoorbeelden van een platform dat als product wordt gerund. Mensen halen die twee voortdurend door elkaar: Spinnaker is van Netflix, Backstage is van Spotify. Haal het niet door elkaar waar je board bij zit.

Ondersteunende teams (enabling teams) — stroomgerichte teams helpen een niveau hoger te komen, met de uitdrukkelijke bedoeling zichzelf overbodig te maken. Een enabling team levert het bedrijf niet direct. Het tilt de capaciteit van stroomgerichte teams: een coach die een nieuwe technologie brengt, een begeleider bij een DevOps-transitie, een adviseur voor security en compliance. De relatie met het stroomgerichte team is mentor en leerling, niet opdrachtgever en leverancier. Voor grote bedrijven is dit precies de rol die een externe transformatie-adviseur zou moeten spelen: capaciteit overdragen, geen langetermijnafhankelijkheid bouwen.

Complexe-subsysteemteams — voor de harde noten die diepe specialisatie vergen. Als een subsysteem echt diepte vraagt — een risico-engine, een aanbevolingsalgoritme, cryptografie, videocodecs — dan hak je het eruit als een eigen expertteam, in plaats van de cognitieve belasting van een stroomgericht team te laten ontploffen. Deze teams moeten zeldzaam zijn. Een organisatie die er veel ziet opduiken, is meestal bezig wat eigenlijk platformcapaciteit is in silo’s uiteen te leggen.

Alleen de teamtypen benoemen is niet genoeg. Je moet ook vastleggen hoe ze met elkaar omgaan. Team Topologies geeft drie interactiemodi. Samenwerking (collaboration) — twee teams diep samenwerken, geschikt voor onzeker nieuw terrein, maar energie-intensief en alleen voor korte uitbarstingen. X-as-a-Service — het ene team levert een capaciteit als product dat een ander team zelfstandig consumeert; dit is de meest efficiënte modus en zou de default moeten zijn. Faciliteren (facilitating) — uitsluitend voor enabling teams. De kernvraag van organisatieontwerp is: hoe duw je zoveel mogelijk interacties richting X-as-a-Service. Als je teams op lange termijn nog leunen op “samenwerking,” dan is platformisatie niet doorgevoerd. Neem de situatie van die CIO: het kwaliteitsstroomteam en het platformteam zouden via X-as-a-Service moeten samenwerken. Het platform biedt een self-service CI/CD-ingang, het kwaliteitsstroomteam gebruikt die zonder in te bellen. Als elke uitrol nog een “samenwerkings”-vergadering met het platformteam vergt, ontbreekt platformisatie — en het probleem zit niet in de attitude. Het platform is nooit als product ingericht.

3. Waarom “meer mensen” en “meer proces” beide falen: cognitieve belasting

Dit is de meest onderschatte bijdrage van Team Topologies. Het plaatst cognitieve belasting in het centrum van organisatieontwerp.

Een team van 5 tot 8 mensen heeft een eindige cognitieve capaciteit. Vraag één team om een dozijn ongerelateerde systemen te onderhouden, met zes of zeven upstreams te praten en tegelijk drie nieuwe frameworks te verwerken — het overbelast. Kwaliteit daalt. Levering wordt trager. Mensen branden op.

Daarom was die CIO verbaasd toen hij me vertelde: “Ik heb er drie mensen bij gezet, waarom zijn we nog steeds langzaam?” De oorzaak zit erin dat deze groep al te veel ongerelateerde dingen tegelijk droeg. Het aantal mensen was prima. Mensen toevoegen zet alleen meer lichamen in dezelfde chaos laten ronddraaien. Proces toevoegen is erger — proces vreet nog een laag cognitieve capaciteit, en de mensen die echt iets konden leveren besteden hun tijd aan formulieren, vergaderingen en goedkeuringen.

Het vet dat een groot bedrijf het gemakkelijkst kan afschaven, is de last die het zichzelf oplegt — wrijving tussen teams, constante contextwissels, goedkeuringsketens. Er is geen nieuwe technologie voor nodig. Alleen minder heen en weer gesleur.

Een concreet geval. De hoofd van een bank-kernsysteemteam had 7 mensen die met vier upstreams praatten — risico, klantenservice, toezichtrapportage, marketing — terwijl ze drie ongerelateerde modules onderhielden. Alleen het afhandelen van de cross-team aftekenrondes, afstemmingsvergaderingen en contextwissels vrat elke dag bijna de helft van de energie van het team op. Geef dit team de beste AI-tool op de markt en hij blijft niet hangen. Er is geen cognitieve bandbreedte meer over om iets nieuws te leren of de manier van werken te veranderen. Om ze te redden moet je de last eerst omlaag brengen: hak de ongerelateerde modules eruit en laat het team één waardestroom dragen.

De “Two-Pizza Team”-regel van Amazon gaat over communicatiekosten — zodra het aantal mensen groeit, explodeert het aantal communicatiekanalen tussen leden (n(n-1)/2) en worden beslissingen traag. Team Topologies gaat een laag dieper: boven de 8 personen raakt ook de cognitieve belasting uit de hand. Wat organisatieontwerp werkelijk doet is teams splitsen op cognitieve belasting, zodat de last van elk team binnen een draaglijke bandbreedte valt — niet rapportagelijnen langs functies tekenen.

Een éénregelige check voor grote bedrijven: dragen je “drukste mensen” elk meer dan 5 ongerelateerde dingen tegelijk? Zo ja, dan redden extra mensen of extra proces het niet. Dan moet je opnieuw snijden.

4. Hoe te handelen: de omgekeerde Conway-maneuvre

Dit is de meest uitvoerbare zet uit het boek. Teken niet eerst de architectuur en reorganiseer dan de teams om erin te passen. Verander eerst de teamstructuur, en laat de architectuur groeien naar de vorm die je wilt.

De traditionele aanpak: een architect tekent een doelarchitectuur (“we gaan microservices!”), en eist vervolgens dat de teams zich herorganiseren om erin te passen. Dat faalt vrijwel altijd. De bestaande teamstructuur trekt de architectuur telkens terug naar zijn eigen vorm. Conway’s Law, aan het werk.

De omgekeerde Conway-maneuvre draait de volgorde om. Herorganiseer eerst de teams langs de waardestroom — hak stroomgerichte teams uit, richt een platformteam op — zodat de teamgrenzen de toekomstige servicegrenzen worden. Daarna neigt de architectuur vanzelf naar een verantwoorde servicesplitsing, omdat teams van nature via API’s communiceren in plaats van in een gedeelde database te graaien.

Terug naar die CIO. Ik liet hem geen microservice-framework kiezen. Ik liet hem iets veel platters doen: “kwaliteitscontrole” als eigen stroomteam oprichten. Trek één persoon uit elk van de oorspronkelijke frontend-, MES-, algoritme- en opsteams. Zes mensen, eindverantwoordelijk voor de kwaliteitsfunctie. Er gebeurden drie dingen in drie weken. Week één: ze ontdekten dat een stap die vastzat in de MES-werkorderflow het algoritmeteam helemaal niet nodig had — ze losten het zelf in het team op. Week twee: ze besloten zelf om de modeluitrol te verplaatsen van “in de wacht voor het opsteam” naar self-service in het team, omdat het platformteam een self-service CI/CD-ingang voor ze had opengezet. Week drie: ze rolden de eerste kleine end-to-end-functie uit, zonder enige teamgrens te passeren. Geen mens bij, geen tool gewisseld — de horizontale lagen waren her-sneden tot verticale stromen. De levertijd daalde van 3 maanden naar 3 weken. Een onverwachte bonus volgde: dit team begon uit zichzelf verbeteringen voor te stellen, omdat ze voor het eerst de hele stroom van begin tot eind overzagen en het resultaat end-to-end droegen. Toen het over 5 teams was verspreid, had niemand zich eindverantwoordelijk gevoeld voor de hele kwaliteitsstroom.

Voor beslissers is dit een contra-intuïtieve maar hefboom-rijke conclusie: stop met martelen op het architectuurdiagram en begin te snijden in het organogram. Architectuur is de uitkomst. Organisatie is de hefboom.

Wie het gebruiken

Bankwezen (officiële TT-focussector + referentie voor zwaar gereguleerde omgevingen). teamtopologies.com heeft een expertcolumn, “When DORA metrics meet governance in banking.” Het DORA-onderzoek dat het aanhaalt is hard: externe goedkeuringen (external approvals) correleren negatief met lead time, deployment frequency en restore time — hoe meer achteraf-goedkeuringen over teams heen, hoe trager de levering en hoe trager het herstel na incidenten. Dat onderstreept precies de stelling van dit artikel: bouw compliance in het stroomteam in en schuif goedkeuring naar voren, in plaats van achteraf cross-team af te tekenen. Digitale banken als ClearBank duiken herhaaldelijk op in het officiële ecosysteem. Het bankwezen is het meest leerzame scenario voor waardestroom-reorganisatie onder zware regelgeving.
Zalando (e-commerce, het platform-als-product-voorbeeld). Het interne ontwikkelaarsplatform dient als self-service-capaciteit voor stroomgerichte teams — een platformisatie-benchmark die in de TT-gemeenschap vaak wordt aangehaald.
AutoTrader UK (autoclassifieds). Een echte adoptiecase die TT herhaaldelijk aanhaalt — reorganisatie langs de waardestroom plus internal-platform-productisering.
KPMG UK (in 2024 TT Official Solutions Partner geworden). Brengt TT naar grote bedrijven en financiële klanten — een signaal dat TT de mainstream ondernemingsconsulting is binnengekomen.
Netflix / Spotify (geestelijke voorbeelden van “platform als product,” geen TT-adoptiecases). Beide runnen hun platforms als product ruim voordat het TT-boek in 2019 verscheen, wat het principe bevestigt — maar het zijn geen adopties van het TT-vierteammodel.

Referentie: teamtopologies.com/examples (officiële casus-bibliotheek) · teamtopologies.com/news-blogs-newsletters/when-dora-metrics-meet-governance-in-banking (bank-DORA-expertcolumn)

5. Wanneer het niet werkt

Team Topologies is geen zilveren kogel. Vier veelvoorkomende faalvormen, elk gekoppeld aan een echte pathologie in grote bedrijven.

Alleen de naam veranderen, niet de structuur. Herdoopt het “frontendteam” tot “stroomgericht team” terwijl de rapportagelijnen technischedlagen blijven — Conway’s Law trekt zich niets van naamgeving aan. Dit is de meest voorkomende afloop van een cosmetische hervorming in een groot bedrijf: nieuwe labels, zelfde oude structuur.

Het platformteam wordt niet als product gerund. Geen roadmap, geen gebruikerservaring. Stroomgerichte teams blijven eromheen werken, en het platform verwordt tot een outsourcingwinkel die tickets aanneemt.

Iedereen is aan het “samenwerken.” Samenwerking is een energie-intensieve interactie, alleen geschikt voor korte uitbarstingen in onzeker nieuw terrein. Er langdurig op leunen betekent dat platformisatie niet is doorgevoerd. Boven lijkt het op een “geweldige samenwerkingscultuur.” De ziekte eronder is ontbrekende platformisatie.

De KPI’s zijn niet meeveranderd. Het organogram is gewijzigd, maar je meet nog steeds langs functies — regels frontendcode, bugaantallen — en het teamgedrag knalt rechtstreeks terug naar de oude vorm.

Deze vier wijzen op één oordeel: van organisatiestructuur, prikkelstructuur en technische architectuur — verander je er één zonder dat de andere twee volgen, dan mislukt de transformatie.

Een variant voor zwaar gereguleerde sectoren. Financiën en telecom zullen vragen: functies als security, compliance en tech-risico moeten volgens de toezichthouder onafhankelijk zijn (segregation of duties). Ze kunnen niet zomaar in het stroomteam worden gevouwen. Dat is een harde wettelijke beperking, geen organisatorische traagheid — forceer het niet. Maar je hoeft ook niet terug te vallen op horizontale goedkeuringswachtrijen. Twee routes. Ten eerste: bed compliance- en security-vertegenwoordigers in het stroomteam in. Ze zitten in het team en rapporteren dotted-line naar de compliance-functie, dicht bij de waardestroom en toch onafhankelijk. Ten tweede: run compliance als een enabling team dat stroomteams helpt de toezichthoudereisen in de stroom in te bouwen — compliance-checks in de CI-pipeline bijvoorbeeld — zodat goedkeuring naar voren wordt geschoven naar het team zelf, in plaats van achteraf cross-team te worden afgetekend. Toezichthoudereisen worden ingebakken kwaliteit van het stroomteam, geen externe beoordelingspoort. Dat is de sleutel waardoor zwaar gereguleerde sectoren überhaupt “kunnen stromen.”

6. Misschien vraag je je af

“We zitten al tien jaar langs technischedlagen — zal een reorganisatie niet een enorme schok zijn?” Jawel, maar veel minder dan je denkt. Je hoeft niet het hele bedrijf plat te gooien en overnieuw te beginnen. Kies de waardestroom die het zwaarst vastzit — meestal degene waarover het hardst wordt geklaagd — en richt die als proef op als één stroomgericht team. Net als die CIO: 4 tot 8 weken, één klein team, en je ziet een duidelijke verschuiving in leversnelheid. Resultaten overtuigen de volgende ronde veel beter dan een slidewee.

“Hoe verhoudt dit zich tot de AI-transformatie die we al aan het doorvoeren zijn?” Direct. AI repareert geen verkeerd ingerichte organisatie. Het versterkt wat er al is: hoogpresterende teams worden met AI sneller; verkeerd ingerichte teams bouwen met AI alleen sneller schulden. Dus de organisatiediagnose rangschikt vóór de toolinkoop. Daarom plaats ik “capaciteitsbeoordeling” heel vroeg in mijn vlaggenschipmethode, het 7-Step AI Transformation Coaching Framework — kijk eerst naar organisatie en mensen, praat daarna pas over tools.

“Wat als we niet alle vier teamtypen kunnen invullen?” De meeste organisaties kunnen dat niet, en hoeven dat ook niet. De eerste twee die je zou moeten hebben zijn stroomgerichte teams (om end-to-end-levering te garanderen) en een platformteam (om te stoppen met het wiel telkens opnieuw uit te vinden). Enabling teams en complexe-subsysteemteams komen bij behoefte; veel organisaties hebben ze in het begin niet, en dat is prima. Fabriceer geen teams louter om de vier typen compleet te krijgen. Dat is de staart die de hond kwispelt.

7. Lessen voor beslissers

Les een: voordat je AI introduceert, teken een teamtopologie-kaart. Heb je, voor de laatste AI-tool die je introduceerde, ooit je teamtopologie getekend? Met teams verkeerd langs technischedlagen gesneden, versnelt zelfs de sterkste AI alleen de schuldenberg op een kapotte structuur. Deze enkele check kan minstens de helft van de verspilde IT-investering in een groot bedrijf blokkeren. Concrete actie: zet elk team op een rij en markeer per team end-to-end voor welke waardestroom het eigenaar is. Degene die je niet kunt markeren zijn langs technischedlagen gesneden, en die gaan voor bij herorganisatie.

Les twee: draai een cognitieve-belasting-check. Stop met de vraag “hebben we genoeg mensen.” Vraag welke teams tegelijk meer dan 5 ongerelateerde systemen onderhouden, en welke personen met meer dan 3 upstreams praten. Dat inzichtelijk maken is veel nuttiger dan mensen of proces toevoegen. AI kan een deel van de last dragen — code schrijven, dingen opzoeken, eerste triage — mits je de last bewust herverdeelt, in plaats van een overbelast team nog een extra “AI-uitrol”-taak op de stapel te leggen.

Les drie: run het interne platform als product, of het ontaardt onvermijdelijk in outsourcing. Het platform moet gebruikers hebben, een roadmap, een SLA, en iemand die verantwoordelijk is voor de adoptieratio. In het AI-tijdperk moet dit platform ook de model-gateway, de promptbibliotheek en de agent-runtime omvatten — dat is het fundament dat het latere “adoptie-framework”-stuk zal uitbouwen.

Les vier: laat AI de verkeerde grenzen niet verstevigen. Deze is specifiek voor organisaties die AI-agenten invoeren. Als je AI-agenten aan teams toevoegt, wordt een verkeerde teamsnede uitvergroot: de agent automatiseert langs de bestaande — verkeerde — grenzen en zet de kapotte structuur steviger vast. Voordat je AI-agenten introduceert, bevestig dan dat de teamgrenzen kloppen. Dit is de focus van het elfde stuk in de reeks.

Omgekeerde zelf-check (antwoord zonder mooipraat): is je team langs de waardestroom gesneden, of langs frontend/backend/ops/security? Draagt je drukste persoon meer dan 3 ongerelateerde dingen tegelijk? Als je interne platform geen gebruikers heeft, brandt het rode lampje voor mislukte platformisatie. Als je bij een van beide antwoorden ongemakkelijk schuift, reorganiseer dan je teams voordat je AI introduceert. Het is de zet met het hoogste rendement die je vooraf kunt doen.

Volgende stap

Dit is het tweede stuk in de reeks “AI-tijdperk software-engineering” (aflevering 172 van de rubriek “Learn AI Slowly”). We zijn van Conway (organisatie bepaalt architectuur) naar Team Topologies (hoe de organisatie te ontwerpen) gelopen. Het volgende stuk (nr. 3) pakt een fundamentele vraag op: nu AI het produceren van code vrijwel gratis maakt, waar verschuift de bottleneck van software-engineering naartoe?

Reeks-notitie: deze reeks volgt continu de laatste verschuivingen in AI-programmeertools, organisatiestructuren en software-engineeringparadigma’s — bijvoorbeeld hoe Conway’s Law in 2026 verandert in het tijdperk van AI-agenten, en de rijpheid van het actuele tools-ecosysteem. Volg de reeks voor continu bijgewerkte inzichten.

Over deze reeks

“AI-tijdperk software-engineering” is een diepgaande onderzoeksserie geschreven voor CIO’s, CDO’s, CTO’s en digitale leiders in sectoren als telecom, financiën, maakindustrie en e-commerce — 15 stukken in totaal. Gebouwd op 200+ academische papers en brancherapporten, biedt beslissingsreferenties met bewijsniveaus aangegeven.

Ik ben ex-IBM-engineer en ICF-gecertificeerd coach, met handen-ervaring in het leveren van AI- en digitaliseringsprojecten voor carriers en grote bedrijven. Wat hier staat, is het velddoordachte oordeel opgebouwd tijdens het begeleiden van bedrijven door deze valkuilen.

Als je dit las en denkt “is ons bedrijf ook zo ingericht” — ik heb een 20-vragen Team Topologies zelfcheck samengesteld, en ik bied een 30-minuten 1-op-1 diagnostisch gesprek aan om te bepalen welke waardestroom je als eerste moet herorganiseren. Als je daarvoor belangstelling hebt: laat een bericht achter bij het officiële account “AI Decision-Maker Insight,” of mail naar coach@iaiuse.com.

Referenties

Skelton, M. & Pais, M. (2019). Team Topologies. IT Revolution Press. (de oorspronkelijke bron voor de vier teamtypen / drie interacties / cognitieve belasting — primaire bron)
Conway, M. (1968). How Do Committees Invent? Datamation.
Forsgren, Humble & Kim (2018). Accelerate. IT Revolution Press.
IT Revolution (2024). Team Topologies: Five Years of Transforming Organizations. (multi-organisatie adoptie-retrospectief, secundair) https://itrevolution.com/articles/team-topologies-five-years-of-transforming-organizations/
Netflix Spinnaker / Spotify Backstage — voorbeelden van internal-platform-productisering
AutoTrader UK — een door TT officieel aangehaalde adoptiecase (link op teamtopologies.com nog aan te vullen)
Officiële casus-bibliotheek: https://teamtopologies.com/examples