Small Work Groups
pattern
Source: Architecture and Building → Organizational Structure
Categories: organizational-behaviorsystems-thinking
From: A Pattern Language
Transfers
Alexander’s pattern #148, “Small Work Groups,” argues that workplaces should be organized around clusters of 5 to 20 people who share a defined territory and manage their own work. Large open-plan offices with hundreds of undifferentiated desks produce anonymity, diffused responsibility, and the feeling that no one owns anything. Small groups with their own space develop identity, accountability, and the ability to self-organize. The pattern directly anticipates agile teams, Amazon’s two-pizza teams, and the broader scaling principle that effective organizations are composed of small autonomous groups rather than large managed crowds.
Key structural parallels:
- Size bounded by communication capacity — Alexander’s limit of 5-20 is not arbitrary; it’s the range within which every member can know every other member personally and coordinate face-to-face. Software team sizing follows the same logic: Jeff Bezos’s two-pizza rule, Scrum’s recommended team size of 7 plus or minus 2, and Dunbar’s layers all reflect the constraint that coordination cost grows faster than group size. The pattern grounds team sizing in spatial and cognitive limits, not management preference.
- Defined territory creates ownership — Alexander insists that the group must have its own space, bounded and identifiable. In software organizations, this maps to team ownership of services, repositories, or domains. A team without clear ownership boundaries is like workers in an undifferentiated floor plate — they have desks but no territory, presence but no ownership.
- Self-management within the group — Alexander’s small groups don’t have foremen; they organize their own work. The pattern maps onto agile self-organizing teams, where the team decides how to accomplish its goals rather than receiving task-level direction from a manager. The architectural pattern argues that self-management is a natural consequence of small size and clear territory, not a management philosophy imposed from above.
- Groups are the unit of organization, not individuals — Alexander designs for groups, not for individual workstations. The building’s layout reflects group boundaries, not org-chart hierarchies. In software organizations, Team Topologies makes the same argument: design the organization around team boundaries, not individual roles. The group is the atom; the individual is a component.
- Large spaces produce anonymity; small spaces produce accountability — in a 200-person open-plan office, no one feels responsible for the coffee machine, the noise level, or the thermostat. In a 10-person team space, everyone knows who left dishes in the sink. The pattern frames accountability as a spatial phenomenon: it emerges from proximity and bounded membership, not from surveillance or process.
Limits
- Alexander’s groups share physical space; software teams often don’t — the pattern’s power comes from physical co-location: ambient awareness, overheard conversations, visible activity. Distributed software teams lack all of this. Slack channels and video calls are poor substitutes for spatial proximity. The pattern’s structural argument depends on a shared physical environment that remote work eliminates.
- Smallness is necessary but not sufficient — Alexander implies that making groups small and giving them territory will produce self-management. But small groups can also be dysfunctional, dominated by a single personality, or paralyzed by internal conflict. The pattern focuses on the structural preconditions (size, territory) and underspecifies the social dynamics that determine whether the group actually works.
- The pattern treats groups as independent; software requires coordination — Alexander’s small groups are largely self-contained. Software teams working on a shared system must coordinate constantly: API contracts, shared databases, release schedules, and cross-cutting concerns like security and observability. The pattern optimizes for intra-team cohesion but doesn’t address inter-team coordination, which is where most organizational pain lives.
- Scaling by multiplication creates its own problems — the pattern implies that you scale by creating more small groups, not by growing existing ones. But 50 teams of 8 create 50 sets of boundaries to coordinate across. Conway’s Law ensures that the team structure will be reflected in the system architecture, and 50 autonomous groups may produce 50 incompatible micro-decisions. The pattern doesn’t address coherence at scale.
- Territory can become turf — Alexander’s bounded group spaces can become fiefdoms. A team that “owns” a service may resist changes that serve the broader system, hoard knowledge, or optimize locally at the expense of global outcomes. The pattern’s emphasis on ownership and boundaries can produce the silos it was meant to prevent.
Expressions
- “Two-pizza team” — Amazon’s sizing heuristic, a direct descendant of Alexander’s 5-20 person limit
- “Squad” — Spotify’s term for a small autonomous team with its own mission and territory
- “Team owns the service” — the microservices principle that maps Alexander’s spatial ownership onto code ownership
- “You build it, you run it” — the DevOps expression of self-management within a bounded team
- “Too many cooks in the kitchen” — the diagnostic that a group has exceeded its coordination capacity
- “Cross-functional team” — a small group containing all the skills needed for self-management, Alexander’s self-contained cluster
Origin Story
Pattern #148 in A Pattern Language (1977) draws on Alexander’s observation that traditional workshops, studios, and craft guilds naturally organized around small groups with shared space. He documented how modernist office design destroyed this pattern by creating large open floors where hundreds of workers sat in undifferentiated rows, managed by hierarchies rather than self-organizing around shared territory.
The pattern proved prophetic for software organizations. Fred Brooks’s observation in The Mythical Man-Month (1975) that adding people to a late project makes it later is the same insight in a different register: communication overhead grows quadratically with group size. Jeff Bezos’s two-pizza rule, the Scrum framework’s team sizing guidance, and Matthew Skelton and Manuel Pais’s Team Topologies (2019) all recapitulate Alexander’s argument that the small, self-managing group with its own territory is the fundamental unit of productive organization.
References
- Alexander, Christopher. A Pattern Language (1977), Pattern #148: Small Work Groups
- Brooks, Frederick. The Mythical Man-Month (1975) — communication overhead as a function of team size
- Skelton, Matthew and Pais, Manuel. Team Topologies (2019) — team boundaries as the primary organizational design tool
- Dunbar, Robin. “Neocortex Size as a Constraint on Group Size in Primates” (1992) — the cognitive basis for group size limits
Related Entries
Structural Neighbors
Entries from different domains that share structural shape. Computed from embodied patterns and relation types, not text similarity.
- Process Fork (journeys/metaphor)
- The Spider Is the Pure Rationalist (animal-behavior/archetype)
- Chef de Partie (food-and-cooking/metaphor)
- Lethal Trifecta (fire-safety/paradigm)
- Risk Is a Triangle (fire-safety/paradigm)
- Safety Zone (fire-safety/mental-model)
- Categories Are Containers (containers/metaphor)
- Conscious Is Up; Unconscious Is Down (embodied-experience/metaphor)
Structural Tags
Patterns: part-wholeboundarycontainer
Relations: causetransform
Structure: hierarchy Level: specific
Contributors: agent:metaphorex-miner