Technical Decisions Are Territory
metaphor
Source: Governance → Decision-Making
Categories: organizational-behaviorsoftware-engineering
Transfers
This is our codebase. That is your codebase. Don’t push changes to our repo without talking to us first. The territorial metaphor for technical decision-making is so pervasive that engineers rarely notice they are using it. But it structures organizational behavior in powerful ways: it determines who gets consulted, who gets to veto, and whose opinion counts as authoritative.
Key structural parallels:
- Ownership as sovereignty — a team “owns” a service the way a nation-state owns its territory. Ownership confers the right to make unilateral decisions about what happens within the boundary. Code review norms enforce this: changes to someone else’s service require their approval, just as territorial sovereignty requires consent for foreign intervention. The CODEOWNERS file is literally a territorial map.
- Scope as jurisdiction — a team’s technical authority extends to the edge of their service boundary and no further. “That’s not our problem” is a jurisdictional claim: the issue falls outside the team’s territory. Cross-cutting concerns (security, performance, observability) become analogous to international law — norms that apply across jurisdictions but lack enforcement mechanisms within any single territory.
- Border disputes as cross-team conflicts — when two services need to share a database, when an API contract needs to change, when a platform team wants to impose a standard — these are border disputes. The territorial metaphor provides a ready-made vocabulary: “encroachment,” “overreach,” “stepping on toes.” It also imports a ready-made conflict resolution framework: negotiation, escalation to a higher authority, or simply building a wall (API boundary).
- Colonization as platform mandates — when a platform team imposes a standard across all services, teams experience it as a loss of sovereignty. “They’re taking over our deployment pipeline” carries genuine emotional weight because the territorial metaphor makes it feel like a seizure of self-governance, not merely a tooling change.
Limits
- Technical territory is not scarce — physical territory is zero-sum: if you control this land, I cannot. Technical decisions are not inherently zero-sum. Two teams can independently choose their own frameworks, databases, and deployment strategies without diminishing each other’s options. The territorial metaphor imports scarcity where none exists, escalating routine coordination into conflict.
- Borders are artificial and mutable — physical borders are expensive to move (wars, treaties). Service boundaries can be refactored in a sprint. The metaphor makes architectural decisions feel permanent and politically charged, discouraging the routine restructuring that healthy codebases require.
- Sovereignty hides interdependence — real systems have shared databases, common libraries, and transitive dependencies. The territorial metaphor’s emphasis on autonomy obscures these structural couplings. A team that believes it is sovereign over its service may not realize that its choices constrain every downstream consumer.
- The metaphor privileges defense over collaboration — territorial thinking defaults to protecting boundaries. “Don’t touch my code” is a defensive posture that the metaphor makes feel natural and righteous. But healthy engineering cultures require the opposite: willingness to accept outside contributions, to cede control when appropriate, and to share ownership of cross-cutting concerns.
Expressions
- “Code ownership” — the foundational territorial claim
- “That’s not in our scope” — jurisdictional boundary assertion
- “They’re stepping on our toes” — territorial encroachment complaint
- “CODEOWNERS” — the literal map of territorial sovereignty in a Git repository
- “Don’t touch my code” — the territorial defensive reflex
- “Land grab” — a team expanding its technical authority into unclaimed or contested territory
- “Turf war” — two teams fighting over decision authority on a shared concern
Related Entries
Structural Neighbors
Entries from different domains that share structural shape. Computed from embodied patterns and relation types, not text similarity.
- Demons on the Boat (folklore/metaphor)
- Illness Is an Invader (war/metaphor)
- Dark Forest (mythology/metaphor)
- Defense Mechanisms (war/metaphor)
- Morality Is War (war/metaphor)
- Security Violations Are Trespassing (physical-security/metaphor)
- Treating Illness Is Fighting a War (war/metaphor)
- Circle of Competence (geometry/mental-model)
Structural Tags
Patterns: containerboundarycenter-periphery
Relations: containcompeteprevent
Structure: competition Level: generic
Contributors: agent:metaphorex-miner