Align architecture and team structure using inverse Conway maneuver
Deliberately designs team structures to match desired architecture using inverse Conway maneuver. Used when aligning teams with bounded contexts or planning organizational changes to enable specific architectural patterns.
/plugin marketplace add melodic-software/claude-code-plugins/plugin install team-design@melodic-softwareThis skill is limited to using the following tools:
Use this skill when:
Apply inverse Conway maneuver to deliberately design team structure for desired architecture.
Before applying inverse Conway:
docs-management skill for architecture-team alignmentConway's Law:
"Organizations which design systems are constrained to
produce designs which are copies of the communication
structures of these organizations."
— Melvin Conway, 1968
IMPLICATION:
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Team A │ │ Team B │ │ Team C │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Component A │◄──►│ Component B │◄──►│ Component C │
└─────────────┘ └─────────────┘ └─────────────┘
If teams communicate, their components will integrate.
If teams don't communicate, their components won't integrate well.
Inverse Conway Maneuver:
Instead of: Team structure → Architecture (emergent)
Do this: Desired architecture → Team structure (deliberate)
PROCESS:
1. Design the target architecture
2. Identify communication patterns needed
3. Restructure teams to match
4. Architecture follows teams
┌─────────────────────────────────────────────────────────┐
│ TARGET ARCHITECTURE │
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ Service A │ │ Service B │ │ Service C │ │
│ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │
│ │ │ │ │
│ └───────────────┼───────────────┘ │
│ │ │
│ ┌──────┴──────┐ │
│ │ Platform │ │
│ └─────────────┘ │
└─────────────────────────────────────────────────────────┘
│
▼ DESIGN TEAMS TO MATCH
┌─────────────────────────────────────────────────────────┐
│ TEAM STRUCTURE │
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ Team A │ │ Team B │ │ Team C │ │
│ │(Service A)│ │(Service B)│ │(Service C)│ │
│ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │
│ │ │ │ │
│ └───────────────┼───────────────┘ │
│ │ │
│ ┌──────┴──────┐ │
│ │ Platform │ │
│ │ Team │ │
│ └─────────────┘ │
└─────────────────────────────────────────────────────────┘
DDD Bounded Context → Team Mapping:
BOUNDED CONTEXTS TEAMS
┌─────────────────┐ ┌─────────────────┐
│ Order Context │ ───────► │ Order Team │
│ │ │ │
│ • Order │ │ • Full-stack │
│ • OrderItem │ │ • Own deployment│
│ • OrderStatus │ │ • Own data │
└─────────────────┘ └─────────────────┘
┌─────────────────┐ ┌─────────────────┐
│ Payment Context │ ───────► │ Payment Team │
│ │ │ │
│ • Payment │ │ • Full-stack │
│ • Transaction │ │ • Own deployment│
│ • Refund │ │ • Own data │
└─────────────────┘ └─────────────────┘
BENEFITS:
✓ Clear ownership
✓ Reduced coordination
✓ Autonomous deployment
✓ Domain expertise
Where Contexts Meet → Team Interfaces:
┌─────────────────┐ API Contract ┌─────────────────┐
│ Order Context │◄───────────────────►│ Payment Context │
│ │ │ │
│ Team A │ Clear interface │ Team B │
└─────────────────┘ └─────────────────┘
INTEGRATION PATTERNS:
• Shared Kernel: Small shared code (use sparingly)
• Customer-Supplier: One serves the other
• Anti-Corruption Layer: Translate between contexts
• Open Host Service: Published API for many consumers
Architecture Vision:
1. Identify key components/services
2. Define boundaries (bounded contexts)
3. Specify integration patterns
4. Note scaling requirements
5. Consider operational aspects
Questions:
□ What services will exist?
□ What are the boundaries?
□ How will services communicate?
□ What data does each own?
□ What are deployment units?
Communication Matrix:
│ Svc A │ Svc B │ Svc C │ Platform
───────────┼───────┼───────┼───────┼──────────
Service A │ - │ Low │ None │ High
Service B │ Low │ - │ High │ High
Service C │ None │ High │ - │ High
Platform │ High │ High │ High │ -
High = Frequent, detailed coordination
Low = Occasional, well-defined interfaces
None = No direct communication needed
Team Structure Rules:
1. ONE TEAM PER BOUNDED CONTEXT
- Full ownership
- Reduced dependencies
- Clear accountability
2. MINIMIZE TEAM DEPENDENCIES
- If A and B need heavy coordination → same team
- If A and B are independent → separate teams
- If dependency is API-only → separate teams OK
3. SIZE APPROPRIATELY
- 5-9 people per team
- Can understand entire domain
- Manageable cognitive load
4. PLATFORM TEAMS FOR SHARED NEEDS
- Common infrastructure
- Shared services
- Self-service focus
Transition Approaches:
GRADUAL EVOLUTION:
Week 1-4: Pilot new team structure with one boundary
Week 5-8: Expand to adjacent boundaries
Week 9+: Full rollout
BIG BANG (Risky):
Day 1: New structure in place
Requires: Clear communication, quick stabilization
HYBRID:
• Announce new target structure
• Allow organic movement
• Timebox the transition
FROM:
┌─────────────────────────────────┐
│ Monolith Team │
│ (Everyone on everything) │
└─────────────────────────────────┘
TO:
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Orders │ │ Payments │ │ Shipping │
│ Team │ │ Team │ │ Team │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
└─────────────┼───────────────┘
│
┌───────┴───────┐
│ Platform │
│ Team │
└───────────────┘
APPROACH:
1. Identify bounded contexts in monolith
2. Assign teams to contexts
3. Extract services gradually
4. Move code ownership with teams
FROM:
┌──────────────────────────────────────────────┐
│ Feature Teams │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │Feature │ │Feature │ │Feature │ │
│ │ Team 1 │ │ Team 2 │ │ Team 3 │ │
│ └────────┘ └────────┘ └────────┘ │
│ (Work on any part of codebase) │
└──────────────────────────────────────────────┘
TO:
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Stream │ │ Stream │ │ Stream │
│ Aligned 1 │ │ Aligned 2 │ │ Aligned 3 │
│ │ │ │ │ │
│ OWN: Search │ │ OWN: Cart │ │OWN: Checkout│
└─────────────┘ └─────────────┘ └─────────────┘
APPROACH:
1. Identify value streams
2. Map current contributions by stream
3. Assign teams to streams
4. Transfer ownership gradually
Inverse Conway Anti-Patterns:
1. IGNORING CURRENT STATE
- Don't try to change everything overnight
- Acknowledge existing structure
- Plan gradual transition
2. FORCING ARCHITECTURE ON UNWILLING TEAMS
- Need buy-in, not mandate
- Explain the why
- Support the transition
3. CREATING UNREALISTIC BOUNDARIES
- Boundaries should be natural
- Too many teams = too much coordination
- Too few teams = cognitive overload
4. NEGLECTING PLATFORM NEEDS
- Stream-aligned teams need platform support
- Platform teams reduce duplication
- Self-service is the goal
5. IGNORING PEOPLE
- Skills need to match teams
- Career paths matter
- Cultural fit important
# Inverse Conway Analysis: [Organization]
## Current State
### Current Architecture
```text
[Diagram of current architecture]
| Team | Responsibilities | Size |
|---|---|---|
| [Name] | [What they own] | [N] |
| Issue | Impact |
|---|---|
| [Misalignment] | [Effect] |
[Diagram of target architecture]
| Team | Type | Responsibilities |
|---|---|---|
| [Name] | [Type] | [What they'll own] |
| From | To | Frequency | Type |
|---|---|---|---|
| [Team] | [Team] | [H/M/L] | [API/Collab] |
| Risk | Mitigation |
|---|---|
| [Risk] | [Strategy] |
When applying inverse Conway:
For detailed guidance:
Last Updated: 2025-12-26