Shared Maps Beat Diverse Maps for Execution
In 1991, James March published a simulation of organizational learning, and understanding it was a turning point for me as a leader. He modeled an organization as a group of individuals plus a shared body of belief about how the world works. March named that shared belief the organizational code, in the sense of a legal code rather than anything you compile. Individuals learn from it. It learns back from them. When everyone adapts to it quickly, the group converges fast and then stops getting smarter, because a shared belief can only learn from the people who still disagree with it.
The tension is right there. Convergence is what makes a group fast. Divergence is the only thing that keeps it correct.
For the rest of this piece I am going to call it a map.
What the map actually contains#
A team’s map is not its values poster. It is the set of questions the team has stopped arguing about. Where validation belongs. What “done” means when someone moves a ticket. Whether a nullable column is a modeling failure or a reasonable escape hatch. Whether a comment in review is blocking or a preference. Whether you reach for an abstraction on the second occurrence or the third.
None of those have universally correct answers. That is exactly why they need to be settled locally. A team that has settled them can act without checking. A team that has not settled them pays for the ambiguity on every single change.
An example of this might be duplicated validation. The same rule enforced in the controller, again in the service layer, and again as a database constraint. Nobody designed that as defense in depth. Three people held three different beliefs about whose responsibility it was, each wrote the check where their map said it belonged, and the reviewers had no shared standard to reject any of them. The result reads like an architectural decision. It is actually three private maps leaving sediment in the same file tree.
Why sameness is fast#
The research on this is older and more settled than most engineers realize. Work by Stout, Cannon-Bowers, and Salas in the late nineties found that teams with more convergent mental models coordinated better under high workload, and did it while communicating less. Mathieu and colleagues followed in 2000 with evidence that convergence on both the task and the team itself predicted performance through improved process, and a later meta-analysis by DeChurch and Mesmer-Magnus found the effect holds broadly across team types.
The mechanism is not mysterious. A shared map is what lets you skip the conversation. When two people already agree that errors surface at the boundary and never in the middle, one of them can write that code and the other can review it in four minutes. When they disagree and neither knows it, the same change costs a review cycle, a thread, a synchronous call, and a rewrite. That cost does not show up on any roadmap. It shows up as a team that feels busy and ships slowly.
This is why treating alignment as a nice-to-have gets the accounting backwards. The hours spent building shared belief are not overhead sitting on top of the work. They are the substrate the work runs on. A team with a thin map is not saving time by skipping that investment. It is deferring the cost into every future change, at a worse exchange rate, forever.
Why sameness eventually kills you#
Maps go stale because territory moves. The traffic pattern that justified your caching strategy changes. The library you standardized on gets abandoned. The service boundary that was clean at four engineers is a coordination bottleneck at fourteen. The map was right. Now it is wrong, and nothing about the map itself will tell you that.
The signal arrives as friction. Someone new pushes back on a convention. Someone senior gets a bad feeling about a pattern they helped establish. Someone asks why we do it this way and the honest answer turns out to be that it was decided under conditions that no longer hold and nobody has revisited it.
That friction is the only update mechanism you have. This is March’s actual punchline, and it is sharper than the usual pitch for diversity. He was not arguing that different perspectives are pleasant or morally good. He showed that fast socialization improves the individual and degrades the organization, because a map that everyone has fully absorbed has no remaining source of new information. The people who have not converged are the sensors.
Simon Wardley arrived at the same pairing from a different direction. His doctrine puts “use a common language” and “challenge assumptions” side by side as principles that only work together, and he has been direct that challenging assumptions requires enough psychological safety that people will actually do it. A shared map with no mechanism for dissent is not alignment. It is a group that has stopped noticing.
Running both without tearing yourself apart#
The resolution is not balance. It is separation. These are two different activities, and the mistake most teams make is running them in the same room at the same time.
Execution mode is conformist on purpose. The map is treated as settled. Disagreement about settled questions gets deferred, not litigated, because the throughput gain from not relitigating is the entire reason you built the map.
Map-updating mode is where deviation is the point. It needs its own venue, its own cadence, and enough time that people bring real objections rather than only the ones cheap enough to raise in passing. What that looks like depends entirely on the team. The shape matters far less than two things being true, that the venue exists and that people believe raising something there will actually change the map.
What connects the two is triage. Every disagreement that surfaces during execution is one of two things. It is a preference, in which case the answer is to conform and move, and nobody should feel bad about that. Or it is a claim that the map is wrong, in which case it belongs in the other mode with a real hearing. The discipline is asking which one it is out loud, in the moment, rather than either suppressing it or letting it derail the change in front of you.
Making the map explicit is what allows any of this to happen. A map that lives only in the heads of the longest-tenured people is not shared. It is transmitted by apprenticeship, slowly, and it is unfalsifiable, because you cannot argue with something that has never been stated. Architecture decision records are one version of this, sitting at the formal end of the range. A short conventions file in the repo sits at the other. What earns its keep is not the format but the surface it creates, something concrete enough to push against, that captures not just what was decided but what was true at the time it was decided. That second part is what lets someone later say the territory has moved without it landing as an accusation that anyone was wrong.
The map is an artifact you maintain, with the same properties as any other artifact. It accumulates entropy. It picks up decisions that made sense under constraints that no longer exist. It benefits from being refactored on purpose rather than patched under pressure.
Starting tomorrow#
The next time you write a review comment that is not about correctness, stop and ask whether the thing you are asking for is written down anywhere. If it is, link it, and the review takes ten seconds. If it is not, you have just found an unmapped area, and you have two honest options. Put it on the map, or drop the comment. What you should not do is enforce a map that only you can read, because that is how a team ends up with a map nobody chose and nobody can revise.
Sources#
- James G. March, “Exploration and Exploitation in Organizational Learning,” Organization Science 2(1), 1991. The origin of the organizational code argument and the finding that fast socialization improves individual knowledge while degrading collective learning.
- Renée Stout, Janis Cannon-Bowers, Eduardo Salas, and Dana Milanovich, “Planning, Shared Mental Models, and Coordinated Performance,” Human Factors 41, 1999.
- John Mathieu et al., “The Influence of Shared Mental Models on Team Process and Performance,” Journal of Applied Psychology 85(2), 2000.
- Leslie DeChurch and Jessica Mesmer-Magnus, “Measuring Shared Team Mental Models: A Meta-Analysis,” 2010.
- Simon Wardley on doctrine, particularly “use a common language” and “challenge assumptions.” His original doctrine post is at blog.gardeviance.org.
- Susanne Kaiser, Architecture for Flow: Adaptive Systems with Domain-Driven Design, Wardley Mapping, and Team Topologies (Addison-Wesley, 2025 edition; originally published 2023). The book that explicitly connects team topologies to maps.
- Matthew Skelton and Manuel Pais, Team Topologies (IT Revolution, 2019), for the team-boundary and cognitive-load half of the picture.