Team Topologies & Interaction Modes

Team Topologies is the most influential modern framework for designing engineering organizations. Matthew Skelton and Manuel Pais's 2019 book operationalized Conway's Law into a practical set of team types and interaction modes. The core insight: how teams interact is more important than what teams exist. Most organizations focus on team composition and responsibilities; Team Topologies focuses on the shape of communication between teams. When the interactions are wrong, no amount of team redesign helps.

Team Topologies: 4 team types, 3 interaction modes, with Conway's Law and cognitive load

Origin

Matthew Skelton and Manuel Pais worked for years as DevOps and delivery consultants helping organizations scale engineering. They noticed that successful teams — at companies like Spotify, ING, Etsy, and Amazon — shared structural patterns even across very different cultures. They also noticed that failed transformations tended to fail in specific, repeated ways.

In 2019, they published Team Topologies: Organizing Business and Technology Teams for Fast Flow. The book synthesized:

Conway's Law (1968)
Mike Cohn's work on cross-functional teams
Don Reinertsen's principles of product development flow
Spotify's "Squads, Tribes, Guilds" experience
DORA research on high-performing organizations
Cognitive load research from cognitive science

The framework has since been adopted at scale by ING, Adidas, Uber, and many others. It is the de facto standard for modern engineering org design.

The Framework

The Four Team Types

Team Topologies identifies four (and only four) legitimate team types:

1. STREAM-ALIGNED TEAM
   - Aligned to a single, valuable stream of work
   - Delivers value directly to customers or users
   - Owns a product or service end-to-end
   - Usually 5-9 people

   Examples: "Payments team," "Checkout team,"
             "Mobile app team"

2. ENABLING TEAM
   - Helps stream-aligned teams acquire missing capabilities
   - Focus on research, learning, and temporary pairing
   - Dissolves or rotates as needs evolve
   - Usually 3-5 people

   Examples: "Testing practices team,"
             "CI/CD adoption team,"
             "Cloud migration team"

3. COMPLICATED-SUBSYSTEM TEAM
   - Owns a part of the system requiring specialist expertise
   - Reduces cognitive load for stream-aligned teams
   - Only exists when the subsystem genuinely requires specialists
   - Usually 3-7 people

   Examples: "Video codec team,"
             "Mathematical modeling team,"
             "Realtime embedded team"

4. PLATFORM TEAM
   - Provides internal services that other teams consume
   - Abstracts underlying complexity
   - Has internal customers (stream-aligned teams)
   - Usually 5-12 people; may be a grouping of sub-platform teams

   Examples: "Kubernetes platform team,"
             "Internal developer platform,"
             "Data platform team"

The Three Interaction Modes

More important than team types are the interaction modes — how teams work together. Team Topologies identifies exactly three healthy modes:

1. COLLABORATION
   - Two teams work closely together for a bounded period
   - High-bandwidth communication, shared work, joint ownership
   - Used for: exploration, new domains, breaking ground

   Duration: weeks to months (not permanent)
   Cognitive cost: high

   Healthy: "Stream-aligned team and platform team collaborate
            to design a new internal platform capability."

   Unhealthy: "Two teams collaborate indefinitely on a shared
              codebase with no clear ownership."

2. X-AS-A-SERVICE
   - One team consumes a service provided by another
   - Communication is low-bandwidth, contract-based
   - Provider exposes a well-defined API/product
   - Consumer uses it without engaging with internals

   Duration: indefinite (this is a stable mode)
   Cognitive cost: low for both sides

   Healthy: "Stream-aligned team consumes the platform team's
            deployment service. They don't know or care how
            it works internally."

   Unhealthy: "Platform team claims to be 'as-a-service' but
              the consumers have to understand all internals
              to use it."

3. FACILITATING
   - One team actively helps another team learn or adopt
   - Temporary, explicit, time-bounded
   - Enabling teams typically in this mode

   Duration: weeks to months (time-bounded)
   Cognitive cost: moderate, decreasing over time

   Healthy: "Enabling team facilitates a stream-aligned team
            learning property-based testing; after 6 weeks,
            the stream-aligned team is self-sufficient."

   Unhealthy: "Enabling team becomes a permanent crutch;
              stream-aligned teams never learn."

The Pairing Rule

A core principle: each team pair should have exactly one interaction mode at a time.

If Team A and Team B are collaborating on Project X...
...and also consuming each other as-a-service for Project Y...
...they will blur the modes and both will degrade.

Solution: Explicitly name the mode for each interaction, or
restructure so each team pair has exactly one mode.

