Vooraf

Je softwarearchitectuur wordt niet “ontworpen” door je technische team, maar “groeit” uit je organisatiestructuur. Deze wet, voorgesteld in 1968, wordt herhaaldelijk bevestigd in het AI-tijdperk.
Empirisch onderzoek van de Harvard Business School bewijst: organisatorische afstand voorspelt softwaredefecten beter dan codecomplexiteit. Wat jij “technische schuld” noemt, is waarschijnlijk in feite “organisatorische schuld”.
Amazon’s microservice-rijk, Spotify’s teammodel en Apple’s Siri-dilemma — drie bedrijven met een waarde van triljoenen dollars, met volledig verschillende loten, die dezelfde wet verduidelijken.
AI-agents betreden nu de organisatiestructuur. Wanneer de “knopen” in je team niet langer alleen mensen zijn, wordt de wet van Conway op een manier opnieuw geschreven die je niet had verwacht.

In 1968 schreef een onbekende programmeur een paper die door de Harvard Business Review werd afgewezen met de opmerking dat het argument niet was bewezen. 56 jaar later is de kern van die paper uitgegroeid tot een algemeen aanvaarde wet in de softwareindustrie — en in 2026, in een tijd waarin AI alles herschrijft, is hij belangrijker dan ooit.

I. Hoe een afgewezen paper de “zwaartekrachtwet” van softwareengineering werd

De profeet die door HBR werd afgewezen

In april 1968 publiceerde Melvin Conway een paper met een bescheiden titel in het tijdschrift Datamation: “How Do Committees Invent?” De kernstelling van deze paper bestaat uit één zin — en die is voldoende om elke CTO wakker te houden:

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”
In eenvoudige taal: jouw organisatiestructuur is de spiegel van jouw softwarearchitectuur.
Conway beschreef in zijn paper een verfijnd voorbeeld. Een bedrijf stelde acht personen in twee groepen in om twee compilers te bouwen: een groep van vijf en een groep van drie. Het resultaat? De groep van vijf bouwde een compiler met vijf fasen; de groep van drie bouwde een compiler met drie fasen. Niet omdat technisch nodig was om zo te verdelen — maar omdat iedereen “eigenaar” wilde zijn van zijn eigen werkunit.
Conway beschreef deze relatie wiskundig als een “homomorfisme” — een structuurbehoudende afbeelding tussen de organisatiestructuur en het systeemontwerp. Het is geen toeval, geen toevallige overeenkomst, maar een wetmatigheid die bijna wiskundig noodzakelijk is.

Ironisch genoeg stuurde Conway het artikel oorspronkelijk naar de Harvard Business Review, maar werd het afgewezen door de redactie met de opmerking dat het argument niet was bewezen. Zeven jaar later citeerde Fred Brooks deze visie serieus in zijn klassieker “The Mythical Man-Month” en gaf het officieel de naam “Conway’s Law”.
Vanaf dan werd een observatie die door toonaangevende commerciële tijdschriften was afgewezen, een van de meest geciteerde wetten in de software-engineering.
## Martin Fowlers “definitieve oordeel”
Als Conway de Copernicus was die de hypothese formuleerde, dan zijn de empirische onderzoeken van de afgelopen twintig jaar de telescoop.
In 2022 schreef Martin Fowler, chief scientist bij ThoughtWorks, een evaluatie die wijdverspreid werd gedeeld in de industrie: “Als er één wet is in het gebied van softwarearchitectuur die door alle praktijkers wordt erkend, dan is het Conway’s Law. Het is belangrijk genoeg om elk systeem dat ik heb gezien te beïnvloeden; het is krachtig genoeg dat iedereen die probeert het te trotseren, gedoemd is te falen.”
Dit is geen theoretische overweging uit een ivoren toren. Fowler heeft in zijn consultatiepraktijk bij honderden bedrijven over de hele wereld hetzelfde fenomeen herhaaldelijk waargenomen: de organisatiestructuur is een schaduw van de software-ontwerpstructuur, ongeacht of het management zich daarvan bewust is.

