Before We Begin

Your software architecture isn’t “designed” by your engineering team—it “grows” from your organizational structure. This 1968-era law is being repeatedly validated in the AI age.
Harvard Business School’s empirical research proves: organizational distance predicts software defect rates more accurately than code complexity. What you call “technical debt” is often, at its core, “organizational debt.”
Amazon’s microservices empire, Spotify’s squad model, Apple’s Siri deadlock—three trillion-dollar companies, utterly different fates, all illustrating the same law.
AI agents are now entering organizational charts. When the “nodes” in your team are no longer all human, Conway’s Law will be rewritten in ways you never anticipated.

In 1968, an obscure programmer wrote a paper that was rejected by Harvard Business Review for “failing to prove its argument.” Fifty-six years later, its central insight became a universally accepted law of software engineering—and in 2026, as AI reshapes everything, it matters more than ever.

I. How a Rejected Paper Became the “Law of Gravity” for Software Engineering

The Prophet Rejected by HBR

In April 1968, Melvin Conway published a deceptively plain paper in Datamation titled “How Do Committees Invent?”.
The paper’s core claim, distilled into a single sentence, is enough to keep any CTO awake at night:

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”

Put simply: Your company’s org chart is a direct mirror of your software architecture.

Conway illustrated this with a subtle case study. A company assigned eight people to build two compilers, split into two teams: one of five and one of three. The result? The five-person team built a five-stage compiler; the three-person team built a three-stage compiler. Not because the technical requirements demanded such divisions—but because each person needed to “own” their own unit of work.

Conway formalized this relationship as a homomorphism—a structure-preserving mapping between organizational structure and system design. This is no coincidence. No accident. It is a near-mathematical law.

Ironically, Conway originally submitted this paper to the Harvard Business Review, but it was rejected by editors for “failing to prove its argument.” Seven years later, Fred Brooks formally cited this insight in his classic book The Mythical Man-Month and named it “Conway’s Law.”
From then on, an observation rejected by a top business journal became one of the most widely cited laws in software engineering. ## Martin Fowler’s “Final Verdict”
If Conway was the Copernicus who proposed the hypothesis, then two decades of empirical research have been the telescope.
In 2022, Martin Fowler, Chief Scientist at ThoughtWorks, wrote a widely circulated assessment: “If there is one law in software architecture that all practitioners agree on, it is Conway’s Law. It is important enough to have influenced every system I’ve seen; it is powerful enough that anyone who tries to fight it is doomed to fail.”
This is not theoretical speculation from an ivory tower. Fowler has repeatedly observed the same phenomenon in hundreds of enterprise consulting engagements worldwide: the organizational chart is the shadow of the software blueprint—regardless of whether management realizes it.

There’s a subtle but critical nuance many miss: Fowler said “anyone who tries to fight it is doomed to fail,” not “anyone who tries to harness it.” What’s the difference? Fighting Conway’s Law means forcing architectural change without altering organizational structure; whereas harnessing it means first adjusting the organization so the architecture can “grow naturally.”
This distinction determines the success or failure of digital transformation initiatives. We’ll expand on the key strategy of “Inverse Conway Maneuver” in our next (Part 2) discussion on Team Topologies—essentially, it’s about leveraging, not fighting, this law.

II. From Lab to Battlefield: Three Studies Cement This Law

Harvard Business School’s “Mirroring Hypothesis”

In 2012, MacCormack and colleagues at Harvard Business School published a landmark study known in academia as the “Mirroring Hypothesis.”
Their methodology was elegant: they compared commercial software and open-source software that performed identical functions. The commercial software was developed by hierarchical corporate teams; the open-source software by loosely distributed communities.

The results align precisely with Conway’s Law: products developed by loosely coupled organizations are significantly more modular. Even when tightly coupled enterprise teams deliberately pursue modular design, their final systems still exhibit tight coupling patterns that mirror their organizational structure.

The organizational structure acts like a “gravitational field”—you can resist it temporarily, but over time, the system architecture will inevitably be pulled back into alignment with the organization’s structure.

