1.2 Team topologies and organizational design¶

Overview and motivation¶

How you divide people into teams determines what software you can build and how fast you can build it. This is not a metaphor. It is a near-mechanical consequence known as Conway's Law: organizations design systems that mirror their own communication structures. If three teams build a compiler, you get a three-pass compiler. If your payments logic is split across a frontend team, a backend team, and a database team, every payment change needs three-way coordination. For a small organization, that is manageable. For a large one, the shape of the org chart becomes the dominant constraint on your engineering, your architecture, your delivery speed, and your quality. So designing team structure is a first-class engineering activity, not an HR afterthought.

Team topologies give you a deliberate vocabulary for this design. Instead of letting structure accrete by accident through reorgs and headcount, mature organizations choose team types and interaction modes on purpose, and they revisit those choices as the system and business evolve. The goal is to keep each team's cognitive load low, the total amount a team has to hold in its head to be effective, so teams can own their domain end to end and deliver a steady flow of value without constantly waiting on others.

For enterprises and government, this discipline is decisive. Large organizations naturally sprawl into deep hierarchies, shared services with long queues, and hand-off chains that turn a two-day change into a two-month project. Government adds procurement boundaries, contractor teams, and mandated separations of duty that fragment ownership further. Explicit topology design is how these organizations reclaim flow: align teams to streams of value, build platforms that reduce cognitive load, and choose interaction patterns that make dependencies visible and intentional rather than hidden and constant.

Key principles¶

• Conway's Law is inescapable; design teams to match the software engineering you want (the "inverse maneuver").
• Optimize for team cognitive load, not for maximum utilization of individuals.
• Prefer stream-aligned teams that own a slice of value end to end.
• Platforms exist to reduce the cognitive load of stream-aligned teams, not to gatekeep.
• Make team interactions explicit and few: collaboration, X-as-a-service, or facilitating.
• Minimize dependencies; every cross-team hand-off is a queue and a risk.
• Team structure is a living design that must evolve as the system and business change.

Recommendations¶

Use the four fundamental team types¶

Team topologies define four team types that cover most needs. Stream-aligned teams are the default: each owns a continuous flow of work for a specific product, service, or user journey, end to end. Platform teams provide internal products (compute, deployment, data pipelines, identity) that stream-aligned teams consume self-service, which lowers their cognitive load. Enabling teams are specialists (testing, security, observability) who coach stream-aligned teams to build a capability, then step back. Complicated-subsystem teams own components that need deep specialist expertise (a pricing engine, a video codec, a cryptographic module), where it makes no sense for every team to hold that knowledge. Most of your teams should be stream-aligned; the other three types exist to support them.

Apply the inverse Conway maneuver¶

Since software mirrors your organization's structure, shape your teams to produce the software you want. Want loosely coupled services with clear boundaries? Create loosely coupled teams with clear ownership boundaries. Want a payments capability that ships on its own schedule? Form a payments team that owns it front to back. Do not fight Conway's Law with heroic coordination. Redraw the team boundaries so the architecture you want becomes the path of least resistance.

Manage cognitive load explicitly¶

A team can only master so much. Cognitive load includes the domain complexity, the technologies, the operational burden, and the breadth of stakeholders. When a team owns too many unrelated services, quality and speed both collapse. So bound each team's responsibilities to a domain it can genuinely master, and use platforms and enabling teams to take undifferentiated complexity off its plate. Keep teams to roughly five to nine people: small enough to communicate easily and to be fed, so to speak, by a couple of pizzas.

Choose interaction modes deliberately¶

Limit team interactions to three modes. Collaboration is close, high-bandwidth work between two teams for a set period; it is powerful for discovery, but expensive, so keep it temporary. X-as-a-service is a clean provider/consumer relationship with a well-defined interface, ideal for platform consumption at scale. Facilitating is one team helping another learn, which is what enabling teams do. Name the mode for each important cross-team relationship, and read long-running collaboration between the same two teams as a signal that their boundary is in the wrong place.

Choose an operating model for cross-cutting functions¶

Security, data, design, and similar disciplines can be organized in three ways: centralized (one team owns it for everyone), federated (specialists embedded part-time, coordinating through a guild), or embedded (a dedicated specialist inside each stream-aligned team). Centralized gives you consistency and depth, but it becomes a bottleneck. Embedded gives you speed and context, but it risks inconsistency and duplication. Federated (often a hub-and-spoke or community-of-practice model) sits between the two. Choose per function and per scale. Most large organizations land on federated for these disciplines, with a small central core that sets standards.

Invest in inner-source¶

Inner-source brings open-source collaboration patterns inside the organization: shared internal repositories, published contribution guidelines, code review across team boundaries, and clear maintainers. When a team needs a change to another team's component, it can contribute the change directly instead of filing a ticket and waiting in a queue. This relieves cross-team dependencies without dissolving ownership, and it spreads knowledge and standards naturally across a large engineering population.

Trade-offs: pros and cons¶

The recurring trade-off is autonomy versus consistency. Fully autonomous teams move fast, but they drift apart in standards, tooling, and security posture. Fully centralized control keeps things consistent, but it strangles flow. Good topology design finds the seam: autonomy for stream-aligned delivery, plus thin central standards and paved-road platforms (well-supported default tooling that makes the compliant choice the easy one) for the things that genuinely have to be consistent.