Cognitive Load

Team Topologies formalizes cognitive load as the primary scaling constraint. Three types:

1. Intrinsic cognitive load
   - Inherent to the task
   - "Understanding algorithms"
   - Cannot be reduced; can only be matched with appropriate
     staffing

2. Extraneous cognitive load
   - From the environment, tooling, process
   - "Dealing with bad deployment tooling"
   - Should be minimized aggressively

3. Germane cognitive load
   - Load used for productive learning and problem-solving
   - The load you want to enable

Team Topologies argues: teams should be sized to keep intrinsic
and germane load high, while platforms and enabling teams drive
extraneous load down.

A team with too much cognitive load produces bad code, misses communication, and bottlenecks the system.

The Platform-Team Pattern

The platform team is the most strategically important team type in Team Topologies, and the most commonly misunderstood.

Platform teams:
  - Build internal products for stream-aligned teams
  - Their "customers" are other engineers
  - Have real product management, roadmap, user research
  - Compete with external alternatives (teams can refuse to use
    the platform)
  - Must deliver actual ergonomic gains, not just mandate adoption

Anti-platform:
  - "Infrastructure team" that stream-aligned teams must go
    through to get anything done
  - Gatekeepers, not service providers
  - Measured by things built, not by consumption or satisfaction
  - No product orientation

A good platform team is an internal product organization. Teams using the platform are delighted; teams that try alternatives come back voluntarily.

How to Use It

Designing an Engineering Org

1. Start with stream-aligned teams.
   What are the valuable streams of work? One team per stream.

2. Assess cognitive load.
   For each stream-aligned team, is the work within their capacity?
   If not, what would reduce their load?

3. Identify platform needs.
   What is common across stream-aligned teams that could be built
   once? Those are platform candidates.

4. Identify enabling needs.
   What capabilities do stream-aligned teams need to acquire?
   Those are enabling team candidates (usually temporary).

5. Identify complicated-subsystem needs.
   Are there parts of the system that genuinely require specialists?
   (Be strict — most "specialist" work doesn't actually need a
   dedicated team.)

6. Design the interactions.
   For each pair of teams that must work together, pick exactly
   one interaction mode.

7. Iterate.
   Check whether the structure is actually producing fast flow.
   Adjust as needed.

Diagnosing an Existing Org

Walk through the diagnostic questions:

- Which of my teams are stream-aligned? (Should be most of them.)
- Do my platform teams have internal customers and a product
  mindset?
- Are my enabling teams time-bounded or permanent?
- Are complicated-subsystem teams justified by genuine specialism?
- For each team pair that works together, what's their interaction
  mode? Is it healthy?
- Are any teams above their cognitive load?

Making a Transition

Team Topologies transitions are usually gradual:

Typical phases:
  1. Audit current team structure and interactions (~2 weeks)
  2. Design target structure (~4 weeks)
  3. Pilot new structure on 1-2 teams (~1 quarter)
  4. Expand to rest of organization (~2-4 quarters)
  5. Stabilize and iterate (ongoing)

Common mistake: trying to reorg everything in one quarter.
Usually produces chaos that sets back the transition by a year.

Tech & Company Example

Example 1: A Mid-Size SaaS Company Reorg

Before:
  25 engineering teams, organized functionally:
    - 5 front-end teams
    - 8 back-end teams
    - 2 data teams
    - 1 DevOps team
    - 3 QA teams
    - 6 specialty teams (security, payments, etc.)

Pain points:
  - Features required 4-6 teams to coordinate
  - Average cycle time for a customer-visible change: 6 weeks
  - DevOps team overwhelmed, bottleneck on everything
  - QA teams detached from engineering context

Target (after Team Topologies-informed reorg):
  15 stream-aligned teams:
    - Each aligned to a customer-facing domain
    - Each has front-end, back-end, QA embedded
    - Each owns their services end-to-end

  2 platform teams:
    - Deployment & infrastructure platform
    - Data & analytics platform
    Both with product managers, roadmaps, customer (team) success
    metrics.

  1 complicated-subsystem team:
    - Payments (regulatory complexity, genuine specialism)

  2 enabling teams:
    - SRE enabling team (teaching reliability practices; time-bounded)
    - Security enabling team (teaching secure coding; time-bounded)

Interaction modes:
  - Stream-aligned teams consume platform teams as-a-service
  - Enabling teams facilitate stream-aligned teams in bounded engagements
  - Collaboration is the exception, used for new initiatives

