conway (1968) tossed out the snarky theorem: any system mirrors the convo topology of the folks who built it. that’s the meme you quoted—“orgs ship their org chart.”

translation rn

• the way teams are sliced → the way the product gets sliced.

• every boundary you see in the hierarchy re-appears as an interface, api, or dumb gap in the thing that launches.

quick-n-dirty exemplars:

• windows vista era: a dozen semi-feudal “component teams” (shell, graphics, drivers …). shipped with a dozen seams—slow boot pipeline here, aero glitches there. vista ≈ microsoft’s head-count spreadsheet. lol.

• amazon microservice sprawl: each two-pizza squad owns its own tiny web service. result: retail site looks like 200+ mini-apps hot-glued by api gateways. healthy for deploy velocity, but users feel the latency matryoshka.

• legacy banks: mainframe core + middleware gang + “digital channel” tribe. you end up with mobile apps that call a middleware layer that screenscrapes cobol—three hops = three silos.

• nasa apollo: spacecraft was literally modular (command module, service module, lem), bc three different directorates owned budgets. fortunately physics didn’t mind.

• apple today: cross-functional “product pods” w hardware+sw+design in the same room. consequence: iphone feels monolithic—tight hw/sw coupling and few exposed knobs. that’s what a flat org looks like on silicon.

• startups pre-series-a: five ppl in a room → one big rails monolith. they reorganize into platform vs feature teams, suddenly the codebase fractures into micro-services nobody asked for.

afaict this law is undefeated; best you can do is game it—structure teams the way you want the system to look. idk, maybe heraclitus would shrug and say “structure becomes code; code becomes structure.” 🌀