Engineering Org Design

How you organize your engineering teams determines the architecture of your systems (Conway’s Law). A poorly structured org produces a poorly structured codebase. The right org design enables teams to move fast independently while staying aligned on company goals.

---

Conway’s Law

"Any organization that designs a system will produce a design 
 whose structure is a copy of the organization's communication 
 structure." — Melvin Conway, 1967

Example:
  Org structure: Frontend Team | Backend Team | Database Team
  System: Monolithic frontend → API → Monolithic database
  
  Org structure: Product A Team | Product B Team | Platform Team
  System: Product A service | Product B service | Shared platform
  
Inverse Conway Maneuver:
  Design the org structure to match the architecture you WANT
  Instead of: org → architecture
  Do: desired architecture → org

---

Team Topologies

Stream-Aligned Teams:
  Own a product area end-to-end (frontend + backend + data)
  Aligned to a stream of business value
  Example: "Payments Team" owns all payment features
  
  Size: 5-9 people
  Ownership: Full stack for their domain
  Goal: Deliver business value autonomously
  
Enabling Teams:
  Help stream-aligned teams overcome capability gaps
  Temporary engagement, not permanent dependency
  Example: "Security Enablement" helps teams adopt security practices
  
  Size: 3-5 specialists
  Engagement: Time-boxed (1-4 weeks with each team)
  Goal: Teach and transfer knowledge, then move on
  
Complicated-Subsystem Teams:
  Own technically complex components that need specialists
  Example: "ML Infrastructure" owns model serving platform
  
  Size: 3-7 deep specialists
  Ownership: Specific complex component
  Goal: Shield other teams from complexity
  
Platform Teams:
  Build internal platforms that accelerate stream-aligned teams
  Example: "Developer Platform" owns CI/CD, deployment, monitoring
  
  Size: 5-12 people
  Ownership: Internal developer tools and infrastructure
  Goal: Reduce cognitive load on stream-aligned teams

---

Scaling Thresholds

1-10 engineers:
  One team, no org design needed
  Everyone talks to everyone
  
10-30 engineers:
  2-4 teams needed
  First team boundaries
  Need: shared coding standards, architecture principles
  
30-100 engineers:
  5-12 teams
  Communication overhead increases
  Need: platform team, team APIs, architecture review
  
100-300 engineers:
  Groups of teams (departments)
  Need: engineering managers, tech leads per team
  Need: Internal developer platform
  
300-1000 engineers:
  Multiple departments, VP-level leadership
  Need: Architecture council
  Need: Inner source practices
  Need: Developer experience team
  
1000+ engineers:
  Engineering divisions
  Conway's Law dominates
  Need: Intentional org design reviews quarterly

---

Team Interaction Modes

Collaboration:
  Two teams work together for a period
  When: New problems, unclear boundaries
  Duration: Days to weeks
  Example: Payments + Fraud team building new fraud detection
  
X-as-a-Service:
  One team provides a clear API/service to others
  When: Well-defined component, clear interface
  Duration: Ongoing
  Example: Platform team provides deployment pipeline
  
Facilitation:
  One team helps another learn a new skill
  When: Capability gap in stream-aligned team
  Duration: 1-4 weeks
  Example: Security team helping product team adopt threat modeling

---

Anti-Patterns

Anti-Pattern	Consequence	Fix
Teams aligned to tech layers	Cross-team coordination for every feature	Stream-aligned teams by product area
No platform team at 50+ engineers	Every team reinvents infrastructure	Platform team at ~30 engineers
Matrix reporting	Confused priorities, slow decisions	Clear single reporting line
Teams too large (>9)	Communication overhead, slow decisions	Split by subdomain
No dedicated team for tech debt	Debt accumulates, velocity slows	20% time or dedicated enabling team

Organizations are a technology. Design them intentionally, review them regularly, and restructure before Conway’s Law creates an architecture you don’t want.