Hier is een subtiel maar cruciaal punt dat veel mensen over het hoofd zien: Fowler zegt “iedereen die probeert te weerstaan ervan is gedoemd te falen”, niet “iedereen die probeert te benutten ervan”. Wat is het verschil? Tegen de wet van Conway ingaan betekent architectuurveranderingen forceren zonder de organisatiestructuur te veranderen; het benutten ervan betekent eerst de organisatie aan te passen, zodat de architectuur ‘natuurlijk groeit’.
Dit verschil bepaalt het succes of falen van digitale transformatieprojecten. In het volgende, tweede deel over Team Topologies zullen we uitgebreid ingaan op de sleutelstrategie van de “Inverse Conway Maneuver” — die essentieel is het benutten, en niet bestrijden, van deze wet.

II. Van laboratorium naar slagveld: drie studies bevestigen deze wet

De “mirroring hypothesis” van de Harvard Business School

In 2012 publiceerden MacCormack en anderen van de Harvard Business School een baanbrekend onderzoek, dat in de academische wereld bekend is geworden als de “Mirroring Hypothesis”.

De onderzoeksmethode was zeer sluw: ze vergelijken commerciële software en open-source software die exact dezelfde functie uitvoeren. De commerciële software werd ontwikkeld door een hiërarchisch bedrijfsteam; de open-source software door een losse, verspreide community.

Het resultaat bevestigt Conway’s wet: producten van los gekoppelde organisaties zijn aanzienlijk meer gemoduleerd. Strak gekoppelde bedrijfsteams, zelfs als ze bewust modulair ontwerp nastreven, leveren systemen op die nog steeds de strakke koppeling van hun organisatiestructuur weerspiegelen.

De organisatiestructuur werkt als een “zwaartekrachtveld” — je kunt er tijdelijk tegen bestaan, maar op de lange termijn wordt de systeemarchitectuur altijd teruggetrokken naar een vorm die identiek is aan de organisatiestructuur.

Wat is de echte boodschap voor bedrijfsleiders uit dit onderzoek? Wanneer je technische teams je herhaaldelijk vertellen “We moeten refactoren”, dan is het mogelijk niet de code die herstructurering nodig heeft, maar de organisatie zelf. Maar hoe kun je onderscheiden tussen “technische schuld” en “organisatorische schuld”? Daarvoor is een systematische diagnose methode nodig — in artikel 12, “Kader voor besluitvorming over de aanname van AI-hulpmiddelen in bedrijven”, presenteren we een volledig evaluatiemodel.

Het “Windows Vista-experiment” van Microsoft Research

In 2008 voerden Nagappan en anderen van Microsoft Research een grote kwantitatieve studie uit naar het Windows Vista-project. Ze wilden een cruciale vraag beantwoorden: welke factor voorspelt het beste defects (bugs) in software?

De kandidaten waren: codecomplexiteit, aantal regels code, frequentie van codeveranderingen, ervaring van ontwikkelaars… en een variabele die op het eerste gezicht niets met “techniek” te maken had — organisatorische afstand (de afstand tussen teams die gerelateerde modules ontwikkelen, binnen de organisatiestructuur).

De onderzoeksconclusies maken veel technocraten ongemakkelijk: organisatieafstand voorspelt softwaredefecten beter dan codecomplexiteit. Met andere woorden: modules die worden ontwikkeld door teams die ver van elkaar staan in de organisatiestructuur, hebben meer bugs dan modules met extreem complexe code maar die worden onderhouden door nauw samenwerkende teams. Wat je denkt dat een slechte code is, kan in werkelijkheid een slechte organisatiestructuur zijn.
De bedrijfsmatige implicaties van deze ontdekking zijn veel dieper dan ze op het eerste gezicht lijken. Het betekent — je QA-strategie moet volgen wat de organisatiestructuur is, niet wat de codecomplexiteit is. Modules die door meerdere teams worden gedeeld, hebben een strengere testdekking en reviewprocessen nodig, zelfs als de code zelf niet complex lijkt. In een tijd waarin AI-gegenereerde code explosief toeneemt (Copilot genereert nu 46% van de code die gebruikers schrijven), wordt dit principe nog belangrijker — we zullen dit uitgebreid bespreken aan de hand van het Coinbase-geval in artikel 8, over de “productiviteitsparadox”.

De “versnelling” en “verborgen risico’s” van het DORA-onderzoek

