The Friday Agile Sync: Conway’s Law — Why Architecture Now Inherits Individuals, Not Teams

The architecture inherits the communication structure. The structure just got individual. AI-generated image

In 1968, a programmer named Melvin Conway published a paper in Datamation called “How Do Committees Invent?” It contained one sentence that has outlived almost every other piece of computer science writing from that decade: any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure. He meant it as an observation, not a prescription.

Fifty-seven years later, it is the closest thing software has to a physical law. In this installment of The Friday Agile Sync, we’ll look at Conway’s Law: what Conway actually said, why every serious Agile coach treats it as a milestone concept, what the Inverse Conway Maneuver is, and how Artificial Intelligence (AI) is doing something to Conway’s Law that the original paper could not have anticipated. The short version is this: AI has not broken Conway’s Law.

Disclosure: I used AI tools for research support and to generate the illustrations; the writing and analysis are my own.

AI has changed the unit the law applies to, and most organizations have not yet noticed. Conway’s Law has always operated at the team boundary because the team was the smallest unit that could produce a system. With AI assistance, the individual is now that unit.

Here is the argument I want you to sit with. The architecture of the system you ship is no longer just a mirror of how your teams communicate. It is also a mirror of how each AI-augmented individual thinks, prompts, and tools their work.

Conway’s Law just got personal, and the org design playbook most organizations are running is calibrated to a world where it wasn’t.

What Conway Actually Said

Strip the paper to its load-bearing claim and Conway said something almost stubbornly simple. If four groups of people work on a compiler, you will get a four-pass compiler. Not because four passes is the right architecture, but because four groups is the communication structure available to produce one.

The crucial word in Conway’s sentence is communication, not organization. Conway did not say systems mirror the org chart. He said systems mirror the communication structure.

Those two things can drift apart inside the same company, and when they do, the system tracks the communication structure every time. A team that shares no calendar, no Slack channel, and no review process with another team will produce an interface between their systems whether anyone designs that interface or not. The architecture is the negative space of who talks to whom.

That distinction matters because most people first encounter Conway’s Law as a critique of the org chart and decide they can fix it by redrawing the chart. They cannot. Redrawing the chart without changing how people actually communicate produces the same system with new boxes around it.

Conway’s Law keeps its grip on the system regardless of whether you accept the grip.

Why Conway’s Law Is a Milestone Concept for Agile Practitioners

In my coaching work, I have come to treat Conway’s Law as the moment an Agile practitioner stops thinking about teams as a productivity unit and starts thinking about teams as an architectural decision. That is a real promotion in the practitioner’s thinking. It is the line most coaches mark as the point at which someone has graduated from running ceremonies to influencing systems.

The reason is that almost every Agile anti-pattern that gets diagnosed as a “team problem” is actually a Conway’s Law problem in disguise. Cross-team dependencies that no one can resolve. Integration points that nobody owns.

Components get over-engineered because the team that owns them is too large for what it builds. Components get under-supported because the team is too small. Each of these reads like a staffing problem and is actually a communication-structure problem expressing itself as code.

This is why the eleventh Agile Principle, the one stating that the best architectures, requirements, and designs emerge from self-organizing teams, lands so much harder once Conway is in your head. The principle is not making an ideological claim about autonomy. It is making a Conway’s Law claim: the team that owns the design is the only team whose communication structure the design can mirror cleanly.

I have written about self-organizing teams as an architectural mechanism before, and the through-line connects directly to Conway. Self-organization is not a values move. It is an architectural one.

The promotion in thinking happens when a practitioner stops asking “how do we make this team faster” and starts asking “what system are we building, and is this team’s communication structure the right shape to produce it?” That second question opens the door to everything else.

The Inverse Conway Maneuver: Turning the Law Into a Tool

Once you accept that systems mirror communication structures, a tool falls out of the observation. If the architecture you want has a known shape, design your team structure to have that shape, and the architecture will follow. This is the Inverse Conway Maneuver, named in a 2010 ThoughtWorks essay by Jonny LeRoy and Matt Simons.

Amazon is the canonical example. The two-pizza team rule, which Jeff Bezos used to constrain team size, was not a productivity heuristic. It was an architectural commitment.

Small autonomous teams could only produce small autonomous services, and those services became Amazon Web Services. The microservices architecture that defines AWS is, in a precise sense, the shape of Amazon’s communication structure rendered as code. Sam Newman’s work on microservices and Martin Fowler’s writing on Conway’s Law both make this connection explicit, and neither author treats it as coincidence.

