Team Topologies

**Author:** Matthew Skelton and Manuel Pais **Estimated Reading Time:** 45 minutes

**What You'll Learn:**

- Why organizational structure determines software architecture more than any technical decision - How to design teams that match the cognitive limits of human beings - The four fundamental team types that every software organization needs - How to use three interaction modes to eliminate ambiguity and friction - Why platforms should be "just big enough" and nothing more - How to evolve team structures as your systems and markets change

**Who This Book Is For:**

This book is for engineering leaders, architects, CTOs, product managers, and anyone responsible for how software gets built. If you have ever wondered why your carefully designed architecture never quite materializes, why teams seem to fight the system instead of improving it, or why scaling feels harder than it should, this book provides the missing piece: the organizational design behind the technology.

Every software organization has a vision of what its systems should look like. The diagrams show clean boundaries, well-defined services, elegant interfaces, and components that can evolve independently. The reality is usually messier. Systems become tangled. Changes ripple across teams. Dependencies multiply. The architecture that emerges bears little resemblance to the one that was designed. Why does this happen? The answer is not a lack of technical skill. It is not insufficient tooling. It is not even bad architectural decisions. The answer, as Matthew Skelton and Manuel Pais demonstrate, is that the organization itself is the architecture. In the 1960s, a computer scientist named Melvin Conway observed something that would become known as Conway's Law: organizations design systems that mirror their communication structures. If four teams work on a compiler, you get a four-pass compiler. If teams cannot communicate effectively, the software they produce will reflect that fragmentation. The implications of this observation are enormous, yet for decades, the software industry largely ignored them. Skelton and Pais argue that this is the root cause of many failed digital transformations. Companies adopt microservices, but their teams remain organized around layers or functions. They invest in cloud platforms, but their teams still depend on centralized operations groups. They adopt agile practices, but their organizational structures remain rigid and hierarchical. In each case, the organization's communication patterns override the intended architecture. The result is frustration, slow delivery, and systems that are harder to maintain than they should be. The book's central insight is that team structure should be treated as a first-class design concern. Instead of letting organizational structures emerge accidentally, leaders should deliberately design teams to match the systems they want to build. This is what Skelton and Pais call the "reverse Conway maneuver." Rather than fighting Conway's Law, you…