Results 12 months later:
  - Cycle time: 6 weeks → 10 days (median)
  - Inter-team coordination meetings reduced ~60%
  - Platform team adoption: 85% of deploys via the new platform
  - SRE enabling team successfully facilitated 12 teams, then
    dissolved into embedded SRE roles

Example 2: Platform Team Success vs. Failure

Platform Team A (Success):
  - Builds internal developer platform
  - Has a product manager
  - Runs quarterly surveys of stream-aligned teams
  - Publishes roadmap based on team feedback
  - Measures: platform adoption rate, time-to-first-deploy for
    new teams, NPS among engineers
  - Result: 90% of deploys through platform; teams actively
    request platform features

Platform Team B (Failure):
  - "Infrastructure team" that owns shared tools
  - No product manager
  - Roadmap driven by VP's priorities
  - Measures: uptime, tickets closed
  - Stream-aligned teams treat platform as bureaucratic barrier
  - Teams build shadow tooling to avoid the platform

The difference isn't skill — it's interaction mode.
Platform Team A operates as X-as-a-service with genuine product thinking.
Platform Team B operates as a gatekeeper (essentially a collaboration
mode with dysfunction).

Example 3: The Collaboration Anti-Pattern

Teams A and B share ownership of a service. They've done this for
18 months.

Symptoms:
  - Incidents: "We thought they were on-call."
  - Features: blocked by "we need B to review this."
  - Technical debt: "That part is B's problem."
  - Hiring: unclear which team new engineers join.

Diagnosis:
  - Collaboration was the right mode during the service's initial
    development.
  - It has persisted past its useful window.
  - What should be X-as-a-service (one team provides; other consumes)
    is still being run as collaboration.

Fix:
  - Explicit decision: which team owns the service?
  - If A owns it: A is the provider; B consumes via API only.
  - If B owns it: vice versa.
  - If genuinely shared ownership is required: merge the teams.

Result:
  - 3 months later, on-call responsibility is clear.
  - Incidents drop.
  - Feature velocity increases for both teams.

The right interaction mode is usually X-as-a-service; collaboration is a temporary, expensive mode that many teams persist in too long.

When It Works

Scaling engineering organizations past ~30 engineers
Platform engineering investments
DevOps and SRE transitions
Microservices adoption (needs matching team structure)
Post-acquisition integration
Any engineering organization that struggles with inter-team coordination

When It Does Not Work

Very small companies — Under 20 engineers, simpler organic structures often work better.
Mandated-adoption cultures — If teams cannot refuse to use a platform, "as-a-service" becomes coercion, not collaboration.
High-churn environments — Team Topologies assumes teams are stable enough to develop identity and domain mastery; very high attrition breaks this.
Political orgs — Where team structure is driven by power dynamics rather than flow, Team Topologies prescriptions are ignored.
Highly regulated environments — Some regulatory frameworks require specific role separations that complicate stream-aligned team design.

Common Failure Modes

Team Type

Proliferating Team Types — Inventing new team types beyond the four. Usually a sign of confused thinking about what teams are actually for.
Misclassifying Platform — Calling a gatekeeping infrastructure team a "platform team" doesn't change its behavior. The orientation must match.
Permanent Enabling Teams — Enabling teams are time-bounded. Permanent ones become a different kind of team (usually a broken platform or consulting group).
Cognitive Load Blindness — Ignoring cognitive load when sizing teams; overloading them with too much surface area.

Interaction Mode

Mode Blur — Not explicitly naming the mode for each team pair. Teams drift between modes inconsistently.
Default Collaboration — Treating collaboration as the default when X-as-a-service should be. Collaboration is expensive; reserve it for genuinely new territory.
Fake As-a-Service — A team calls itself "as a service" but consumers need deep internal knowledge to use them. Not a service; a trap.
Ungoverned Facilitation — Enabling teams that never dissolve. Facilitating without exit criteria.

Cultural

Reorg as Silver Bullet — Reshaping teams without addressing underlying culture, trust, or incentive issues. Team Topologies isn't magic.
Not Listening to Teams — Designing team structure top-down without input from the teams affected. Teams know the pain better than executives.
Framework Zealotry — Enforcing Team Topologies orthodoxy in contexts where simpler structures would work. Not every company needs four team types.

Platform-Specific

Platform-as-Control — Platform used to enforce standards rather than enable teams. Stream-aligned teams work around it.
Platform Without Users — Platform built without consulting consumers. No adoption.
Platform Over-Investment — Platform team absorbs 30%+ of engineering capacity. The "efficiency" gains never materialize because the platform itself becomes the bottleneck.