Innan vi börjar

Din programvaruarkitektur är inte “designad” av ditt teknikteam — den “växer fram” ur din organisationsstruktur. Den lag som formulerades 1968 bekräftas återigen i AI-eran.
Harvard Business Schools empiriska studier visar: organisationsavstånd förutspår programvarufel mer exakt än kodkomplexitet. Det du tror är “teknisk skuld” är i grunden “organisationsskuld”.
Amazons mikrotjänstimperium, Spoticys teammodell, Apples Siri-kris — tre företag med trillioner i marknadsvärde illustrerar samma lag med helt olika öde.
AI-agenter kommer nu in i organisationsdiagrammet. När “noder” i ditt team inte längre är endast människor, kommer Conway’s lag att skrivas om på ett sätt du inte förutsett.

1968 skrev en okänd programmerare en artikel som avvisades av Harvard Business Review med motiveringen “ej bevisad”. 56 år senare är dess kärnidsé den allmänt accepterade lagstiftningen inom mjukvaruutveckling — och i AI-omskapade 2026 är den viktigare än någonsin.

1. Hur en avvisad artikel blev mjukvaruengineeringens “gravitationslag”

Den profet som HBR avvisade

I april 1968 publicerade Melvin Conway en artikel med ett lugnt titel i tidskriften Datamation: »How Do Committees Invent?«.
Kärnan i artikeln är bara en mening – men den är tillräcklig för att få någon CTO att ligga vaken natten igen:

»Organisationer som designar system genererar design som är isomorf med deras kommunikationsstrukturer.«
Översatt till vardagligt språk: Din organisationsstruktur är en spegelbild av din programvaruarkitektur.
Conway beskrev i artikeln ett elegant exempel: Ett företag tilldelade åtta personer till två grupper för att bygga två kompilatorer – en grupp med fem och en med tre. Resultatet? Femmannagruppen producerade en femstegskompilator, tremannagruppen en trestegskompilator. Det var inte på grund av tekniska krav på uppdelning – utan eftersom varje person behövde »äga« sin egen arbetsenhet.
Conway beskrev detta förhållande som en »homomorfi« – en strukturbehållande avbildning mellan organisationsstruktur och systemsdesign. Det är inte en slump, inte en tillfällighet – utan en nästan matematisk nödvändighet.

Ironiskt nog skickade Conway ursprungligen denna artikel till Harvard Business Review, men den avvisades av redaktören med motiveringen att “argumentet inte var bevisat”. Sju år senare citerade Fred Brooks detta perspektiv i sin klassiska bok The Mythical Man-Month och namngav det formellt som “Conways lag”.
Från och med då blev en observation som avvisats av de främsta affärstidningarna en av de mest citerade lagarna inom mjukvaruengineering.
## Martin Fowlers “dödsdom”
Om Conway var Copernicus som formulerade hypotesen, så är de empiriska studierna av de senaste tjugo åren teleskopet.
2022 skrev Martin Fowler, ThoughtWorks chef för vetenskaplig forskning, en kommentar som spridits bredt i branschen: “Om det finns en enda princip inom mjukvaruarkitektur som alla praktiserande erkänner, så är det Conways lag. Den är tillräckligt viktig för att ha påverkat varje system jag sett; den är tillräckligt kraftfull för att alla som försöker motstå den kommer att misslyckas.”
Det här är inte en teoretisk spekulation från en akademikers torn. Fowler har i hundratals konsultationsuppdrag över hela världen sett samma fenomen igen och igen: organisationsdiagrammet är en skugga av mjukvarubladet, oavsett om ledningen är medveten om det eller inte.

Här finns en subtil men avgörande nuans som många missar: Fowler säger “alla som försöker motstå den är fördömda att misslyckas”, inte “alla som försöker utnyttja den”. Vad är skillnaden? Att motstå Conways lag innebär att tvinga genom arkitektoniska förändringar utan att förändra organisationens struktur; att utnyttja den innebär att först anpassa organisationen så att arkitekturen kan “växa naturligt”.
Den här skillnaden avgör framgång eller misslyckande hos digitala transformationsprojekt. I den följande andra delen, där vi diskuterar Team Topologies, kommer vi att utförligt gå igenom den avgörande strategin “Inverse Conway Maneuver” — som i sin kärna handlar om att utnyttja, inte motstå, denna lag.

II. Från laboratoriet till slagfältet: Tre studier bekräftar denna lag