Het DevOps Research and Assessment (DORA)-team van Google, geleid door Nicole Forsgren, Jez Humble en Gene Kim, publiceerde de grootste studie tot nu toe over de efficiëntie van softwarelevering.

De kernvinding is sterk in lijn met Conway’s Law: “Als we een los gekoppelde, goed geëncapsuleerde architectuur implementeren, gecombineerd met een passende organisatiestructuur, kunnen we niet alleen de leveringssnelheid en stabiliteit verbeteren, maar ook bij aanzienlijke groei van de engineeringteams lineaire of zelfs superlineaire productiviteitsgroei behouden.” Het DORA-rapport van 2022 ontdekte echter een opvallende bijwerking: hoewel los gekoppelde architectuur de leveringsefficiëntie verhoogt, kan het ook het vermoeidheidsniveau van teams verhogen. Mogelijke oorzaak: wanneer teams hoogst zelfstandig en onderling geïsoleerd zijn, kunnen leden het gevoel verliezen van een groter doel, en een gevoel van “ik ben slechts een tandwiel” ontwikkelen.
Dit is een belangrijke herinnering — architectuur- en organisatie-afstemming is geen wondermiddel; het lost efficiëntieproblemen op, maar kan culturele problemen veroorzaken. Een diepgaande implicatie: als los gekoppelde architectuur + los gekoppelde organisatie menselijke ontwikkelaars al geïsoleerd voelen, wat gebeurt er dan als AI-agents aan het team worden toegevoegd? AI voelt geen isolatie, maar mensen zullen nog geïsoleerder worden. Dit aspect wordt zelden besproken, maar in ons onderzoeksmateriaal stelt een BCG-rapport uit 2025 het “orchestratieprobleem van middelbare managers” voor — dit is ook het kernthema van ons elfde artikel.

Drie: De “Conway-momenten” van drie bedrijven met een waarde van een biljoen

Amazon: Een e-mail van de CEO die alles veranderde

Rond 2002 stuurde Jeff Bezos een beroemde e-mail binnen bij Amazon met de “API Mandate”: alle teams moesten communiceren via service-interfaces (API’s), en het was verboden om rechtstreeks toegang te krijgen tot de gegevensopslag van andere teams.
De laatste regel van deze e-mail zou luiden: “Mensen die deze regels niet naleven, worden ontslagen.”
Veel mensen zien de microservices-architectuur van Amazon als een technische keuze. Maar vanuit de wet van Conway gezien, was Bezos eigenlijk een organisatiekeuze aan het maken: hij dwong met managementmaatregelen het “kortegat” in de communicatie tussen teams af, waarna de softwarearchitectuur vanzelf evolueerde naar onderling geïsoleerde service-modules.
Dit leidde tot wat Bezos later de “Two-Pizza Team” noemde — elk team mag niet groter zijn dan het aantal mensen dat met twee pizza’s te voeden is (meestal 5-8 personen); elk team bezit zijn eigen service, wordt zelfstandig geïmplementeerd en communiceert via API’s met de buitenwereld.
Het microservices-imperium van Amazon is niet getekend door architecten — het is groeien als gevolg van de organisatiestructuur. Dit is het klassieke, positieve voorbeeld van de wet van Conway.

Maar hier is een aspect dat veel artikelen negeren: Amazons succes ligt niet alleen aan Bezos’ begrip van Conway’s Law, maar ook aan zijn oplossing van het “incentive alignment”-probleem. Elk “two-pizza team” heeft zijn eigen P&L (winst- en verliesrekening); ze zijn niet alleen technisch autonoom, maar ook bedrijfsmatig autonoom. Dit betekent dat teams een intrinsieke motivatie hebben om de grenzen van hun services duidelijk te houden — want vaagere grenzen betekenen vaagere verantwoordelijkheden, en vaagere verantwoordelijkheden betekenen vaagere prestatiebeoordelingen. De driehoek van organisatiestructuur + incentivestructuur + technische architectuur — dat is het volledige Amazon-model. Bedrijven die alleen de organisatiestructuur overnemen, maar de incentivestructuur negeren, krijgen slechts de vorm, niet de essentie.