Examples¶

Startup. A ten-person startup has a single stream-aligned team that owns the whole product end to end, which is exactly right at its scale: no hand-offs, no coordination tax, everyone sharing the same context. Trouble starts when they hire a dedicated "DevOps person" and a separate "QA person" and accidentally recreate functional silos, so every release now waits on two individuals. They course-correct by treating those hires as an embedded platform-and-testing capability inside the one team, rather than gates that work must pass through. At this size, the cheapest topology is the one that keeps everyone in a single flow.

Enterprise. A large retailer's checkout was slow to change because frontend, backend, and fulfillment logic were split across three functionally organized teams, forcing every change through three backlogs. Applying the inverse Conway maneuver, they reorganized into stream-aligned teams around customer journeys ("browse," "cart and checkout," "post-purchase"), each owning its slice front to back, backed by a platform team that provided deployment and observability as a service. Checkout changes that once took a quarter started shipping in days, because the coordination that used to span teams now happened inside one.

Government. A government tax agency ran a central security team that reviewed every release, creating a multi-week queue that delayed critical fixes. They shifted to a federated model: a small central security function set standards and provided a "paved road" of pre-approved, automatically scanned pipelines, while security champions embedded part-time in each delivery team handled the day-to-day decisions. The platform generated compliance evidence automatically. Mandated separation-of-duty requirements were still met, but through tooling and clear interfaces rather than a human bottleneck, which cut release lead time dramatically while improving audit readiness.

Business case: motivations, ROI, and TCO¶

You pay for poor team design in coordination overhead, and that overhead grows faster than linearly with the number of teams that have to synchronize for a typical change. Every hand-off is a queue with waiting time, a context transfer that loses information, and a fresh chance to miscommunicate. When a routine change needs three teams to align their roadmaps, the real cost is not the sum of their work; it is the far larger cost of scheduling, waiting, and rework. Redraw boundaries so that most changes fit inside one team's ownership, and that overhead simply goes away.

The adoption cost is real. Reorganizations are disruptive, and building platforms and inner-source practices takes up-front investment before the payoff arrives. But the cost of not adopting compounds. Organizations that let structure accrete by accident pile up hand-off chains, shared bottleneck teams with quarter-long queues, and architectures fossilized by the org chart. To make the case to leadership, measure dependency-driven delay: how many active initiatives are blocked waiting on another team, and for how long. Platform and topology investments usually pay back by turning that waiting into flow, which shows up as shorter lead times and higher throughput without adding headcount.

Anti-patterns and pitfalls¶

• Ignoring Conway's Law: designing an architecture the org structure cannot deliver.
• Functional silos: separate frontend, backend, QA, and ops teams that must coordinate for any change.
• Shared-services bottleneck: a central team every project must queue behind.
• Platform as gatekeeper: a platform team that mandates rather than serves, adding friction instead of removing it.
• Cognitive overload: teams owning sprawling, unrelated systems they cannot master.
• Permanent "collaboration": two teams perpetually entangled, signaling a misplaced boundary.
• Reorg addiction: reshuffling constantly, destroying the stability teams need to gel.

Maturity model¶

• Level 1 (Initial): Teams form by accident or headcount; structure mirrors legacy hierarchy; dependencies everywhere.
• Level 2 (Managed): Some stream-aligned teams exist, but shared bottlenecks and functional silos persist.
• Level 3 (Defined): The four team types and explicit interaction modes are used deliberately; platforms and InnerSource reduce dependencies.
• Level 4 (Optimizing): Team boundaries and cognitive load are actively monitored and evolved; the org reshapes itself to sustain flow.

Ideas for discussion¶

• For a typical change, how many teams must coordinate, and why?
• Which of our teams are carrying too much cognitive load, and what could a platform offload?
• Where are we fighting Conway's Law instead of redrawing boundaries?
• Are our platform teams serving stream-aligned teams or gatekeeping them?
• Should security, data, and design be centralized, federated, or embedded for us right now?
• Which "temporary" collaborations have quietly become permanent dependencies?

Key takeaways¶

• Org structure determines architecture and delivery speed; design it deliberately.
• Use the four team types, with stream-aligned as the default and the rest in support.
• Apply the inverse Conway maneuver to make the desired architecture the easy path.
• Manage cognitive load; bound each team to a domain it can master.
• Limit and name cross-team interaction modes; treat lingering dependencies as boundary defects.
• Choose centralized, federated, or embedded models for cross-cutting functions per scale, and use InnerSource to relieve queues.

References and further reading¶

• Matthew Skelton and Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow"
• Melvin Conway, "How Do Committees Invent?" (the origin of Conway's Law)
• Nicole Forsgren, Jez Humble, Gene Kim, "Accelerate"
• Will Larson, "An Elegant Puzzle: Systems of Engineering Management"
• Sam Newman, "Building Microservices" (on aligning services to teams)
• Danese Cooper and Klaas-Jan Stol, "Adopting InnerSource," and the InnerSource Commons patterns
• Frederick Brooks, "The Mythical Man-Month" (communication overhead)