Harvard Business Schools “mirroring-hypotes”

2012 publicerade MacCormack och andra vid Harvard Business School en omfattande studie som akademisk värld kallar “mirroring-hypotesen”.

Metoden var mycket smart: De hittade kommersiella och öppen källkodsprogramvaror som utförde exakt samma funktioner och jämförde dem. Kommeriell programvara utvecklades av hierarkiska företagsteam, medan öppen källkod utvecklades av löst sammanlänkade communitys.

Resultaten stämmer överens med Conway’s lag: produkter utvecklade av löst kopplade organisationer är tydligt mer modulära. Tätt kopplade företagsteam, även om de aktivt strävar efter modulär design, levererar system som ändå visar de tätt kopplade egenskaperna som speglar deras organisationsstruktur.

Organisationsstruktur fungerar som ett “gravitationsfält” – du kan motstå det tillfälligt, men över tid kommer systemarkitekturen att dras tillbaka till en form som är isomorf med organisationens struktur.

Vad är den verkliga insikten för beslutsfattare i företag? När dina teknikteam upprepat säger “vi behöver refaktorera”, är det kanske inte koden som behöver refaktoreras – utan organisationen. Men hur avgör man om det är “teknisk skuld” eller “organisationskuld”? Det kräver ett systematiskt diagnostiskt ramverk – vilket vi presenterar i artikel 12, “Ramverk för beslutsfattande kring antagande av AI-verktyg i företag”.

Microsoft Researchs “Windows Vista-experiment”

2008 genomförde Nagappan och andra vid Microsoft Research en omfattande kvantitativ studie av Windows Vista-projektet. De försökte besvara en nyckelfråga: Vilken faktor förutsäger bäst fel (bugs) i mjukvara?

Kandidaterna inkluderade: kodkomplexitet, antal kodrader, frekvensen för kodändringar, utvecklarens erfarenhet… samt en variabel som verkar orelaterad till “teknik” – organisationsavstånd (det vill säga avståndet mellan team som utvecklar relaterade moduler i organisationens struktur).

Forskningsresultaten orsakar oro bland många teknikmaximalister: Organisationsavstånd förutspår mjukvarufelrate bättre än kodkomplexitet. Med andra ord: en modul som utvecklas av två team som är “långt ifrån varandra” i organisationsstrukturen har större chans att ha buggar än en mycket komplex modul som underhålls av ett tätt samarbetande team. Du tror att buggarna beror på dålig kod – men de kan i själva verket bero på en dålig organisationsdesign.

Denna upptäckt har djupare organisationella konsekvenser än det ser ut för. Den innebär att — din QA-strategi ska följa organisationsstrukturen, inte kodkomplexiteten. Moduler som involverar två team kräver striktare testdekning och granskning, även om koden själv verkar enkel. I dagens värld, där AI-genererad kod exploderar (Copilot genererar nu 46 % av användarnas kod), blir denna princip ännu viktigare — vi kommer att utförligt utforska detta med Coinbase som exempel i artikel 8, när vi diskuterar “produktivitetsparadokset”.

DORA-studien: “Acceleration” och “dolda faror”

DevOps Research and Assessment (DORA)-teamet, som ägs av Google och leds av Nicole Forsgren, Jez Humble och Gene Kim, har publicerat den största studien någonsin om mjukvaruleveransprestanda.

Kärnupptäckten stämmer väl överens med Conway’s lag: “Om vi implementerar en arkitektur med lös koppling och god inkapsling, kombinerad med en matchande organisation, kan vi både öka leveranshastigheten och stabiliteten samt uppnå linjär eller till och med superlinjär produktivitetsökning när ingenjörsteamen expanderar kraftigt.” Men DORA:s rapport från 2022 upptäckte också en fascinerande bieffekt: även om lös koppling förbättrar leveranseffektiviteten, kan den öka utmattning hos teamen. Orsaken kan vara att när team är högt autonomt och isolerade från varandra, kan medlemmar förlora känslan av den större bilden och uppleva en isolerad känsla av “jag är bara en kugg”.

Detta är en viktig påminnelse — arkitektur- och organisationsalignering är inte en silverkula; den löser effektivitetsproblem, men kan skapa kulturella problem. En fascinerande slutsats: om lös koppling i arkitektur och organisation redan gör människliga utvecklare känsliga för isolation, vad händer när AI-agenter läggs till i teamen? AI:er “känner” inte isolation, men människor blir ännu mer isolerade. Denna dimension diskuteras sällan, men i våra undersökningsmaterial nämner en BCG-rapport från 2025 “mellannivåledarnas koordineringsdilemma” — vilket också är kärnan i vår elfte artikel.

