Slicing the Organization

After Andy hired me in 2003, I joined Web.de in Karlsruhe as a software developer. My team, the Windows Frontend Team, sat at one end of a long open-plan office. The Backend Team sat at the other end, 20 meters away.

Every time our code did not work as expected, the conversation followed the same pattern. My frontend colleague would say: “The backend returns the wrong status. They need to fix it.” So I walked 20 meters to the backend developer. His answer: “That has to be solved in the frontend. Otherwise we need to hold state persistently, which is not part of the design.” Back to the frontend. We patched it somehow, which caused the next bug. As the more extroverted developer on the team, I became the one who walked those 20 meters back and forth, sometimes countless times a day.

What I did not understand at the time: I was fighting a structural force that Melvin Conway had described in 1968. The organizational split between frontend and backend made it nearly impossible to build an integrated product. The teams communicated across a boundary that should not have existed. When management later added a Business Analyst role to improve coordination, it made things worse. I know, because I was that Business Analyst. My job was to translate the product designers’ ideas into specifications the developers could implement. Instead of removing the boundary between teams, the role added another handoff. I moved 20 meters closer to the product designers and 20 meters further from the developers. More distance, more delay.

The solution came by accident. A frustrated product designer sat at my desk one morning because the software did not work as he envisioned. Instead of writing another specification document, I walked him 20 meters through the office to our programmer. I asked him to explain his concept directly. A few hours later, they had a working solution. Direct communication solved in hours what layers of coordination had failed to solve in months.

This experience taught me a lesson I have since observed in dozens of organizations: how you slice the organization determines how well the organization can build its products.

The Mathematics of Communication

Every enterprise faces the same challenge as it grows: communication becomes harder. Not because people stop trying, but because mathematics works against them.

Five people need 10 communication channels to stay fully connected. Ten people need 45. Twenty-five people need 300. The formula is simple: $n(n-1)/2$. Communication effort grows quadratically.

“Adding manpower to a late software project makes it later.” (Fred Brooks, The Mythical Man-Month, 1975)

Brooks identified the mechanism: the communication overhead of each new person outweighs their productive contribution. Robin Dunbar’s research confirms it from a different angle: the human brain can maintain meaningful social relationships with roughly 150 people. Beyond that, groups fragment without formal structure.

No organizational approach scales linearly. The question is how to manage the inevitable complexity.

Calculations use $i_a = 1$, $i_t = 2$, $i_{mt} = 4$. See Communication Effort in a Scaling Organization with Teams for the full model.

AME3 answers this question through a principle applied recursively at every level of the enterprise: compartmentalize communication within boundaries and reduce the intensity of communication across boundaries.

Slicing with Teams

The first cut is the most powerful. Organizing people into small Teams transforms one large communication network into several smaller ones, connected by fewer, lower-intensity channels.

Without Teams, 25 people generate a communication effort of $I = 300$. Organized into five Teams of five, internal effort drops to $5 \times 10 = 50$. Inter-team coordination adds $10 \times 2 = 20$ (assuming each team-pair communicates at twice the intensity of an individual pair). Total: $I = 70$. A 77% reduction.

The inter-team intensity of $i_t = 2$ is not a constant. It depends on the practices teams use to reduce inter-team dependencies. Co-location, as in my Web.de story, removes physical barriers. Continuous automated testing catches integration problems before they become coordination problems. Shared code ownership eliminates handoffs between component owners. Each practice lowers $i_t$. When practices are absent, $i_t$ rises. The companion chapter Slicing the Product explores how product architecture further influences this intensity.

The math shows that well-structured teams have an enormous margin before coordination overhead outweighs the benefits. Teams become inefficient only when inter-team communication intensity exceeds $i_a \cdot n_a^2$. For teams of five, that threshold is 25 times the internal pair intensity.

How Large Should a Team Be?

Multiple independent sources converge on the same answer.

George Miller’s research on working memory established that humans can hold 7 ± 2 items simultaneously. John Sweller’s Cognitive Load Theory extended this: when the demands on working memory exceed capacity, performance degrades. Dunbar’s research places the closest social bonding layer at 5 people, the next at 15.

The practitioners arrived at the same numbers independently. Jeff Bezos at Amazon insists no team should be larger than what two pizzas can feed, roughly 5 to 10 people (he was probably talking about American pizzas). Scrum recommends 3 to 9 developers. LeSS specifies 7 ± 2 members per feature team.

