team-topologies

Organize engineering teams using Team Topologies team types, interaction modes, and fracture planes.

Updated Jul 8, 2026
One-click install
npx skills add https://github.com/HafidJoss/Lummy --skill team-topologies-hafidjoss
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: team-topologies
Source: https://github.com/HafidJoss/Lummy/tree/main/agent/skills/team-topologies
Command: npx skills add https://github.com/HafidJoss/Lummy --skill team-topologies-hafidjoss

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Engineering organizations suffer from slow delivery caused by poorly drawn team boundaries, unclear team charters, and cross-team dependencies that turn every feature into a multi-team project. This Skill applies Skelton and Pais's Team Topologies framework to design team structures that align with Conway's law, respect cognitive load limits, and optimize for fast flow of change. ## Core Features & Use Cases - Four Team Types Classification: Categorize every team as stream-aligned, enabling, complicated-subsystem, or platform, with conversion procedures for component, ops, QA, and architecture teams. - Three Interaction Modes: Declare collaboration, X-as-a-Service, or facilitating modes per team pair, with time-boxing rules, interaction contracts, and evolution triggers. - Cognitive Load Management: Assess team load with surveys and domain-counting heuristics, and publish team APIs so other teams can interact without meetings. - Fracture Planes for Monolith Splits: Split software along business domain, regulatory, cadence, and other seams so each piece fits one team's ownership. - Use Case: A scale-up where every feature touches five teams uses this Skill to map streams of change, form cross-functional stream-aligned teams, convert the ops ticket queue into a platform-as-product team, and cut lead time from nine weeks to under three. ## Quick Start Ask the AI to assess your current engineering org structure using Team Topologies and recommend a target team design with declared interaction modes.

Frequently Asked Questions about team-topologies

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I organize engineering teams for faster delivery?

Align most teams to streams of business change so each owns a slice end to end, then add platform, enabling, and complicated-subsystem teams only to reduce stream teams' cognitive load. Declare explicit interaction modes between teams and size each team's domains to its cognitive capacity.

What are the four team types in Team Topologies?

The four types are stream-aligned (owns a flow of business change end to end), enabling (grows capabilities in other teams, then disengages), complicated-subsystem (owns deep specialist knowledge behind a simple interface), and platform (provides self-service internal products that reduce stream teams' load).

How do I split a monolith so teams can own the pieces?

Split along fracture planes, defaulting to business domain bounded contexts, with regulatory scope, change cadence, and performance isolation as alternatives when evidence justifies them. Form the owning team before extracting code, and verify each seam with git change-coupling and shared-table analysis.

When should a platform team mandate adoption of its tools?

Never, according to Team Topologies. Mandates hide platform failure by removing the feedback signal of voluntary adoption. Run the platform as an internal product with a roadmap, SLAs, and user research so it competes on value and measurably reduces stream teams' cognitive load.

Why does every feature require multiple teams to complete?

This usually means teams are split by technology layer (frontend, backend, QA, ops) rather than by business domain, so every change crosses team boundaries. Re-split along domain fracture planes and form cross-functional stream-aligned teams that can deliver without handoffs.

How many domains can one team own before it overloads?

A team can hold at most one complicated domain, or two to three simple domains alongside its main work. A complex domain needs a dedicated team, and one complicated domain should never be split across two teams. Shed domains before adding headcount when overload appears.