Team Topologies¶
Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press.
Cited by¶
8 citations across 8 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Conway's Law
- Start with a single engineering organization of four teams — Auth, Billing, Catalog, Search — that historically sat in one room and shipped a monolith: one codebase, tightly coupled across all four domains, because the producer-graph was densely connected (everyone talked to everyone, so every cross-domain interface was cheap to negotiate and none was enforced).
This sourceDevelops the inverse Conway maneuver and the distributed-monolith failure mode — re-cutting team boundaries to make the desired service architecture arise as the producer-graph's image. (
- Start with a single engineering organization of four teams — Auth, Billing, Catalog, Search — that historically sat in one room and shipped a monolith: one codebase, tightly coupled across all four domains, because the producer-graph was densely connected (everyone talked to everyone, so every cross-domain interface was cheap to negotiate and none was enforced).
Mechanisms¶
- Artifact Boundary Refactor
- Centralized Infrastructure Platform
- The guarding discipline is to treat the platform as a product — a thin, opt-in, well-supported surface with a genuine service boundary — so it earns adoption instead of compelling it,
This sourceAdvocates treating an internal platform as a product for the teams that consume it.
- The guarding discipline is to treat the platform as a product — a thin, opt-in, well-supported surface with a genuine service boundary — so it earns adoption instead of compelling it,
- Cross-Team Interface Contract
- The discipline that guards against it is to treat contracts as instruments for stable boundaries: if a seam needs constant renegotiation and its contract keeps churning, that is a signal to restructure — hand the boundary to an artifact refactor or a team redesign — rather than to write more contract.
This sourcePresents stable, clearly bounded team interfaces and low-interaction service relationships as a basis for fast flow.
- The discipline that guards against it is to treat contracts as instruments for stable boundaries: if a seam needs constant renegotiation and its contract keeps churning, that is a signal to restructure — hand the boundary to an artifact refactor or a team redesign — rather than to write more contract.
- Inverse Conway Design Intervention
- The discipline that guards against this is to run it only when the desired architecture is clear and genuinely worth a reorganization, to respect each team's cognitive-load limit, and to pair it with the domain boundary review that supplies — and justifies — the target.
This sourceTreats bounded team cognitive load as a constraint on assigned responsibilities and software-system boundaries.
- The discipline that guards against this is to run it only when the desired architecture is clear and genuinely worth a reorganization, to respect each team's cognitive-load limit, and to pair it with the domain boundary review that supplies — and justifies — the target.
- Ownership Boundary Refactor
- It restores the recurring principle that one cohesive component should have exactly one owning team, which cuts the standing coordination cost of split or absent ownership.
This sourceAssigns a cohesive bounded component to one owning team.
- It restores the recurring principle that one cohesive component should have exactly one owning team, which cuts the standing coordination cost of split or absent ownership.
- Pre-Refactor Operating-Model Check
- Team Topologies frames the ceiling precisely: a team's ownership should be bounded by its cognitive load, and a module no team can hold will fail on the operating-model side however clean its code.
This sourceTeam Topologies treats manageable team cognitive load as a design criterion when assigning service and ownership boundaries.
- Team Topologies frames the ceiling precisely: a team's ownership should be bounded by its cognitive load, and a module no team can hold will fail on the operating-model side however clean its code.
- Team Topology Review Workshop
- It is the natural front end to an inverse-Conway maneuver: deliberately shaping the communication structure so that the architecture you want emerges, instead of letting an inherited org dictate the design.
This sourcePresents the inverse Conway maneuver as deliberately evolving team and communication structures so that the desired architecture can emerge rather than inheriting architecture from the existing organization.
- It is the natural front end to an inverse-Conway maneuver: deliberately shaping the communication structure so that the architecture you want emerges, instead of letting an inherited org dictate the design.
Verification¶
Does it exist? Confirmed. This work's ISBN resolves to a registered record, which fixes its identity. That is all it fixes.
Does it back the claim? Not recorded. Neither this nor any other of the 8 citations of this work carries a recorded support check.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Links previously used in the corpus¶
Before the registry existed this work was also linked 2 other ways.
- https://itrevolution.com/wp-content/uploads/2022/06/TTOP_excerpt.pdf ×2
- https://search.worldcat.org/oclc/1108538721 ×1
Registry ID ref:ac17b1535cd3 · see in the full table