These are not arbitrary choices. A team of 5 has 10 communication channels. A team of 9 has 36. A team of 12 has 66. Beyond 9 or 10 people, the internal coordination overhead starts consuming the productivity gains that teams provide.

Every team has a finite capacity for complexity. When a team is responsible for too many domains, too many technologies, or too many stakeholder relationships, quality drops. Communication overhead and cognitive overload are two forces that both push toward smaller teams.

Feature Teams vs Component Teams

The terms “feature team” and “component team” originate in software development, but the underlying principle applies to any domain where teams create products or services. As AI reshapes what teams take responsibility for, the distinction becomes even more relevant. Teams will own broader slices of the value chain, making end-to-end ownership the default rather than the exception.

How teams are sliced determines how much they need to coordinate. Two approaches exist.

A component team owns a functional layer: a department, a technology stack, a specialized capability. Every customer need that crosses layers requires coordination between multiple teams. This creates handoffs, waiting, and integration overhead. My experience at Web.de was a textbook case.

A feature team owns a slice of customer value end-to-end. It contains all the skills needed to deliver a complete Improvement within a Match. Feature teams minimize inter-team dependencies by design, because each team can deliver independently.

LeSS strongly advocates feature teams: long-lived, cross-functional groups of 7 ± 2 people that complete end-to-end customer features, one by one. The trade-off is real: feature teams require generalizing specialists who can work across domains. Component teams preserve deep specialization. But the communication mathematics favors feature teams. Every dependency between teams adds communication channels.

Fewer dependencies does not mean zero dependencies. Feature teams still coordinate with other teams on shared interfaces, architecture decisions, and cross-cutting concerns. The De-Scaling Cycle provides the method for managing and reducing the dependencies that remain.

This is not limited to software. In manufacturing, a team that owns a product from design through production has fewer coordination points than separate design, engineering, and production teams. In consulting, a team that owns an entire client engagement communicates more efficiently than functional specialists handed off between phases.

Conway’s Law: Design Your Teams, Design Your Product

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” (Melvin Conway, 1968)

Conway’s Law means that organizational boundaries become product boundaries. If three teams build a product, the product will have three major components. If teams are organized by function (design, engineering, operations), the product will have functional silos.

The Inverse Conway Maneuver turns this around: design your team structure to match the product architecture you want. If you want loosely coupled services, create autonomous teams with clear ownership boundaries. If you want a tightly integrated product, create cross-functional teams that share code and coordinate closely.

The System Lead’s choice of team structure is an architectural decision as much as an organizational one. The System Lead and the Owner must make these decisions together. Restructuring is not overhead. It is an investment in the Arena Product. As Overall Optimization describes in the De-Scaling Cycle: treat organizational design and technical architecture as one problem, not two.

Slicing with Multi-Team Units

The same compartmentalization principle applies one level up. When an Arena grows beyond a handful of Teams, grouping them into multi-team units reduces the number of inter-team communication channels.

Each multi-team unit contains Teams that share a product or service boundary. Internal coordination stays within the unit. Communication between units follows defined interfaces at lower intensity.

Multi-team units are not an AME3 concept. They are a design choice made by the System Lead using methods and frameworks. A single Team might use Scrum. A multi-team unit might scale following LeSS, LeSS Huge, or Scrum@Scale. The choice depends on the evolutionary stage and Ambition.

How Frameworks Structure Multi-Team Units

LeSS (up to 8 teams): All teams share one Product Backlog, one Product Owner, and one Sprint cadence. Coordination happens through direct communication, not additional management layers. Feature teams work end-to-end across the full product.

LeSS Huge (more than 8 teams): Introduces Requirement Areas, each handled by 4 to 8 teams with an Area Product Owner. One overall Product Owner maintains product-wide prioritization. LeSS explicitly warns against making Requirement Areas the line organization: they should be dynamic and adaptive, not permanent structures.

Scrum@Scale: Organizes coordination through a Scrum of Scrums, where representatives from each team synchronize work and remove cross-team impediments. An Executive Action Team mirrors this at the leadership level, responsible for removing organizational obstacles that teams cannot address themselves.

Each framework solves the same problem differently. See The Good, the Bad, and the Ugly about Frameworks and Example Mapping of Methods and Frameworks for guidance on choosing between them.