Tre: Tre trilliondollarsföretagens “Conway-moment”

Amazon: En e-post från CEO:n som förändrade allt

Cirka 2002 skickade Jeff Bezos den berömda “API-mandatet” inom Amazon — alla team måste kommunicera via servicegränssnitt (API), och det var förbjudet att direkt komma åt andra teams datalagring.
Den sista punkten i denna e-post ska enligt rykten ha varit: “Personer som inte följer dessa regler kommer att avskedas.”
Många ser Amazons mikrotjänstararkitektur som ett tekniskt beslut. Men ur康威-lagen synvinkel gjorde Bezos ett organisationellt beslut: han tvingade först till en slut på “kortvägskommunikation” mellan team genom ledarskap, och därefter utvecklades programvaruarkitekturen naturligt till isolerade tjänstmoduler.

Detta ledde till Bezos’ senare koncept av “två-pizzateam” — varje team är inte större än vad två pizzor kan mata (vanligtvis 5–8 personer), varje team äger sin egen tjänst, distribuerar självständigt och interagerar med omvärlden via API.
Amazons mikrotjänstepalats är inte ritat av arkitekter — det växte fram ur organisationens struktur. Detta är ett av康威-lagens mest klassiska positiva exempel.

Men här finns en aspekt som många artiklar inte nämner: Amazons framgång beror inte bara på att Bezos förstod Conway’s lag, utan också på att han samtidigt löste problemet med “incitamentsavstämmning”. Varje “två-pizza-team” har sin egen P&L (resultaträkning), och de är inte bara tekniskt autonomt, utan också affärsmässigt autonomt. Det innebär att teamen har ett inre drivkraft att hålla klara servicegränser – eftersom suddiga gränser innebär suddig ansvarsfördelning, och suddig ansvarsfördelning innebär suddig prestationsevaluering. Triangeln mellan organisationsstruktur, incitamentsstruktur och teknisk arkitektur är den fullständiga bilden av Amazons modell. Företag som bara lär sig organisationsstruktur utan incitamentsdesign får bara formen, inte själen. ## Spotify: Den ideala modellen möter verklighetens “entropi” Spoticys “Squad-modell” betraktades en gång i Silicon Valley som den heliga skriften för organisationsdesign: självstyrda småteam (Squads) på 5–8 personer, som sammanfogas till stammar (Tribes), med tekniska experter över stammar som kapitel (Chapters), och intressedrivna gemenskaper som gilden (Guilds). Denna modells designfilosofi är högst konsistent med Conway’s lag – genom små, autonomt strukturerade team drivs fram små, autonomt fungerande mjukvarutjänster.

Men Spotify själva erkände senare att verkligheten är mycket mer komplex än modellen. När affären växer till en viss skala ökar beroenden mellan team oundvikligen, och ren autonomi börjar skapa koordineringskostnader.
Det avslöjar en ofta förbigången konsekvens av Conway’s Law: organisationens struktur är inte något som designas en gång och sedan är det klart — den har, precis som mjukvara, en tendens till ökad entropi. Med ökande affärskomplexitet suddas organisationsgränser ut, kommunikationsvägar längs, och systemarkitekturen degraderas.
En utmärkt teknisk organisation är inte “den som designade en bra arkitektur”, utan den som byggt upp förmågan att kontinuerligt justera organisationens avstämmning med arkitekturen. Denna förmåga kommer vi att utforska i del 2 om Team Topologies — den erbjuder ett mer systematiskt och praktiskt ramverk än Spottify-modellen.

Apple: Varför Siri blev “slagen” av ChatGPT

Under 2024–2025 blev Apples Siri AI-uppdateringsplan nästan en “anti-exempel” på Conway’s Law.

Problemet ligger inte i tekniken. Apple har världsklass AI-forskare och omfattande finansiering. Men utvecklingen av Siri involverar två team med strukturella klyftor i organisationen: AI-forskningsteamet (leds av John Giannandrea) och produktutvecklingsteamet (leds av Craig Federighi).

