Collaboration is good for innovation but increases cognitive load. And not all work is innovative. Managing this tradeoff between collaboration and focus is central to the theme of Team Topologies. Team Topologies presents some core patterns of team organization and communication that can help your team deliver effectively while minimizing (excess) communication overhead and maximizing necessary interactions. The authors emphasize that structuring your team isn’t simply something that you do once; you need to be alert to signs that your team (and architecture) need to be realigned.
At first glance, this seems to be about “Conway’s Law,” and Conway’s observation that “organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations” is a central and recurring theme in the book. Team Topologies goes a bit deeper and presents some principles for defining and organizing your teams so that the teams and their communication structures support an architecture that makes sense (rather than the reverse).
The book builds on various work around teams, teamwork, communication, and collaboration. While it did miss a few sources — such as Thomas Allen for the role of office space in collaboration and Organization Patterns by Coplien and Harrison— it cites many essential works.
Software architecture and technology problems can be challenging, but people architecture can be the more challenging of the two. Since teams of people build software, it’s important not to ignore the structure of your organization. While much work focuses on technology or technology, for complex systems, the interaction between people, processes, and technology is essential. to understand since addressing issues on only one part might only be a short-term fix. My work on Software Configuration Management Patterns and later the study (and practice) of Agile methods got me thinking about this, and I’m working on integrating these elements more tightly in an update to the pattern language (see some other posts on my substack) and Team Topologies will certainly get a reference in that new work
Team Topologies can help you understand the role of the organization structure and dynamics in building good software architecture and data flow. If you want to understand how organization affects your architecture and how to work to align your team structure to get the architecture you want, this book is worth a look.