A context map shows the technical integration between two bounded contexts, but it's also supposed to capture the relationship between the teams that own them. Why does that organizational dimension matter as much as the technical one, and how does it connect to Conway's Law?

## What the organizational dimension records The organizational dimension of a context map is the record, attached to each edge, of what kind of working relationship exists between the teams that own the two connected contexts — not just which side is upstream, but: - whether the teams **actively collaborate** on shared decisions; - whether **one dictates terms** and the other simply complies; - or whether they've **explicitly agreed to stay decoupled** and solve conflicts independently. This is distinct from direction: two contexts can have a clear upstream/downstream direction while the teams behind them either collaborate warmly on the contract or barely speak to each other, and those two scenarios produce very different day-to-day realities even though the technical direction on the map looks identical. ## Conway's Law This matters because of a well-known observation usually called **Conway's Law**: organizations that design systems are constrained to produce designs that mirror their own communication structure. In practice, this means a system's architecture is not purely an engineering artifact shaped by technical requirements — it's also a reflection, often an unconscious one, of who talks to whom, how often, and with what authority inside the company that built it. - Two teams that sit in different divisions, report up through different leaders, and rarely coordinate will tend to produce two systems with a poorly negotiated, ad hoc integration between them — duplicated logic, inconsistent semantics for the same business concept, brittle point-to-point calls — regardless of how technically skilled either team is individually, because the architecture is downstream of the communication gap, not the other way around. - Conversely, two teams that meet weekly and jointly own a roadmap tend to produce a cleanly negotiated contract between their contexts. ## Making the invisible layer visible The context map's job is to make this organizational layer visible on the same page as the technical layer, precisely because it's usually invisible in ordinary architecture documentation. An architecture diagram shows an HTTP call from Service A to Service B; it says nothing about whether Team A and Team B have ever had a real conversation about that call's contract, or whether it was reverse-engineered from a public endpoint because nobody responded to an integration request. Once that organizational relationship is written down next to the technical edge, it becomes usable **diagnostically**: a senior engineer looking at a persistently painful, frequently breaking integration can check whether the map shows a healthy collaborative relationship or a strained one, and very often the technical pain turns out to be a downstream symptom of an upstream organizational problem — the fix isn't a better API, it's establishing a regular sync between the two teams, or escalating a resourcing conflict. ## The inverse Conway maneuver This diagnostic use has a prescriptive counterpart known as the **inverse Conway maneuver**: since architecture tends to mirror communication structure, an organization can deliberately restructure teams, reporting lines, or standing meetings to produce the communication pattern it wants, in order to nudge the architecture toward a target shape. If leadership wants two systems to become one cleanly owned platform rather than two loosely integrated ones, merging the teams, or at minimum forcing regular joint planning, is often a more effective lever than any amount of top-down architectural mandate, because the org structure will eventually reassert itself over any architecture that fights it. ## The trade-off The trade-off in taking this organizational dimension seriously is that it turns some technical conversations into organizational ones, which are slower, more political, and outside a single engineer's authority to resolve — reorganizing teams requires management buy-in the mapping exercise itself can't produce, so surfacing the problem is necessary but not sufficient. There's also a risk of over-applying the diagnosis: not every integration pain point is a Conway's-Law symptom, and treating every technical problem as secretly organizational can become an excuse to avoid straightforward technical fixes. ## The failure mode The failure mode to watch for is a context map that records only the pleasant, official version of a team relationship — labeling everything a partnership because that's diplomatically comfortable — when the lived reality is that one team unilaterally dictates terms to an unwilling other. That kind of dishonest labeling defeats the map's purpose: - it hides exactly the organizational friction that would otherwise explain why an integration keeps breaking; - and it prevents the map from being used as evidence when someone finally needs to escalate a genuine authority conflict to leadership. ## A concrete scenario A concrete scenario: a Pricing team and a Checkout team integrate via an API that changes unpredictably, breaking Checkout every few weeks. On the surface this looks like an API-design problem; on the context map, it's visible that Pricing sits under a different leader with different priorities and the two teams have never had a standing sync — the real fix, once that's visible, is establishing a joint review process or escalating to get Pricing's roadmap to account for Checkout's needs, not another round of defensive coding in Checkout.