De två teamen har olika prioriteringar, olika tempo och olika mått för framgång. AI-forskningsteamet strävar efter framsteg inom modellens kapacitet, medan produktteamet fokuserar på stabil och pålitlig användarupplevelse. När kommunikationsstrukturer mellan dessa två organisationella “noder” är brustna, blir det resulterande systemet också brustet.

Vad får användaren i slutändan? En “funktionell patchwork-assistent” – varje modul verkar fungera, men tillsammans saknar de en sammanhängande intelligent upplevelse. Detta är exakt det som Conway’s lag förutspådde: Systemets klyftor speglar organisationens klyftor.

Apples fall är särskilt relevant för kinesiska företagsledare. Många företag genomgår just nu exakt samma utmaning – AI-team och affärsteam ligger under olika VP:ar, och AI-implementeringsprojekt blir “politiska krig mellan två avdelningar” snarare än “samarbetsbaserad produktleverans”.

Om ditt företag driver AI-implementation, titta tillbaka på din organisationsstruktur: Är AI-kompetens en separat avdelning, eller är den integrerad i affärsteam? Svaret på den frågan kan vara mer avgörande för projektets framgång än vilken AI-modell du väljer.

Fyra: AI-epoken: Conway’s lag skrivs om

När “organisationsnoder” inte längre är endast människor

2026 står Conway’s lag inför sin djupaste utmaning sedan 1968. När Conway formulerade laget, förutsatte han en dold förutsättning: varje “nod” i organisationen är en människa. Kommunikationsstrukturer är människors kommunikation.

Men idag kommer AI-agenter in i organisationsdiagrammet. Claude Code kan självständigt genomföra flerstegsutvecklingsuppgifter, Stripe:s Minions-system producerar över 1000 sammanfogade PR:er varje vecka, och Cursor har förändrat sättet att arbeta för 100 % av NVIDIA:s ingenjörer. Gartners rapport visar att konsultfrågor om fleragent-AI-koordinering ökade med 1445 % år 2025.

Vad händer med Conway’s lag när vissa noder i organisationen inte längre är människor?

Denna frågas utveckling kommer att genomföra hela vår serieens andra halva — artikel 10 om “ensam unicorn”-fenomenet, artikel 11 om “Conways lag möter AI-agenter”, artikel 14 om “Agentic Engineering” — men här är tre preliminära bedömningar för att bygga ett tänkande ramverk:

Först: Kommunikationsstrukturer blir strategistrukturer. Människors kommunikation bygger på kultur, förståelse och informella interaktioner. Men mellan människor och AI-agenter finns inget “förstånd” — du måste definiera interaktionsgränser genom tydliga strategier, regler och behörigheter. Governanskapacitet ersätter kommunikationskapacitet som central variabel i organisationsdesign.

Andra: Organisationsdiagram blir behörighetsdiagram. Traditionella organisationsdiagram beskriver rapporteringsrelationer och funktionell uppdelning. I AI-eran är “diagrammet” mer som en riktad acyklisk graf (DAG), som definierar kapaciteter och begränsningar: vilken agent som kan komma åt vilka data, utföra vilka åtgärder, och under vilka villkor som människlig godkännande krävs.

Tredje: Institutionellt kunskap flyttas från människor till strategier. Tidigare var “när en erfaren medarbetare går, tar han/hon kunskapen med sig” en smärta för alla företag. I framtiden kommer nyckelkunskap att koda in i AI-agenteras strategier och kontexter — detta är både en möjlighet (kunskap förloras inte längre) och ett risk (felaktiga strategier kan förstärkas systemiskt).

Varje påstående stöds av omfattande branschpraxis och data. Till exempel ger fallet med Klarna en dramatisk både positiv och negativ lärdom för det tredje påståendet om “institutionellt kunskapsöverföring” — efter att de frisatt 40 % av sina anställda upptäckte de att AI-systemet inte kunde hantera den implicita kunskap som försvann med de frisatta anställda, och var tvungna att anställa igen. Den här historien utvecklas fullständigt i artikel 9, “Klarna-läxan”.