What is the real implication for business decision-makers? When your engineering team repeatedly says, “We need to refactor,” what may truly need refactoring isn’t the code—but the organization. But how do you tell whether it’s “technical debt” or “organizational debt”? This requires a systematic diagnostic approach—and we’ll present a complete evaluation model in Article 12, “A Decision Framework for Adopting Enterprise AI Tools.”

Microsoft Research’s “Windows Vista Experiment”

In 2008, Nagappan and colleagues at Microsoft Research conducted a large-scale quantitative study on the Windows Vista project. They sought to answer a critical question: What factor best predicts bugs in software?

Candidate variables included: code complexity, lines of code, frequency of code changes, developer experience… and one variable that appeared unrelated to “technology”—organizational distance (i.e., the structural distance between teams developing related modules within the organization).

The research findings have unsettled many technocrats: organizational distance is a stronger predictor of software defect rates than code complexity. In other words, modules developed jointly by teams that are “far apart” on the organizational chart are more prone to bugs than modules with extremely complex code but maintained by tightly coordinated teams. What you assume are bugs caused by poor coding may actually stem from flawed organizational design.

The enterprise-level implications of this discovery run far deeper than they appear. It means — your QA strategy should follow your organizational structure, not your code complexity. Modules involving cross-team collaboration require stricter test coverage and review processes, even if the code itself looks simple. In today’s era of surging AI-generated code (Copilot now generates 46% of user-written code), this principle is more critical than ever — we’ll explore this in depth using Coinbase’s case study in Part 8, when we discuss the “productivity paradox.”

The “Accelerators” and “Hidden Risks” of the DORA Study

Led by Nicole Forsgren, Jez Humble, and Gene Kim, Google’s DevOps Research and Assessment (DORA) team has published the largest-ever study on software delivery performance.

The core finding aligns closely with Conway’s Law: “By implementing a loosely coupled, well-encapsulated architecture paired with a matching organizational structure, we can not only accelerate delivery velocity and stability, but also sustain linear or even super-linear productivity growth as engineering teams scale dramatically.” However, DORA’s 2022 report also uncovered a counterintuitive side effect: while loosely coupled architectures improve delivery efficiency, they may increase team burnout. The reason? When teams are highly autonomous and isolated from one another, members may lose sight of the broader purpose, developing a sense of “I’m just a cog.”

This is a crucial reminder—architecture-organization alignment is not a silver bullet; it solves efficiency problems but may create cultural ones. A thought-provoking implication: if loosely coupled architectures + loosely coupled organizations already make human developers feel isolated, what happens when AI agents join the team? AI won’t “feel isolated,” but humans will feel even more so. This dimension is rarely discussed, yet in our research materials, a BCG 2025 report introduces the “orchestration dilemma of middle managers”—which is also the central theme of our 11th piece.

III. The “Conway’s Law Moment” at Three Trillion-Dollar Companies

Amazon: The CEO Email That Changed Everything

Around 2002, Jeff Bezos issued the famous “API Mandate” internally at Amazon—requiring all teams to communicate exclusively through service APIs and strictly prohibiting direct access to other teams’ data stores. The final line of this email is reportedly: “Anyone who does not comply with the above will be fired.”

Many view Amazon’s microservices architecture as a technical decision. But from the perspective of Conway’s Law, what Bezos actually made was an organizational design decision: he first used management directives to cut off “shortcut communication” between teams, and the software architecture naturally evolved into isolated, autonomous service modules.

This later became Bezos’s concept of the “Two-Pizza Team”—each team sized no larger than what two pizzas could feed (typically 5–8 people), each owning its own service, deploying independently, and interacting with the outside world solely via APIs.

Amazon’s microservices empire was not designed by architects—it grew organically from its organizational structure. This is one of the most classic positive examples of Conway’s Law.

But there’s a layer many articles overlook: Amazon’s success didn’t just stem from Bezos understanding Conway’s Law—he also solved the “incentive alignment” problem. Each “two-pizza team” owned its own P&L (Profit & Loss statement), achieving not only technical autonomy but also business autonomy. This gave teams intrinsic motivation to maintain clear service boundaries—because blurred boundaries meant blurred accountability, and blurred accountability meant blurred performance evaluation. The triad of organizational structure + incentive structure + technical architecture is the full picture of Amazon’s model. Companies that copy only the organizational structure without mastering incentive design end up with the form but miss the essence.

