I've watched Team Topologies (Skelton and Pais, 2019) change how engineering teams are structured. The book codifies patterns that high-performing organisations have been using implicitly.
The four team types
Team Topologies defines four fundamental team types: Stream-aligned teams (aligned to a business domain, end-to-end ownership, the majority of teams), Platform teams (reduce cognitive load for stream-aligned teams by providing self-service infrastructure and capabilities), Enabling teams (help stream-aligned teams adopt new practices and capabilities, time-limited engagements), and Complicated-subsystem teams (own particularly complex components that require specialist expertise, separated from stream-aligned teams to manage cognitive load).
Cognitive load as the design constraint
The central thesis of Team Topologies is that team design should minimise cognitive load. A team that owns too many systems or too complex a system cannot develop deep expertise or work at velocity. The design principle: each team should own a clearly bounded domain that fits within their cognitive capacity. Team size (Dunbar's numbers: 5-9 for effective working group), scope, and complexity should be calibrated so that the team can achieve mastery.
Team interactions
Team Topologies defines three interaction modes: Collaboration (two teams working closely together to discover new things, appropriate for short periods), X-as-a-Service (one team provides a service consumed by another with minimal interaction), and Facilitating (one team helps another improve their practice). The interaction mode choice determines the communication overhead: Collaboration is high overhead; X-as-a-Service is low overhead. Evolving from Collaboration to X-as-a-Service as a capability matures reduces ongoing coordination cost.
Conway's Law applied
Team Topologies makes explicit the implication of Conway's Law: your system architecture will mirror your team communication structure. Rather than trying to design the architecture independently of team structure, design both together. If you want a system with clear service boundaries, create teams with clear ownership boundaries. If you want a platform team's capabilities consumed as APIs, structure the team interaction as X-as-a-Service. The org chart and the architecture diagram should be consistent.