Learn it → Apply it → Save as Skill
Whatever system you build, it will end up shaped like the way your team talks to itself. Four groups that barely coordinate will ship four loosely joined parts, even if the whiteboard diagram shows one elegant whole. The org chart isn't just where the work happens — it quietly becomes the blueprint.
The Dr. Wallace's Favorite Mental Models library is designed to turn useful ways of thinking into reusable tools. Each model gives you a fast visual overview, deeper interactive learning, practical application exercises and an AI-ready Markdown skill you can save for future use.
Instead of merely reading about mental models, you can gradually build your own AI skills library: a collection of portable reasoning skills that can help ChatGPT, Claude, Grok and other AI assistants apply the mental models you value.
A group of people who design any complex system will, whether they intend to or not, produce a design whose structure mirrors how that group communicates. Tightly linked teams tend to produce tightly linked parts. Loosely linked teams tend to produce loosely linked parts.
Notice: nobody put "build a monolith" or "build four services" on a requirements doc. The communication pattern decided it anyway.
The model is most useful whenever a system is being designed, redesigned, split up, or merged, and more than one group of people will own a piece of it.
The method does not tell you the "correct" architecture. It tells you which architecture your current team structure is already steering you toward, whether or not anyone chose it on purpose.
Draw the real communication structure: who talks to whom daily, who reviews whose work, not the formal org chart on the wall.
Lay that map next to the system's current or planned structure. Where do the boundaries line up? Where do they not?
Wherever two groups rarely talk, expect a rigid interface, a slow handoff, or an outright seam in the system between their parts.
If a different architecture is genuinely needed, change the team structure and its ownership first. The system tends to follow, not lead.
Open a use case to see what the model changes about how you'd think it through.
Before drawing new service boundaries on a diagram, check whether the teams who will own each piece are already structured to work that independently. A diagram alone does not change who has to ask whom for permission to ship.
With one small, constantly-talking team, expect a single tightly woven codebase almost by default. That is not a mistake to fix early; it is what the team structure predicts, and it is usually fine at that stage.
Two companies rarely produce one clean combined system quickly, because their engineers do not yet have the daily working relationships that a truly unified system would require. Expect a federated result until the teams themselves are integrated.
If the platform team and each product squad rarely sync, expect the platform's interface to be rigid and general-purpose rather than tailored, because rigidity is what infrequent, low-bandwidth communication produces.
Decide the team structure you want the new system to have before the rebuild starts, not after. Architecture set early in a project is expensive to unwind once code and habits both harden around it.
A dataset with no single clearly responsible team tends to accumulate exactly what shared, low-communication ownership predicts: inconsistent naming, duplicate tables, and nobody confident enough to clean it up.
This is an illustrative case built on the pattern researchers have repeatedly documented, using a simplified fictional company to teach the method.
Expand for the research behind the model and how confident that research actually is.
Computer scientist Melvin Conway stated it in "How Do Committees Invent?", published in the April 1968 issue of the magazine Datamation. His original wording: organizations "which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."
No. Participants at the 1968 National Symposium on Modular Programming gave it that name after his paper circulated. Conway described a pattern; the field named it.
Researchers at MIT and Harvard Business School (Alan MacCormack, John Rusnak, and Carliss Baldwin) compared the modularity of commercial and open-source software products against the modularity of the organizations that built them, and found products built by more loosely coupled organizations were themselves more loosely coupled — a result often called the "mirroring hypothesis." Separately, a University of Maryland study with Microsoft (Nagappan, Murphy, and Basili, 2008) found organizational metrics predicted software failure-proneness better than many purely technical code metrics.
It is the deliberate strategy of restructuring teams first, specifically to steer the system toward a desired architecture, rather than waiting for architecture to drift into place on its own. The term is widely used in modern software and DevOps writing, notably popularized through the "Team Topologies" framework by Matthew Skelton and Manuel Pais.
The people who actually message, review, and block each other daily are the structure that matters. The reporting-line chart on the wall often lags far behind it.
Renaming teams or redrawing reporting lines does nothing on its own. The system follows who actually has to coordinate with whom to ship a change.
The same pattern shows up in any complex artifact built by multiple groups: a policy document, a curriculum, a physical product with several supplier teams.
Architecture lags organizational change by months or longer. A reorg from last quarter has not necessarily shown up in the codebase yet.
"That's just Conway's Law" can quietly become a way to avoid responsibility for a design that is genuinely fixable with better technical choices.
Team boundaries constrain the space of likely designs. They do not guarantee the design that results will actually be a good one.
the problem is a specific algorithm, a performance bottleneck, or a technology choice, and no structural or ownership boundary is actually involved.
a team is simply understaffed for the scope it owns. That is a capacity problem, not a communication-structure problem, even though the symptoms can look similar.
the mismatch sits between an internal team and an external vendor's system, where reorganizing your own team is not a lever that reaches the actual seam.
This browser tool structures your thinking. It does not send your information anywhere or perform AI analysis.
Save as Skill converts the model into portable Markdown instructions that teach an AI when and how to apply Conway's Law, what questions to ask, what evidence to seek, what mistakes to avoid and how to structure its analysis.
Save the skills you find useful and organize them into your own reusable library. The Markdown is intentionally model-neutral, so it can be used wherever an AI system accepts uploaded files, project knowledge, custom instructions or reusable text context. Platform capabilities differ, so this is a portable skill file rather than a claim of one-click installation.
Not entirely. Once a system exists, its structure makes some changes easy and others hard, and teams tend to reorganize around those existing seams over time. Later researchers have described this as a two-way relationship rather than a one-way rule: the org shapes the system, and the system, once built, quietly shapes how the org re-forms around it.
"Mirroring hypothesis" is the term researchers use for the testable, narrower claim that product modularity statistically correlates with organizational modularity. Conway's Law is the broader, older observation the hypothesis was built to test. In practice the two terms are often used interchangeably.
Structure tends to matter more than raw size. A team of thirty split into five clearly-bounded, loosely-communicating groups will tend to produce a more modular system than a team of ten that reviews every change together, even though the first team is larger.
It tends to sharpen it. Time zones, async communication, and fewer hallway conversations all lower the bandwidth between groups that aren't deliberately kept close, which the model predicts should push toward more separable, independently-shippable system boundaries.