Socio-Technical Systems

Software doesn’t exist in a vacuum. It’s built by people organized into teams, and the way those teams communicate shapes the systems they produce. This section covers the patterns that live at the intersection of organizational structure and software architecture.

These patterns operate at the strategic-to-architectural scale. They address questions that sit above individual code decisions but below business strategy: How should teams be organized to produce the architecture you want? How much complexity can a single team (or agent) hold in its head? Who owns what, and what happens when ownership is unclear?

The concepts here draw on decades of research in organizational design, from Melvin Conway’s foundational observation in 1967 to Matthew Skelton and Manuel Pais’s Team Topologies framework. What makes them newly urgent is the arrival of AI agents as first-class participants in software construction. Agents don’t absorb tacit knowledge from hallway conversations. They can’t sense when a team boundary is in the wrong place. The organizational structures you design for agent teams shape the software those agents produce, just as they always have for human teams.

Patterns in This Section

• Conway’s Law – Organizations produce systems that mirror their communication structures. This observation, once treated as an inevitability, is now a design lever.
• Team Cognitive Load – Every team has a ceiling on how much complexity it can handle. Cognitive load measures how close a team is to that ceiling, and what happens when it overflows.

Where to Start

Start with Conway’s Law. It’s the foundational observation that connects organizational structure to software architecture. Then read Team Cognitive Load to understand the mechanism that explains why team structure limits what teams can effectively own.