Spotify: The Ideal Model vs. Reality’s “Entropy”

Spotify’s “Squad model” was once hailed in Silicon Valley as the bible of organizational design: autonomous squads of 5–8 people, multiple squads forming tribes, cross-tribe technical experts organized into chapters, and interest-driven communities forming guilds.
This model’s design aligns perfectly with Conway’s Law—using small, autonomous teams to drive the emergence of small, autonomous software services.

But Spotify later admitted that reality is far more complex than the model suggests. As the business scales, cross-team dependencies inevitably increase, and pure autonomy begins to generate coordination costs.
This reveals a frequently overlooked implication of Conway’s Law: organizational structure is not something you design once and forget—it, like software, has a tendency toward entropy. As business complexity grows, organizational boundaries blur, communication paths lengthen, and the system architecture degrades.
Outstanding technical organizations don’t just “design a good architecture”—they build the ongoing capability to align organization and architecture. We’ll expand on this capability in Part 2’s discussion of Team Topologies—a more systematic and actionable framework than Spotify’s model.

Apple: Why Siri Got “Crushed” by ChatGPT

Between 2024 and 2025, Apple’s Siri AI upgrade plan became almost a textbook counterexample of Conway’s Law.

The root of the problem is not technical. Apple possesses world-class AI research talent and abundant funding. But Siri’s development involves two teams with a structural rift in the organizational architecture: the AI Research team (led by John Giannandrea) and the Product Development team (led by Craig Federighi).

These teams have different priorities, different paces, and different definitions of success. The AI research team pursues frontier breakthroughs in model capabilities; the product team prioritizes stable, user-centric delivery. When the communication channels between these two organizational “nodes” are fractured, the resulting system inevitably becomes fractured too.

What did users ultimately get in Siri? A “patchwork mediocrity”—each module looks decent on its own, but when stitched together, it lacks a unified intelligent experience. This is precisely what Conway’s Law predicts: the cracks in the system mirror the cracks in the organization.

Apple’s case is especially worth attention for Chinese corporate decision-makers: Many enterprises are experiencing the exact same dilemma—AI teams and business teams report to different VPs, and AI deployment projects turn into “political battles between departments” rather than “collaborative product delivery.”

If your company is pushing for AI adoption, take a look back at your organizational chart: Is AI capability housed as a standalone department, or embedded within business teams? The answer to this question may matter more than which AI model you choose in determining project success.

IV. The AI Era: Conway’s Law Is Being Rewritten

When “Organizational Nodes” Are No Longer All Human

In 2026, Conway’s Law faces its most profound challenge since 1968. When Conway articulated this law, he operated under an implicit assumption: every “node” in an organization is human. Communication structures were defined by human-to-human interaction.

But today, AI agents are entering organizational charts. Claude Code autonomously completes multi-step development tasks; Stripe’s Minions system generates over 1,000 merged PRs per week; Cursor has transformed how 100% of NVIDIA’s engineers work. Gartner reports a 1,445% surge in enterprise inquiries about multi-agent AI orchestration by 2025.

What happens to Conway’s Law when some nodes in the organization are no longer human?

The exploration of this issue will span the second half of our series—Article 10 on the “One-Person Unicorn” phenomenon, Article 11 on “Conway’s Law Meets AI Agents,” and Article 14 on “Agentic Engineering”—but here are three preliminary judgments to help you build a conceptual framework:

First, communication structures will become strategy structures. Human-to-human communication relies on culture, tacit understanding, and informal exchanges. But between humans and AI agents, there is no “tacit understanding”—you must define interaction boundaries through explicit strategies, rules, and permissions. Governance capability will replace communication capability as the core variable in organizational design.

Second, organizational charts will become permission graphs. Traditional organizational charts depict reporting relationships and functional divisions. In the AI era, the “chart” resembles a directed acyclic graph (DAG) that defines capabilities and constraints—which agent can access which data, perform which actions, and under what conditions requires human approval.

Third, institutional knowledge will shift from people to strategies. In the past, “when the veteran leaves, the knowledge leaves” was every company’s pain point. In the future, critical knowledge will be encoded into AI agents’ strategies and contexts—this is both an opportunity (knowledge no longer leaks) and a risk (strategy errors may be systematically amplified).

