interaction-patterns

What this skill does

# Team Interaction Patterns Skill

## When to Use This Skill

Use this skill when:

- **Interaction Patterns tasks** - Working on team interaction modes and their evolution over time
- **Planning or design** - Need guidance on Interaction Patterns approaches
- **Best practices** - Want to follow established patterns and standards

## Overview

Define and evolve team interaction modes using Team Topologies interaction patterns.

## MANDATORY: Documentation-First Approach

Before defining interaction patterns:

1. **Invoke `docs-management` skill** for interaction mode guidance
2. **Verify Team Topologies concepts** via MCP servers (perplexity)
3. **Base guidance on Skelton & Pais interaction modes**

## Three Core Interaction Modes

```text
Team Topologies Interaction Modes:

┌─────────────────────────────────────────────────────────────────┐
│                    INTERACTION MODES                            │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │                   COLLABORATION                           │  │
│  │                                                           │  │
│  │   ┌───────┐            ┌───────┐                         │  │
│  │   │ Team  │◄──────────►│ Team  │                         │  │
│  │   │   A   │  working   │   B   │                         │  │
│  │   └───────┘  together  └───────┘                         │  │
│  │                                                           │  │
│  │   High bandwidth • Shared goals • Time-limited           │  │
│  └──────────────────────────────────────────────────────────┘  │
│                                                                 │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │                  X-AS-A-SERVICE                           │  │
│  │                                                           │  │
│  │   ┌───────┐            ┌───────┐                         │  │
│  │   │ Team  │───────────►│ Team  │                         │  │
│  │   │   A   │  consumes  │   B   │                         │  │
│  │   └───────┘    API     └───────┘                         │  │
│  │                                                           │  │
│  │   Clear API • Low coupling • Sustainable long-term       │  │
│  └──────────────────────────────────────────────────────────┘  │
│                                                                 │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │                   FACILITATING                            │  │
│  │                                                           │  │
│  │   ┌───────┐            ┌───────┐                         │  │
│  │   │Enabling│──────────►│ Team  │                         │  │
│  │   │ Team  │   helps    │   A   │                         │  │
│  │   └───────┘  improve   └───────┘                         │  │
│  │                                                           │  │
│  │   Knowledge transfer • Time-boxed • Exit planned         │  │
│  └──────────────────────────────────────────────────────────┘  │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘
```

## Collaboration Mode

```text
COLLABORATION: Working closely together on shared goals

CHARACTERISTICS:
• High-bandwidth communication
• Shared responsibility for outcomes
• Blurred team boundaries (temporarily)
• Frequent synchronization
• Joint decision-making

WHEN TO USE:
• New product/service development
• Complex integration work
• Innovation or discovery phases
• Major architectural changes
• Rapid problem-solving

DURATION:
• Time-boxed (weeks to months)
• NOT sustainable long-term
• Should evolve to X-as-a-Service

SIGNS IT'S WORKING:
✓ Joint ownership of outcomes
✓ Frequent informal communication
✓ Shared understanding develops
✓ Problems solved together
✓ Knowledge transfers both ways

ANTI-PATTERNS:
✗ Collaboration without end date
✗ One team doing all the work
✗ No knowledge transfer happening
✗ Dependencies increasing
✗ "Collaboration" as excuse for poor boundaries

EXAMPLE:
┌─────────────────────────────────────────┐
│ Payments Team + Security Team           │
│                                         │
│ Goal: Implement PCI compliance          │
│ Duration: 3 months                      │
│ Exit: Security becomes X-as-a-Service   │
│                                         │
│ Activities:                             │
│ • Joint design sessions                 │
│ • Shared Slack channel                  │
│ • Pairing on implementation             │
│ • Knowledge transfer sessions           │
└─────────────────────────────────────────┘
```

## X-as-a-Service Mode

```text
X-AS-A-SERVICE: Consuming another team's capability via API

CHARACTERISTICS:
• Clear, versioned API
• Minimal coordination needed
• Teams operate independently
• Provider-consumer relationship
• Self-service when possible

WHEN TO USE:
• Stable, well-defined capabilities
• Platform team offerings
• Standard infrastructure needs
• Commoditized services
• After collaboration establishes patterns

DURATION:
• Long-term sustainable
• Default interaction mode
• Can evolve from Collaboration

SIGNS IT'S WORKING:
✓ Consumers self-serve successfully
✓ Provider rarely contacted
✓ Clear documentation exists
✓ Versioning allows evolution
✓ Both teams operate independently

ANTI-PATTERNS:
✗ Constant back-channel requests
✗ Documentation always outdated
✗ Breaking changes without warning
✗ Provider becomes bottleneck
✗ Service doesn't meet needs

EXAMPLE:
┌─────────────────────────────────────────┐
│ Stream-aligned Team → Platform Team     │
│                                         │
│ Service: Container Deployment           │
│ Interface: CLI + Terraform module       │
│ Documentation: Self-service guide       │
│ Support: Office hours + Slack           │
│                                         │
│ Consumer:                               │
│ • Reads docs                            │
│ • Uses CLI to deploy                    │
│ • Files issues if blocked               │
│ • Attends office hours for questions    │
└─────────────────────────────────────────┘
```

## Facilitating Mode

```text
FACILITATING: Helping another team improve their capability

CHARACTERISTICS:
• Enabling team leads
• Knowledge transfer focus
• Teaching over doing
• Time-boxed engagement
• Clear exit criteria

WHEN TO USE:
• Capability gap identified
• New technology adoption
• Process improvement needs
• Team struggling with patterns
• Skills development required

DURATION:
• Time-boxed (weeks to few months)
• Exit when capability transferred
• NOT meant to be permanent

SIGNS IT'S WORKING:
✓ Receiving team gains skills
✓ Less help needed over time
✓ Enabling team can exit
✓ Receiving team owns capability
✓ Knowledge documented

ANTI-PATTERNS:
✗ Facilitating team does the work
✗ No skill transfer happening
✗ Dependency created
✗ Engagement drags on indefinitely
✗ Receiving team passive

EXAMPLE:
┌─────────────────────────────────────────┐
│ DevOps Enablement → Checkout Team       │
│                                         │
│ Goal: Improve CI/CD maturity            │
│ Duration: 6 weeks                       │
│ Exit: Team owns their pipeline          │
│                                         │
│ Activities:                             │
│ Week 1-2: Assessment & planning         │
│ Week 3-4: Pairing on improvements       │
│ Week 5: Team leads implementation       │
│ Week 6: Documentation & handoff         │
└─────────────────────────────────────────┘
```

## Interaction Mode Selection

```text
MODE SELECTION MATRIX:

┌────────────────────┬─────────────────┬─────────────────┬─────────────────┐
│ Situation          │ Collaboration   │ X-as-a-Service  │ Facilitating    │
├────────────────────┼────────────────