The Inverse Conway Maneuver became a foundational practice in the 2019 book Team Topologies by Matthew Skelton and Manuel Pais. Team Topologies offers four team types (stream-aligned, enabling, platform, and complicated-subsystem) and three interaction modes (collaboration, X-as-a-Service, and facilitating).

The entire framework is constructed around the premise that you can choose your architecture by choosing your team structure. The framework’s popularity in the last six years has done more to operationalize Conway’s Law than any single development since Conway’s original paper.

What practitioners often miss is that the Inverse Conway Maneuver is continuous, not one-shot. Communication structures drift. New hires reshape them.

Reorgs reshape them. Acquired companies bring their own. A team that started as a clean stream-aligned unit can become a complicated-subsystem team without anyone deciding it should, and the architecture will follow.

Holding the maneuver in place requires the same ongoing discipline that holding a backlog refined requires.

How AI Changed the Unit of Coupling

Now the part that is genuinely new. Conway’s Law has always operated at the team boundary because the team was the smallest unit capable of producing a system. One person could write a script.

One person could not produce a system. The cognitive bandwidth, the integration work, the testing surface, and the operational coverage required more than one human. So the smallest unit that mattered to Conway’s Law was the team.

That assumption is no longer safe. Faros AI’s Productivity Paradox Report, covering more than 10,000 developers across 1,255 teams in 2025, found that teams with high AI adoption completed 21 percent more tasks and merged 98 percent more pull requests. Core Innovation Capital’s 2025 analysis put the output multiplier at more than 5x per AI-capable engineer.

The HOLYWATER platform, a 55-million-user vertical streaming company, runs a 200-person team where only 10 percent of staff are coders. Gradient Labs, a UK AI startup, reached $1 million in annual recurring revenue in four months with a small team. The numbers vary, but the direction does not.

The individual now has the delivery capacity that, three years ago, required the team.

Here is what Conway’s Law does at that scale. The system the individual ships still mirrors a communication structure. But the communication structure being mirrored now includes the individual’s relationship with their AI tools, their prompt patterns, their style guide, the libraries their model gravitates toward, and the parts of the problem they decided to delegate.

That is not “the team’s communication structure.” That is the individual’s effective architecture, and the system inherits it.

The unit of coupling Conway described has gotten smaller. The law has not changed. What has changed is the addressable surface where the law applies.

If you used to need to look at the team to predict the architecture, you now need to look at the team and at the individual practices inside it. The architecture is a fractal of both.

The Structure Lag Conway’s Law Just Exposed

This is where the Conway’s Law argument compounds with the broader structural argument about AI capacity. I have argued elsewhere that organizations using AI to shrink are making a strategic error most won’t see for 12 to 18 months. The core of that argument is structural: leveling frameworks, spans of control, and headcount budgets were calibrated to pre-AI assumptions about individual output.

When the individual output ceiling moves and the structures don’t, organizations end up with people doing director-scale work inside individual-contributor structures. Conway’s Law sharpens that argument. The structural lag isn’t just an HR and accountability problem.

It is an architecture problem. When an AI-augmented engineer is doing what three engineers used to do, the system they produce inherits one person’s mental model, not three people’s debated and integrated mental models.

That can be a feature: faster decisions, cleaner internal consistency, less coordination tax. It can also be a bug: fewer perspectives in the architecture, more idiosyncratic patterns, a heavier dependence on a single person’s communication style.

The org design question is no longer “how many people do we need to build this?” The Conway question is “whose communication structure do we want this system to inherit?”

Those are different questions, and answering only the first one without answering the second is how organizations end up shipping systems they can’t maintain after the original engineer leaves.

Practical Patterns for Conway’s Law at Individual Scale

If Conway’s Law now applies at the individual level, the practitioner toolkit has to follow. Five patterns are worth lifting from current Team Topologies practice and adapting for the AI-augmented unit.

Map the actual communication graph, not the org chart. Inside Slack channels, code review patterns, and PR comment threads, the real communication structure is observable. The architecture you are about to ship is already implied by it.

If the graph looks like a hub-and-spoke around one senior engineer with AI assistance, your architecture will, too. That may be fine. It is not fine to discover it after deployment.

Treat each AI-augmented individual as a small team for architecture purposes. The prompt library that engineer uses is, in effect, their team’s working agreement. The tool choices they make are their stack decisions.