Each judgment is backed by extensive industry practice and data. For instance, the third point on “institutional knowledge transfer” offers a dramatic cautionary tale through Klarna’s case—they laid off 40% of their staff, only to discover that their AI systems could not replicate the tacit knowledge lost with those employees, forcing them to rehire. We’ll fully unpack this story in Article 9, “The Klarna Lesson.”

The first and second judgments are not unique to us. In the July 2026 a16z podcast Software in the Age of Agents, a16z enterprise partner Seema Amble and former Microsoft Windows president Steven Sinofsky arrived at highly aligned conclusions based on frontline investment observations. Steven cut to the heart of judgment one in one sentence: “The biggest network effect in enterprise software is inside of a company” — the web of interpersonal relationships, processes, and systems within an organization is where true stickiness lies. Agents cannot plug into this web through “unspoken默契”; they require explicit strategies and permissions — this is the real-world force driving the shift from communication structures to strategic structures. Seema corroborated judgment two from the perspective of agent access to enterprise systems: when an agent attempts to “execute” (write to system records, alter financials), it immediately confronts an entire stack of issues — identity, credentials, billing seats, approval rights — as the organizational chart is being rewritten into a permission map: “Who can access what, and who authorizes what?” These are not predictions — they are already happening in the projects that frontline VCs are investing in. (Guests: a16z partners / former Microsoft executives, VC perspective.)

Five: Self-Check — What Kind of “Conway Error” Is Your Organization Making?

If you’ve read this far and still think, “I already understand all this,” then I invite you to do an exercise.

Below are five common patterns of “organization-architecture misalignment” we’ve distilled from Conway’s Law and its extended research. Cross-check them against your own company—how many hit home?

❶ Surface-level Microservices: Code is split up, but 50 people are still arguing in one group chat.
❷ Mid-platform Illusion: The mid-platform has become the communication bottleneck for every business line.
❸ AI Silos: AI team models can’t be integrated into business systems because, organizationally, they’re on different paths.
❹ Degraded Remote Collaboration: Physical separation has led to unnecessary system fragmentation.
❺ Poor Acquisition Integration: Technological integration fails due to incompatible organizational cultures.

Next Steps

This is the first of 15 articles in the series “Software Engineering Transformation in the AI Era.” Starting from Conway’s Law, we’ve established a foundational insight: Organizational structure determines system architecture—not as a metaphor, but as an empirically validated causal relationship.

But knowing this law is only the starting point. The real question is: Can we reverse-engineer it? By deliberately designing organizational structures to guide the desired system architecture—that’s the core idea of the “Inverse Conway Maneuver.” In the next post, Team Topologies—Organizational Design Methodology for the Post-Agile Era, we’ll dive into how Matthew Skelton and Manuel Pais transformed this concept into a complete, actionable methodology—including four fundamental team types, three interaction patterns, and the severely underappreciated concept of “cognitive load.” Real-world case studies from Netflix, Adidas, and Accenture will demonstrate: under what conditions the Inverse Conway Maneuver succeeds—and when it fails.

Series Note: This series will continuously track the latest evolution of AI programming tools, organizational structures, and software engineering paradigms—such as how Conway’s Law is evolving in the age of AI agents by 2026, and the maturity of emerging tool ecosystems. Follow this series for ongoing insights.

About This Series

“The Transformation of Software Engineering in the AI Era” is an in-depth research series designed for enterprise technology decision-makers, comprising 15 articles. Based on a systematic review of 200+ academic papers and industry reports, this series provides evidence-tiered decision-making references. Stay tuned for more content.

Sources:

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’s quote: “The biggest network effect in enterprise software is inside of a company”; Seema Amble’s observations on agent access to enterprise systems encountering permissions, credentials, and licensing seats — underpinning Claims 1 and 2 in Section 4; primary source — original podcast audio. Positioning: a16z partner / former Microsoft executive, VC perspective. Guests verified: a16z Enterprise Partner Seema Amble, former Microsoft Windows President Steven Sinofsky (board partner), a16z writer Elena Burger; aired July 2026.)