Skip to main content

Conway's Law & Team Structures

Align team structure to system architecture: organizations produce designs reflecting their communication structure.

TL;DR​

Conway's Law states: "Any organization that designs a system (defined broadly) will produce a design whose structure is isomorphic to the structure of the organization." In other words: your system's architecture mirrors your org chart. Understand this law deeply to intentionally design teams that produce good architectures. Misaligned teams produce fragmented systems with unclear boundaries, excessive coordination, and conflicting technical decisions.

Learning Objectives​

  • Understand Conway's Law and its implications for system design
  • Learn practical implementation approaches and best practices
  • Recognize common pitfalls and how to avoid them
  • Build sustainable team structures that support desired architectures
  • Intentionally design communication patterns that enable good technical decisions
  • Design for asynchronous communication to reduce coordination friction
  • Recognize and fix misalignments between team structure and technical goals

Motivating Scenario​

Your organization faces a challenge that Conway's Law directly addresses. You want a clean microservices architecture with clear service boundaries. But your org chart has Frontend, Backend, and Database teams. So your system becomes: Frontend Service (everything UI), Backend Service (everything logic), Database (all persistence)—not organized by business capability.

Alternatively, your technical leadership organizes teams by capability: Orders, Payments, Inventory. But leadership reports structure is by region: US, EU, APAC. Team members answer to both, creating confusing communication patterns. Fast decisions become slow as they cross regional and technical boundaries.

Real problem: Structure doesn't match desired architecture. Result: the system architecture evolves to match the reporting structure, not the technical goals.

This section provides frameworks, templates, and practices to align team structure with architectural goals.

Core Concepts​

Conway's Law Formally​

"The structure of any system produced by an organization is isomorphic to the structure of the organization which produced it." — Melvin Conway, 1967

What this means:

  • Organizations communicate in specific patterns
  • System boundaries emerge along communication lines
  • Changing the system architecture requires changing communication patterns
  • Good luck changing communication patterns without changing org structure

Implication: Design the team structure you want, and the architecture will follow. Don't try to impose architecture on misaligned teams.

The Inverse Corollary​

If you want a microservices architecture (independent services), you need autonomous teams per service. If you want a monolith, centralized coordination works. Match structure to technical goals.

Purpose and Value​

Conway's Law & Team Structures matters because it creates clarity without creating bureaucracy. When processes are lightweight and transparent, teams understand what decisions matter and can move fast with safety.

Key Principles​

  1. Clarity: Make the "why" behind processes explicit
  2. Lightweight: Every process should create more value than it costs
  3. Transparency: Document criteria so teams know what to expect
  4. Evolution: Regularly review and refine based on experience
  5. Participation: Include affected teams in designing processes

Implementation Pattern​

Most successful implementations follow this pattern: understand current state, design minimal viable process, pilot with early adopters, gather feedback, refine, and scale.

Governance Without Bureaucracy​

The hard part is scaling without creating approval bottlenecks. This requires clear decision criteria, asynchronous review mechanisms, and truly delegating decisions to teams.

Practical Example​

# Conway's Law & Team Structures - Implementation Roadmap

Week 1-2: Discovery & Design
  - Understand current pain points
  - Design minimal viable process
  - Identify early adopter teams
  - Create templates and documentation

Week 3-4: Pilot & Feedback
  - Run process with pilot teams
  - Gather feedback weekly
  - Make quick adjustments
  - Document lessons learned

Week 5-6: Refinement & Documentation
  - Incorporate feedback
  - Create training materials
  - Prepare communication plan
  - Build tools to support process

Week 7+: Scaling & Iteration
  - Roll out to all teams
  - Monitor adoption metrics
  - Gather feedback monthly
  - Continuously improve based on learning

Core Principles in Practice​

  1. Make the Why Clear: Teams will follow processes they understand the purpose of
  2. Delegate Authority: Push decisions down; keep strategy centralized
  3. Use Asynchronous Review: Documents and ADRs scale better than meetings
  4. Measure Impact: Track metrics that show whether process is working
  5. Iterate Quarterly: Regular review keeps processes relevant

Success Indicators​

✓ Teams proactively engage in the process ✓ 80%+ adoption without enforcement ✓ Clear reduction in the pain point the process addresses ✓ Minimal time overhead (less than 5% of team capacity) ✓ Positive feedback in retrospectives

Pitfalls to Avoid​

❌ Process theater: Requiring documentation no one reads ❌ Over-standardization: Same rules for all teams and all decisions ❌ Changing frequently: Processes need 3-6 months to stabilize ❌ Ignoring feedback: Refusing to adapt based on experience ❌ One-size-fits-all: Different teams need different process levels ❌ No documentation: Unwritten processes get inconsistently applied

Real-World Examples​

Example 1: Monolith vs Microservices​

Centralized Org → Monolith