The style guide they prompt their model with is their team’s coding standard. Most organizations have governance for the team-level versions of these and no governance for the individual versions. The Inverse Conway Maneuver applied at the individual scale means treating these artifacts as architectural decisions, not personal preferences.

Manage cognitive load explicitly per individual, not just per team. Team Topologies makes cognitive load a first-class scheduling input at the team level. With AI scaling individual scope, the cognitive load on a single engineer can quietly exceed what one human can hold, even with the model carrying part of it.

The signal is not “are they shipping” but “could they explain the system they shipped six months from now without re-reading the model’s output.” If the answer is no, the architecture is already drifting away from a maintainable shape.

Hold the team-level Inverse Conway Maneuver more deliberately, not less. The temptation is to relax team structure because individuals are doing more. The right move is the opposite: tighter team-level intentionality, because the individual-level variance is now larger and the team is the only level at which it can be integrated.

The team’s job becomes less about production and more about integration of architecturally distinct individual outputs.

Build a review process that catches Conway drift at the individual layer. Code review historically caught quality issues and architectural deviations from team norms. With AI-augmented individuals, the new failure mode is architecturally consistent code that quietly imposes one person’s mental model on the team’s surface area.

The review needs a “whose communication structure is this inheriting” question alongside the standard quality checks.

The Pitfalls Practitioners Keep Hitting

Three failure modes show up in practice often enough to flag.

The first is treating Conway’s Law as solved by a reorg. A reorg changes reporting lines. It does not change communication structures unless the communication structures are explicitly redesigned alongside it.

Teams that have been reorged six times in three years usually have the same communication structure they started with, because the people who actually talk to each other have not changed, only the boxes around them have.

The second is assuming AI breaks Conway’s Law. I have heard versions of this in coaching conversations all year. The reasoning goes: if one engineer can produce what a team used to produce, then communication structures matter less, and Conway’s Law is less constraining.

The opposite is true. The law operates at a smaller unit now, and the variance between individuals’ effective communication structures is larger than the variance between teams used to be. The constraint is sharper, not looser.

The third is ignoring the maintenance horizon. A system built by a single AI-augmented engineer can be coherent, fast to ship, and beautifully internally consistent. It can also be a system that no other engineer in the organization can extend without first reverse-engineering the original engineer’s prompt patterns.

The Conway question at the maintenance horizon is “whose communication structure is the next engineer’s communication structure going to have to align with to extend this.” If that question has no good answer, the architecture is a hostage situation waiting to happen.

Final Thoughts: Conway’s Law Just Got Personal

Conway’s Law has always been the quiet rule under every architectural choice. The teams talked to each other, the system inherited the pattern, and the question for an Agile coach was how to use that observation, either to predict failure modes or to deliberately shape an architecture through team design.

That was the senior practitioner’s tool for two decades, and Team Topologies turned it into a framework anyone could pick up. The thing that has changed in 2026 is that the law’s smallest meaningful unit shrank.

The individual with AI assistance now has the production capacity that once required a team, and Conway’s Law operates on that unit just as cleanly as it ever operated on the team. The architectures the next decade ships will mirror the communication structures of AI-augmented individuals, not just AI-augmented teams.

That is not a small adjustment to org design. It is a new layer of architectural accountability that did not exist three years ago.

What makes this genuinely hard in practice is that it requires holding two levels of Conway’s Law at the same time. The team is still the unit at which integration happens, and so the team-level Inverse Conway Maneuver still matters. But the individual is now a unit at which architecture gets created, and most organizations have no governance, no review, and no language for that level.

Coaches and leaders who can hold both levels are going to be the ones who avoid the maintenance crises waiting at the other end of this productivity surge.

How has Conway’s Law shown up in the systems your team has shipped this year, and have you noticed any patterns yet that look like an AI-augmented individual’s communication structure rather than the team’s?

Feel free to share your experiences or examples in the comments. If you found this deep dive useful, please leave a clap, comment, or share it with your network, and don’t forget to subscribe for the next installment in our Friday Agile Sync series.

The Friday Agile Sync is a weekly series on foundational Agile topics to highlight the depths of Agile often overlooked and misunderstood.

Related Reading

Your Organization Is Using AI to Shrink. Your Competitors Are Using It to Build. The structural argument for redesigning organizations around expanded individual output, which this piece extends with the architectural-inheritance lens.

The Friday Agile Sync: Agile Principle #11, Self-Organizing Teams Unlock the Best Designs. Why the eleventh principle is, in retrospect, a Conway’s Law claim wearing a values framing.