What AME3 Prescribes and What It Does Not

AME3 prescribes the Arena structure: Teams, Owner, System Lead, Arena Backlog, Arena Product, Match. It does not prescribe how to organize teams within the Arena. That is the System Lead’s responsibility.

This is a deliberate design choice. The critics of scaling frameworks consistently identify the same failure mode: frameworks that lock in structure before the organization has learned what structure it actually needs. SAFe draws the strongest criticism on this point. Ken Schwaber (Scrum co-creator), Ron Jeffries and Andy Hunt (Agile Manifesto co-authors), and ThoughtWorks Technology Radar have publicly argued that it codifies dysfunctions and optimizes for predictability over empiricism. See The SAFe Delusion for a detailed analysis.

AME3 avoids this by separating the strategic frame (Rules, Tournament, Ambition, Goals) from the tactical work system design. The System Lead selects and adapts frameworks based on the current reality, not a predetermined blueprint.

The Arena as Strategic Frame

The Arena does not add communication overhead. It provides the governance structure within which Teams and multi-team units operate.

An Arena is a highly independent organizational unit dedicated to a specific Ambition. It contains a complete work system: Teams that deliver and improve the Arena Product, an Owner who drives product success, and System Leads who ensure an effective work system.

The Teams are the single connection to the customer. Their work is to improve and enhance the Arena Product, generating return on investment and satisfying the customer. The dashed arrow in the image represents this customer interface: it evolves with the product, from early exploration to established service.

The communication interfaces in this image are positioned on a Wardley Map. Their position reveals the level of stability each interface requires.

Teams operate in the Volatile and Shifting zone. Inter-team communication is frequent and must adapt continuously. Product boundaries are still forming. The System Lead actively shapes how teams coordinate.

Between multi-team units and between Arenas, communication moves into the Settling and Stable zone. Interfaces here need well-defined rules and predictable cadence. The Tournament provides this structure at the enterprise level.

At the outermost layer, the Enterprise communicates with society through legal entity structures, regulatory compliance, and public accountability. These interfaces are governed by law rather than organizational choice.

Practical Guidance for the System Lead

Designing the organizational structure of an Arena is the System Lead’s core responsibility, in collaboration with the Owner. The following guidelines synthesize the principles from this chapter into actionable recommendations.

When to Split a Team

• A team exceeds 9 people, or internal coordination consumes more time than productive work
• A team owns too many domains and cognitive load prevents deep work. Signs: frequent context-switching, declining quality, inability to finish Improvements within a Match
• Splitting should follow product boundaries, not functional specializations. Each new team should be able to deliver end-to-end value independently

When to Form Multi-Team Units

• An Arena has more than 5 to 8 Teams, and inter-team coordination becomes a bottleneck
• Groups of teams naturally cluster around related customer concerns or product areas
• The System Lead should resist making multi-team units permanent organizational layers. They should be dynamic, adapting as the product evolves. LeSS Huge warns explicitly against this rigidity

When to Create a New Arena

• A product or service has its own distinct Ambition, customer base, and success criteria
• The work is sufficiently independent that teams rarely need to coordinate with other parts of the enterprise
• The product’s evolutionary stage requires a different approach than the existing Arenas. A Genesis-stage innovation project should not share governance with a Commodity-stage operational product

When to Reorganize

• The product has moved from one evolutionary stage to the next: structures optimized for Genesis-stage exploration slow down Product-stage delivery, and vice versa
• The De-Scaling Cycle reveals persistent dependencies that cannot be managed, only eliminated through restructuring
• A Match retrospective repeatedly surfaces the same coordination problems across teams
• New products or capabilities emerge that do not fit the current Arena boundaries

The System Lead facilitates this continuous reorganization, working with the Owner and Teams to experiment with structures that minimize dependencies.

The goal is not to find the perfect structure. The goal is to develop the ability to change structure when the product demands it.

The Other Side of the Coin

This chapter addresses one side of the scaling challenge: how to slice the organization. Compartmentalize communication within boundaries. Reduce the intensity across boundaries. Apply this principle recursively, from Teams to multi-team units to Arenas.

The other side is equally important. Conway’s Law tells us that organizational boundaries and product boundaries mirror each other. How you slice your products and services determines where team boundaries can and should be drawn. The companion chapter, Slicing the Product, covers this.

Together, they form one practice: designing the organization and the product as a single, evolving system.