inverse-conway

What this skill does

# Inverse Conway Maneuver Skill

## When to Use This Skill

Use this skill when:

- **Inverse Conway tasks** - Working on align architecture and team structure using inverse conway maneuver
- **Planning or design** - Need guidance on Inverse Conway approaches
- **Best practices** - Want to follow established patterns and standards

## Overview

Apply inverse Conway maneuver to deliberately design team structure for desired architecture.

## MANDATORY: Documentation-First Approach

Before applying inverse Conway:

1. **Invoke `docs-management` skill** for architecture-team alignment
2. **Verify Conway patterns** via MCP servers (perplexity)
3. **Base guidance on Team Topologies and DDD literature**

## Conway's Law

```text
Conway'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

```text
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     │                         │
│                 └─────────────┘                         │
└─────────────────────────────────────────────────────────┘
```

## Architecture-Team Alignment

### Bounded Contexts to Teams

```text
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
```

### Integration Seams

```text
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
```

## Applying Inverse Conway

### Step 1: Define Target Architecture

```text
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?
```

### Step 2: Map Communication Needs

```text
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
```

### Step 3: Design Team Structure

```text
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
```

### Step 4: Plan Transition

```text
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
```

## Common Patterns

### Monolith to Microservices

```text
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
```

### Feature Teams to Stream-Aligned

```text
FROM:
┌──────────────────────────────────────────────┐
│              Feature Teams                    │
│  ┌────────┐  ┌────────┐  ┌────────┐          │
│  │Feature │  │Fea