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:
- Invoke
docs-managementskill for interaction mode guidance - Verify Team Topologies concepts via MCP servers (perplexity)
- Base guidance on Skelton & Pais interaction modes
Three Core Interaction Modes
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
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
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
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
MODE SELECTION MATRIX:
┌────────────────────┬─────────────────┬─────────────────┬─────────────────┐
│ Situation │ Collaboration │ X-as-a-Service │ Facilitating │
├────────────────────┼─────────────────┼─────────────────┼─────────────────┤
│ New product dev │ ✓ Start here │ → Evolve to │ │
│ Discovery work │ ✓ │ │ │
│ Complex integration│ ✓ │ │ │
├────────────────────┼─────────────────┼─────────────────┼─────────────────┤
│ Stable capability │ │ ✓ Default │ │
│ Platform service │ │ ✓ │ │
│ Infrastructure │ │ ✓ │ │
├────────────────────┼─────────────────┼─────────────────┼─────────────────┤
│ Skill gap │ │ │ ✓ │
│ Process improvement│ │ │ ✓ │
│ Adoption help │ │ │ ✓ │
└────────────────────┴─────────────────┴─────────────────┴─────────────────┘Interaction Evolution
TYPICAL EVOLUTION PATTERNS:
Pattern 1: Collaboration → X-as-a-Service
START MID END
┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐
│ A │◄──►│ B │ → │ A │◄──►│ B │ → │ A │───►│ B │
└─────┘ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘
Collaboration Patterns emerge API defined
Pattern 2: Facilitating → Independence
START MID END
┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐
│ EN │───►│ A │ → │ EN │───►│ A │ → │ EN │ │ A │
└─────┘ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘
Heavy help Light touch Team independent
Pattern 3: X-as-a-Service → Collaboration → X-as-a-Service
START MID END
┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐
│ A │───►│ B │ → │ A │◄──►│ B │ → │ A │───►│ B │
└─────┘ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘
Using service Major change together New API versionTeam Type and Interaction Compatibility
INTERACTION COMPATIBILITY MATRIX:
│ Stream │Platform│Enabling│Complicated│
│Aligned │ │ │ Subsystem │
────────────────────┼────────┼────────┼────────┼───────────┤
Stream-Aligned │ Collab │ XaaS │Facilit.│ XaaS │
────────────────────┼────────┼────────┼────────┼───────────┤
Platform │ XaaS │ Collab │Facilit.│ XaaS │
────────────────────┼────────┼────────┼────────┼───────────┤
Enabling │Facilit.│Facilit.│ Collab │ Facilit. │
────────────────────┼────────┼────────┼────────┼───────────┤
Complicated │ XaaS │ XaaS │Facilit.│ Collab │
Subsystem │ │ │ │ │
────────────────────┴────────┴────────┴────────┴───────────┘
XaaS = X-as-a-Service (default, sustainable)
Collab = Collaboration (time-boxed)
Facilit. = Facilitating (time-boxed, knowledge transfer)Interaction Anti-Patterns
ANTI-PATTERNS TO AVOID:
1. PERMANENT COLLABORATION
Problem: Two teams always in collaboration mode
Impact: Neither team fully independent
Fix: Define API, evolve to X-as-a-Service
2. FACILITATING WITHOUT EXIT
Problem: Enabling team never leaves
Impact: Dependency created, not capability
Fix: Time-box engagement, define exit criteria
3. X-AS-A-SERVICE WITHOUT SERVICE
Problem: API claimed but not actually self-service
Impact: Hidden collaboration, provider overloaded
Fix: Invest in documentation, automation
4. COLLABORATION THEATER
Problem: Called collaboration but one team does work
Impact: No knowledge transfer, resentment
Fix: Define joint outcomes, shared work
5. TOO MANY INTERACTION MODES
Problem: Team interacts with 10+ teams intensively
Impact: Cognitive overload, context switching
Fix: Reduce dependencies, consolidate interactions
6. NO EVOLUTION PLANNING
Problem: Interactions never reviewed or evolved
Impact: Sub-optimal patterns persist
Fix: Quarterly interaction reviewInteraction Mapping Template
# Team Interaction Map: [Team Name]
## Current Interactions
### Collaboration Mode
| Partner Team | Purpose | Started | Planned End | Exit Criteria |
|-------------|---------|---------|-------------|---------------|
| [Team] | [Why collaborating] | [Date] | [Date] | [Criteria] |
### X-as-a-Service (We Provide)
| Consumer Team | Service | API/Interface | SLE |
|--------------|---------|---------------|-----|
| [Team] | [What we provide] | [Interface] | [SLE] |
### X-as-a-Service (We Consume)
| Provider Team | Service | API/Interface | Our Usage |
|--------------|---------|---------------|-----------|
| [Team] | [What we consume] | [Interface] | [How we use] |
### Facilitating (We Receive)
| Enabling Team | Capability | Duration | Exit Criteria |
|--------------|------------|----------|---------------|
| [Team] | [What they help with] | [Dates] | [Criteria] |
### Facilitating (We Provide)
| Receiving Team | Capability | Duration | Exit Criteria |
|----------------|------------|----------|---------------|
| [Team] | [What we help with] | [Dates] | [Criteria] |
## Interaction Health
### Working Well
- [Interaction that works well]
- [Another positive interaction]
### Needs Attention
| Interaction | Issue | Proposed Change |
|-------------|-------|-----------------|
| [Teams] | [Problem] | [Solution] |
## Planned Evolution
### Q1 Changes
| Current | Target | Reason |
|---------|--------|--------|
| Collab with Team X | XaaS | API now stable |
### Dependencies to Reduce
| Dependency | Current Impact | Reduction Plan |
|------------|----------------|----------------|
| [Team] | [Impact] | [Plan] |
## Review Schedule
- **Last Review:** [Date]
- **Next Review:** [Date]
- **Reviewer:** [Name]Interaction Review Process
QUARTERLY INTERACTION REVIEW:
1. MAP CURRENT STATE
□ List all team interactions
□ Classify by mode
□ Note duration of each
2. ASSESS HEALTH
□ Which interactions work well?
□ Which are struggling?
□ Any "forever collaborations"?
3. PLAN EVOLUTION
□ What should change mode?
□ What can be reduced?
□ What needs more investment?
4. TAKE ACTION
□ Update interaction agreements
□ Set exit criteria for time-boxed
□ Communicate changesWorkflow
When defining interaction patterns:
- Map Current Interactions: What exists today?
- Classify Modes: Collaboration, X-as-a-Service, or Facilitating?
- Assess Fit: Is each mode appropriate for the situation?
- Identify Anti-Patterns: Any problematic patterns?
- Plan Evolution: What should change and when?
- Document Agreements: Make interactions explicit
- Review Regularly: Quarterly assessment
References
For detailed guidance:
Last Updated: 2025-12-26