Spotify: Het ideale model tegen de realiteit van “entropie”

Spotify’s “Squad-model” werd een tijdlang in Silicon Valley als de bijbel van organisatieontwerp beschouwd: autonome teams van 5-8 personen (Squads), meerdere Squads samengevoegd in Tribes, technische experts over Tribes heen gegroepeerd in Chapters, en community’s aangedreven door interesse in Guilds.
Deze modelstructuur is volledig in lijn met Conway’s Law — door kleine, autonome teams te creëren, wordt een architectuur van kleine, autonome softwarediensten aangestuurd.

Maar Spotify zelf erkende later dat de realiteit veel complexer is dan het model. Zodra het bedrijf groeit tot een bepaalde schaal, nemen afhankelijkheden tussen teams onvermijdelijk toe, en zuivere autonomie begint coördinatiekosten te genereren.
Dit onthult een vaak vergeten implicatie van Conway’s Wet: organisatiestructuur is niet iets wat je een keer ontwerpt en daarna vergeten kunt. Net als software heeft het een neiging tot ‘entropie’. Naarmate de bedrijfscomplexiteit toeneemt, worden organisatiegrenzen vaag, communicatiepaden langer, en de systeemarchitectuur degradeert.
Een uitstekende technische organisatie heeft niet “een goede architectuur ontworpen”, maar een continu vermogen opgebouwd om organisatie-architectuuralignement aan te passen. Dit vermogen bespreken we in de tweede blog over Team Topologies — het biedt een systematischer en praktischer kader dan het Spotify-model.

Apple: Waarom Siri werd “verslagen” door ChatGPT

In 2024-2025 werd Apples Siri AI-upgradeplan bijna een “tegenbeeld” van Conway’s Wet.

Het probleem ligt niet in de technologie. Apple beschikt over wereldklasse AI-onderzoekers en overvloedige middelen. Maar de ontwikkeling van Siri omvat twee teams met een structurele scheur in de organisatiestructuur: het AI-onderzoeksteam (onder leiding van John Giannandrea) en het productontwikkelingsteam (onder leiding van Craig Federighi).

Deze teams hebben verschillende prioriteiten, verschillende tempoen en verschillende successcriteria. Het AI-onderzoeksteam streeft naar grensverleggende doorbraken in modelcapaciteit; het productteam streeft naar stabiele, gebruiksvriendelijke uitvoering. Wanneer de communicatiestructuur tussen deze twee organisatorische “knooppunten” gebroken is, is het resulterende systeem ook gebroken.

Wat krijgt de gebruiker uiteindelijk als Siri? Een “samengestelde, middelmatige assistent” — elk onderdeel lijkt redelijk, maar samen ontbreekt het een coherente intelligente ervaring. Dit is precies wat Conway’s wet voorspelt: de scheuren in het systeem spiegelen de scheuren in de organisatie.

Het geval van Apple is bijzonder relevant voor Chinese bedrijfsleiders. Veel bedrijven ervaren precies dezelfde problemen — AI-teams en bedrijfsteams vallen onder verschillende VPs; AI-implantatieprojecten worden een “politieke strijd tussen twee afdelingen” in plaats van een “samenwerking bij het leveren van één product”.

Als je bedrijf aan het vooranbrengen is van AI-implantatie, kijk dan terug naar je organisatiestructuur: is AI-capaciteit een afzonderlijke afdeling, of is het ingebed in de bedrijfsteams? Het antwoord op deze vraag kan meer bepalend zijn voor het succes van je project dan welk AI-model je kiest.

Vier: Het AI-tijdperk: de wet van Conway wordt herschreven

Wanneer “organisatieknopen” niet langer alleen mensen zijn

In 2026 staat de wet van Conway voor de diepste uitdaging sinds haar formulering in 1968. Conway ging er bij het formuleren van deze wet stilzwijgend van uit dat elke “knoop” in een organisatie een mens is: communicatiestructuren bestonden uit mens-mens communicatie.

Maar vandaag de dag betreden AI-agents de organisatiestructuur. Claude Code kan zelfstandig meervoudige ontwikkelstappen uitvoeren, Stripe’s Minions-systeem produceert meer dan 1000 samengevoegde PR’s per week, en Cursor heeft de werkwijze van 100% van NVIDIA’s ingenieurs veranderd. Gartner rapporteert een toename van 1445% in consultancyvragen rond multi-agent AI-orchestratie in 2025.