CEO
├── CTO
│   ├── Backend Team (20 engineers)
│   ├── Mobile Team (8 engineers)
│   └── Web Team (5 engineers)

Result: Monolithic backend with mobile/web clients. Teams coordinate heavily. Backend changes require alignment.

Distributed Org → Microservices

CEO
├── Chief Architect
│   ├── Orders Service Team (5 engineers) - owns order processing end-to-end
│   ├── Payments Service Team (4 engineers) - owns payment processing
│   ├── Inventory Service Team (5 engineers) - owns inventory management
│   ├── Platform Team (3 engineers) - shared infrastructure, logging, deployment

Result: Services align with teams. Teams own their service end-to-end (frontend, backend, ops). Coordination minimal.

Example 2: Regional vs Capability Structure​

By Region (common in global companies)

CEO
├── VP North America
│   └── 20 engineers building features for NA region
├── VP Europe
│   └── 15 engineers building features for EU region
├── VP Asia-Pacific
│   └── 18 engineers building features for APAC region

Result: Duplicated features across regions. Inconsistent technical decisions. Hard to share components.

By Capability (often better for technical alignment)

CEO
├── VP Engineering
│   ├── Search & Discovery (8 engineers across all regions)
│   ├── Checkout & Payments (6 engineers across all regions)
│   ├── Recommendations (7 engineers across all regions)
│   ├── Infrastructure (4 engineers)
│   └── Regional Support (6 engineers supporting all teams)

Result: Shared capabilities, consistent design, easier to maintain scale.

Hybrid Approaches​

Some organizations use matrix structures:

  • Primary: By capability (Orders, Payments, etc.)
  • Secondary: By region (for hiring, timezones, local support)

Engineers have one reporting line (capability) and work with region-specific managers on local issues.

Trade-off: Hybrid is more complex but enables both technical alignment and regional presence.

Practical Team Structure Design​

Step 1: Define Desired System Architecture​

Before organizing teams, know what architecture you want:

  • Monolithic or distributed?
  • By business capability or technical layer?
  • How many teams can stay loosely coupled?
  • What are the critical integration points?

Step 2: Identify Natural Communication Boundaries​

Draw your system:

Orders → Payments → Settlements
Orders → Inventory
Orders → Shipping

Teams that must communicate frequently should be close in org structure. The Orders team coordinates with Payments, Inventory, and Shipping. They should all report to one VP, not scattered across regions.

Step 3: Assign Teams to Services​

One service per team (or one team per service). Team owns:

  • Product requirements (what should this do?)
  • Architecture (how should it be built?)
  • Implementation (writing code)
  • Operations (supporting in production)
  • Upgrades (keeping dependencies current)

This "product ownership" model prevents "not my problem" thinking.

Step 4: Define Integration Points​

Where do teams need to coordinate?

  • API contracts: version, backward compatibility
  • Shared libraries: when to use, versioning
  • Data models: shared events, formats
  • Infrastructure: logging, monitoring, deployment

Document these explicitly. Fewer integration points mean less coordination needed.

This practice connects to:

  • Architecture Governance & Organization (overall structure)
  • Product & Architecture Alignment (cross-team decisions)
  • Reliability & Resilience (ensuring systems stay healthy)
  • Documentation & ADRs (capturing decisions and rationale)
  • Team Structure & Communication (enabling effective collaboration)

Checklist: Before You Implement​

  • Clear problem statement: "This process solves [X]"
  • Stakeholder input: Teams that will use it helped design it
  • Minimal viable version: Start simple, add complexity only if needed
  • Success metrics: Define what "better" looks like
  • Communication plan: How will people learn about this?
  • Pilot plan: Early adopters to validate before scaling
  • Review schedule: When will we revisit and refine?

Self-Check​

  1. Can you explain the purpose of this process in one sentence? If not, it's too complex.
  2. Do 80% of teams engage without being forced? If not, reconsider its value.
  3. Have you measured the actual impact? Or are you assuming it works?
  4. When did you last gather feedback? If >3 months, do it now.

Takeaway​

The best processes are rarely the most comprehensive ones. They're the ones teams choose to follow because they see the value. Start lightweight, measure impact, gather feedback, and iterate. A simple process that 90% of teams adopt is infinitely better than a perfect process that 30% of teams bypass.

Next Steps​

  1. Define the problem: What specifically are you trying to solve?
  2. Understand current state: How do teams work today?
  3. Design minimally: What's the smallest change that creates value?
  4. Pilot with volunteers: Find early adopters who see the value
  5. Gather feedback: Weekly for the first month, then monthly
  6. Refine and scale: Incorporate feedback and expand gradually

References​

  1. ISO/IEC/IEEE 42010: Systems and Software Engineering ↗️
  2. Martin Fowler: Architecture Decision Records ↗️
  3. Forsgren, Humble, Kim: Accelerate ↗️