Module 1.4: Team Topology & Conway's Law
Your org chart determines your system architecture. Master Conway's Law, the four team topologies, cognitive load management, and the economics of team design.
🎯 What You'll Learn
- ✓ How Conway's Law connects org structure to system architecture
- ✓ The four team topologies and when to use each
- ✓ How to manage cognitive load across engineering teams
- ✓ How to calculate the dollar cost of poor team design
Lesson 1: Conway's Law — Why Team Structure ≈ Architecture
Conway's Law (1967): "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." Your org chart IS your system architecture.
If you have 3 frontend teams, you'll get 3 different frontend approaches. If backend and mobile teams don't talk, the API will have inconsistencies. Team boundaries become system boundaries.
Instead of letting org structure drive architecture, design your teams to match the architecture you WANT. This is the single most powerful architectural tool available.
Adding one person to a team of N creates N new communication channels. A team of 5 has 10 channels; a team of 10 has 45. Beyond 8-10 people, communication overhead destroys productivity.
Draw your current org chart alongside your system architecture diagram. Where do team boundaries and system boundaries mismatch? Those mismatches are your highest-priority organizational debt.
Lesson 2: The Four Team Topologies
Matthew Skelton and Manuel Pais identified four fundamental team types. Every team in your engineering org should fit one of these topologies.
Aligned to a single, valuable stream of work (a product, service, or user journey). These are your "value delivery" teams. They should be 5-9 people with full ownership.
Provide internal services that accelerate stream-aligned teams. Examples: deployment platform, observability, authentication. Their "customers" are other engineering teams.
Help stream-aligned teams overcome obstacles. Examples: SRE coaches, security consultants, architecture guidance. They don't own production code — they enable others.
Own components requiring deep specialist knowledge (ML models, payment processing, regulatory engines). Needed when expertise required exceeds what a stream team can maintain.
Categorize every team in your engineering org into one of the four topologies. Identify teams that don't fit any category — these are organizational debt.
Lesson 3: Cognitive Load & Team Boundaries
Every team has a cognitive load capacity — the amount of domain complexity, technical complexity, and tooling complexity it can handle. Exceeding this capacity causes burnout, bugs, and attrition.
The fundamental complexity of the problem domain. Can't be reduced — payment processing is inherently complex. The team must be staffed and skilled for this load.
Complexity from poor tooling, bad process, or unclear requirements. CAN be reduced. Every minute spent fighting deployment scripts is extraneous load.
The "good" cognitive load — learning and growing. Building new features, adopting new patterns. You WANT this load. It's where innovation happens.
For each team, estimate the percentage split between intrinsic, extraneous, and germane cognitive load. Where extraneous load > 30%, identify the platform improvements needed.
Lesson 4: Economic Impact of Team Design
Bad team design is invisible technical debt. It doesn't show up in code scanners, but it destroys velocity, increases coordination costs, and causes attrition.
Every cross-team dependency adds 2-4 weeks of calendar time per feature (handoffs, waiting, miscommunication). With 5 dependencies, a 2-week feature takes 12 weeks.
The percentage of engineering time spent in cross-team meetings, Slack discussions, and alignment sessions. In poorly-structured orgs: 30-50% of time is coordination.
Revenue per engineer (APER) improves 15-30% after team topology optimization. Fewer handoffs = faster delivery = more revenue per engineer.
Calculate your engineering org's "coordination tax" — the percentage of time in cross-team meetings and dependencies. Multiply by engineering budget to get the dollar cost of poor team design.