Wat gebeurt er met de wet van Conway wanneer sommige knopen in de organisatie geen mensen meer zijn?

Deze discussie zal zich door het tweede deel van onze serie doortrekken — de tiende post over het fenomeen “Eénman Unicorn”, de elfde over “Conway’s Law ontmoet AI-agents”, en de veertiende over “Agentic Engineering” — maar hier zijn al drie voorlopige inzichten om je denkframe te vormen:

Eerst: communicatiestructuur wordt strategische structuur. Menselijke communicatie vertrouwt op cultuur, stilzwijgende afspraken en informele interacties. Maar tussen mensen en AI-agents bestaat geen “stilzwijgende afspraken” — je moet de interactiegrenzen definiëren via expliciete strategieën, regels en rechten. Governance-vaardigheden vervangen communicatievaardigheden als kernvariabele in organisatieontwerp.

Tweede: organisatiestructuren worden toegangsdiagrammen. Traditionele organisatiestructuren beschrijven rapportagerelaties en functieverdeling. De “structuur” in het AI-tijdperk lijkt eerder op een gerichte acyclische graaf (DAG), die capaciteiten en beperkingen definieert: welke agent toegang heeft tot welke data, welke acties mag uitvoeren, en onder welke voorwaarden menselijke goedkeuring nodig is.

Derde: institutionele kennis verplaatst zich van mensen naar strategieën. Vroeger was “als een ervaren medewerker vertrekt, neemt hij de kennis mee” een pijnlijke realiteit voor elke organisatie. In de toekomst zal cruciale kennis worden gecodeerd in de strategieën en contexten van AI-agents — dit is zowel een kans (kennis verliest niet meer) als een risico (foutieve strategieën kunnen systematisch worden versterkt).

Elke beoordeling wordt ondersteund door een groot aantal industriepraktijken en gegevens. Bijvoorbeeld, de derde punt over “institutioneel knowledge transfer”: het geval van Klarna biedt een boeiende, zowel positieve als negatieve les — na het ontslaan van 40% van de medewerkers ontdekten ze dat het AI-systeem niet in staat was om de impliciete kennis te dragen die de ontslagen medewerkers meenamen, waardoor ze gedwongen waren om opnieuw personeel aan te nemen. Dit verhaal zullen we volledig uitwerken in artikel 9, “De Les van Klarna”.

De eerste en tweede bewering worden niet alleen door ons zo gezien. In de a16z-podcast van juli 2026, “Software in the Age of Agents”, kwamen Seema Amble, partner van het a16z enterprise-team, en Steven Sinofsky, voormalig president van Microsoft Windows, uit hun praktische investeringsobservaties tot een hoogst gelijkende conclusie. Steven bracht het kernpunt van bewering één op één punt: “The biggest network effect in enterprise software is inside of a company”: het netwerk van menselijke relaties, processen en systemen binnen een organisatie is de echte bron van binding. Agents kunnen zich niet via “intuïtie” aansluiten op dit netwerk — ze moeten zich aansluiten via duidelijke strategieën en rechten — dit is de praktische druk die “communicatiestructuur” verandert in “strategische structuur”. Seema bevestigde bewering twee vanuit het perspectief van agent-toegang tot bedrijfssystemen: wanneer een agent “uitvoert” (systeemrecords schrijft, boekhouding wijzigt), botst hij direct op een hele reeks vragen: identiteit, credentiales, licentieplaatsen, goedkeuringsrechten — de organisatiestructuur wordt omgevormd tot een toegangskaart: “wie wat kan benaderen, wie wat mag autoriseren”. Deze twee beweringen zijn geen voorspellingen — het zijn feiten die al gebeuren in de projecten waarin investeerders op het front nu al investeren. (Gasten: a16z-partners / voormalige Microsoft-executives, VC-perspectief.)

Vijf: Controlelijst: Welk type “Conway-fout” maakt jouw organisatie?

Als je tot hier hebt gelezen en nog steeds denkt: “Ik begrijp al deze principes”, dan wil ik je een oefening laten doen.