Den första och andra bedömningen delas inte bara av oss. I a16z-podden ”Software in the Age of Agents” från juli 2026, kom Seema Amble, partner i a16z’s enterprise-team, och Steven Sinofsky, tidigare chef för Windows hos Microsoft, fram till högst konsensbaserade slutsatser baserat på sina direkta investeringsobservationer. Steven sammanfattade kärnan i bedömning ett med en enda mening: ”The biggest network effect in enterprise software is inside of a company” — den nätverksstruktur som skapas av människor, processer och system inom en organisation är det verkliga klistret. Agents kan inte ansluta till detta nätverk genom ”förståelse” — de kräver tydliga strategier och behörigheter — och det är den praktiska kraften bakom ”kommunikationsstruktur blir strategistruktur”. Seema bekräftade bedömning två från perspektivet av agents som tillgår enterprise-system: när en agent ska ”utföra” en åtgärd (skriva till systemloggar, ändra bokföring), stöter den omedelbart på en hel kedja av frågor — identitet, autentisering, betalningsplatser, godkännandebefogenheter — organisationsdiagrammet omvandlas till en behörighetsgraf: ”Vem kan komma åt vad, och vem godkänner vad?” Dessa två bedömningar är inte framtidsprognoser — de är saker som redan sker i de projekt som venturekapitalister just nu investerar i. (Gäster: a16z-partner / tidigare Microsoft-exekutiv, VC-perspektiv.)

Fem: Kontrolllista: Vilken typ av “Conway-fel” begår din organisation?

Om du har läst hit och fortfarande tycker “jag förstår alla dessa principer”, vill jag att du gör ett övning.

Här är fem vanliga mönster för “organisation-arkitektur-misalignment” som vi sammanfattat baserat på Conways lag och dess utvidgade forskning. Jämför med din egen organisation och se hur många som träffar:

❶ Ytliga mikrotjänster: Koden är uppdelad, men 50 personer fortsätter att skrika i samma Slack-grupp.
❷ Mid-platform-illusionen: Mid-platformen har blivit kommunikationsbarriären för alla affärslinjer.
❸ AI-öar: AI-teamets modeller kan inte integreras i affärssystemen – för att de är organisationellt separerade.
❹ Nedsatt fjärrsamarbete: Fysisk isolering har lett till onödiga systemfragmenteringar.
❺ Akkvistionssvårigheter: Teknisk integrering misslyckas på grund av kulturell inkompatibilitet.

Nästa steg

Detta är den första av 15 artiklar i serien “Programvaruengineering i AI-tiden”. Vi utgår från Conways lag och etablerar en grundläggande insikt: Organisationsarkitektur bestämmer systemarkitektur – det är inte en metafor, utan en empiriskt verifierad orsakssamband.

Men att känna till denna lag är bara början. Det verkliga frågan är: Kan vi använda den i omvänd riktning? Genom bewusst att designa organisationer för att leda mot önskade systemarkitekturer – detta är kärnan i “Inverse Conway Maneuver”. I nästa artikel, Team Topologies – en organisationsdesignmetodik för efter-agil tid, undersöker vi hur Matthew Skelton och Manuel Pais utvecklade denna idé till en komplett, praktisk metodik med fyra grundläggande teamtyper, tre interaktionsmönster och konceptet “kognitiv belastning”, ett övergått och underskattat begrepp. Praktiska fallstudier från företag som Netflix, Adidas och Accenture visar: Under vilka villkor fungerar Inverse Conway Maneuver, och när misslyckas den? — > Serienotis: Denna serie följer kontinuerligt den senaste utvecklingen inom AI-programmeringsverktyg, organisationsarkitektur och programvaruengineeringparadigm, till exempel hur Conway’s Law förändras i AI-agenternas tid år 2026 och mognaden i den senaste verktygsekosystemet. Prenumerera på serien för kontinuerliga insikter. # Om denna serie

“AI-tidens förändringar inom mjukvaruutveckling” är en djupgående forskningsserie riktad till tekniska beslutsfattare i företag, bestående av 15 artiklar. Baseras på systematisk analys av 200+ akademiska artiklar och branschrapporter, och ger dig beslutsunderlag med evidensnivåer markerade. Fler innehåll kommer snart.

Källor:

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 om agenter som stöter på behörigheter, autentiseringsuppgifter och licenser när de försöker komma åt företagssystem — stöder påståenden 1 och 2 i avsnitt 4; primärkälla — podcastens ursprungliga ljud. Ståndpunkt: a16z-partner / tidigare Microsoft-exekutiv, VC-perspektiv. Gäster verifierade: a16z-enterprisepartner Seema Amble, tidigare Windows-president vid Microsoft Steven Sinofsky (board partner), a16z-skrivare Elena Burger; sändes juli 2026.)