Hieronder hebben we op basis van de wet van Conway en aanverwante onderzoeken vijf veelvoorkomende patronen van organisatie-architectuurmisfit samengevat. Vergelijk ze met jouw eigen bedrijf en kijk hoeveel er op jouw organisatie van toepassing zijn:

❶ Oppervlakkige microservices: De code is opgesplitst, maar 50 mensen ruziën nog steeds in één groep.
❷ Middenplatform-illusie: Het middenplatform is uitgegroeid tot een communicatieknelpunt voor alle bedrijfslijnen.
❸ AI-eilanden: De modellen die het AI-team produceert, kunnen niet worden geïntegreerd in de bedrijfsprocessen, omdat ze organisatorisch “niet op dezelfde lijn” zitten.
❹ Verslechtering van remote samenwerking: Fysieke isolatie leidt tot onnodige systeemfragmentatie.
❺ Slechte integratie na overname: Technische integratie mislukt door onverenigbare organisatieculturen.

Volgende stap

Dit is het eerste artikel van een serie van 15 over “Software engineering in het AI-tijdperk”. We beginnen met de wet van Conway en bouwen een fundamenteel inzicht op: organisatie-architectuur bepaalt systeem-architectuur — dit is geen metafoor, maar een empirisch bewezen causaal verband.

Maar het kennen van deze wet is slechts het begin. De echte vraag is: kunnen we dit omgekeerd toepassen? Door bewust een organisatiestructuur te ontwerpen die het gewenste systeemarchitectuur stimuleert — dit is de kern van de “Inverse Conway Maneuver”. In het volgende artikel, Team Topologies — een organisatieontwerpmethode voor de post-agile tijd, gaan we dieper in op hoe Matthew Skelton en Manuel Pais deze gedachte hebben uitgewerkt tot een volledige, praktische methode: met vier basis teamtypen, drie interactiemodellen en het zwaar onderschatte concept van “cognitive load”. Praktische case-studies van bedrijven als Netflix, Adidas en Accenture tonen aan: onder welke omstandigheden werkt de Inverse Conway Maneuver, en onder welke niet? — > Serietoelichting: Deze serie volgt continu de nieuwste ontwikkelingen in AI-programmeertools, organisatiestructuren en software-engineering paradigma’s, zoals de evolutie van Conway’s Wet in het AI-agent-tijdperk (2026) en de volwassenheid van de nieuwste tooling-ecosystemen. Volg deze serie voor continue inzichten. # Over deze serie

“De verandering van software engineering in het AI-tijdperk” is een diepgaande onderzoekserie van 15 delen, gericht op technische beslissers in bedrijven. Gebaseerd op een systematisch onderzoek van 200+ wetenschappelijke artikelen en industrierapporten, biedt het je beslissingsreferenties met expliciete bewijsniveaus. Meer content volgt binnenkort.

Referenties:

Conway, M. (1968). How Do Committees Invent? Datamation, 14 (4), 28-31.
Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
MacCormack, A., et al. (2012). Exploring the Duality between Product and Organizational Architectures: A Comparative Study of Commercial and Open Source Software. Harvard Business School Working Paper.
Nagappan, N., et al. (2008). The Influence of Organizational Structure on Software Quality. ICSE ‘08 Proceedings.
Forsgren, N., et al. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
Fowler, M. (2022). Conway’s Law. Martinfowler.com/bliki/ConwaysLaw.html.
Gartner (2025/26). Predicts 2026: AI Agents in Software Engineering.
a16z (2026). Software in the Age of Agents. The a16z Podcast. (Steven: “The biggest network effect in enterprise software is inside of a company” + Seema Amble over de observatie dat agents bij de toegang tot bedrijfssystemen botsen op rechten/credentiales/abonnementen; ondersteunt beweringen 1 en 2 in sectie 4; primaire bron: podcast-origineel. Standpuntmarkerings: a16z-partner / voormalig Microsoft-executief, VC-standpunt. Gasten geverifieerd: a16z Enterprise-team partner Seema Amble, voormalig Windows-voorzitter van Microsoft Steven Sinofsky (board partner), a16z-auteur Elena Burger; uitgezonden juli 2026.)