DevOps Topologies

Matthew Skelton (devopstopologies.com) · article · 2026-10-08 source ↗ Reader 🖥️

Platform Engineering Sociotechnical Architecture Team Topologies Value Streams & Verticals

There is no single universally correct Dev/Ops team structure for achieving DevOps's actual goal — improved delivery of customer and business value — because the right topology is contingent on an organization's product count (via Conway's Law) and on whether its Operations function has the capability and appetite to move from infrastructure-racking toward genuine value-stream alignment; a reference catalog of named anti-patterns and working patterns lets an organization diagnose and choose among structures rather than assume one conformation fits all.

practical · expository — A reference taxonomy page (predecessor material to Skelton & Pais's Team Topologies book) arguing that Dev/Ops team structure should be chosen deliberately from a catalog of named patterns, against the implicit claim that any one structure is universally correct. The capture is thin and largely visual — the catalog of named anti-types (A-G) and types (1-8) is represented mostly as bare image references without the descriptive text that (per the live site) normally accompanies each; only the intro/summary prose and a handful of named patterns carry textual argument here.

Structure

Part	Role
Promotional banner for the Team Topologies book	context
Introduction: DevOps's actual goal is value delivery, not cost/automation/config-management as ends in themselves	premise
Summary: two contingency variables (product count / Conway's Law; Ops's capability and appetite for value-stream alignment) determine which topology fits	evidence/argument
Acknowledgment that most topologies here were previously described elsewhere (Sweeney, DevOpsGuys, Humble/Kim/Edwards), with three new additions by the author (Shared Ops, DevOps-as-a-Service, Temp DevOps Team)	context (attribution)
Anti-Types catalog (seven named bad patterns, A through G)	evidence (diagnostic contrast)
Team Topologies catalog (named good-enough working patterns, including Type 1 Dev/Ops Collaboration, Type 3 Ops as IaaS, and others)	conclusion (prescriptive reference set)

Key terms

Anti-Type B (DevOps Team Silo)
A dedicated 'DevOps team' that itself becomes a new silo positioned between development and operations, defeating the collaborative purpose DevOps is meant to serve. Named explicitly in the text but not elaborated beyond the label in this capture.
Type 1 (Dev and Ops Collaboration)
The baseline 'good' pattern in which development and operations collaborate directly, without an intervening DevOps-team silo.
Type 3 (Ops as IaaS)
A pattern in which Operations' primary contribution is to provide infrastructure as a self-service capability to development teams, rather than acting as a silo that mediates every operational action.
Topology
A named, reusable pattern describing how Dev and Ops responsibilities and team boundaries are arranged relative to each other — used as a diagnostic/heuristic vocabulary rather than a single prescribed design.

Propositions

explicitThe primary goal of any DevOps effort is to improve the delivery of value for customers and the business — not, in itself, to reduce costs, increase automation, or drive everything from configuration management.conf: high
supportsTeam Topologies: Organizing Business and Technology Teams for Fast Flow · p18 — Both insist on evaluating team/organizational structure against actual value/flow delivered, not against proxy activity (automation, cost reduction, or feature-output volume).
explicitcorroboratedDifferent organizations need different Dev/Ops team structures to achieve effective collaboration; there is no single topology that suits every organization.conf: high
supportsTeam Topologies: Organizing Business and Technology Teams for Fast Flow · p19 — Both reject a single, final, universally correct team structure in favor of continuous, context-dependent choice/evolution.
extendsTeam Topologies: Organizing Business and Technology Teams for Fast Flow · p5 — This page's open-ended, many-pattern catalog is the direct historical precursor that Team Topologies later distills into exactly four fundamental topologies, treating most other named types (including several catalogued here) as variations or combinations.
supports ←TBM 390: Governance by Principle, Not by Template · p10 — Batch sibling: both reject a single universal structural template in favor of context-contingent design — Cutler for governance units, Skelton for Dev/Ops team structure.
explicitcorroboratedThe number of products an organization maintains affects which topology fits: fewer products make Dev/Ops collaboration easier because there are fewer natural organizational silos, as Conway's Law predicts.conf: high
supports ←Optimizing teams: A dual perspective on Team Topologies · p8 — Wille's 'minimize dependencies on other teams for discovery, delivery, and release' echoes DevOps Topologies' observation that the number of products/dependencies an organization juggles determines which collaboration topology actually works.
explicitWhether an organization's IT Operations department has the capability or appetite to shift from racking hardware and configuring servers toward genuine alignment with the value stream — with operational concerns taken seriously by software teams — is a second major variable determining which topology fits.conf: high
extendsTeam Topologies: Organizing Business and Technology Teams for Fast Flow · p9 — The contingency this page names informally ('Ops as IaaS' / Shared Ops — whether Ops provides self-service infrastructure) is the direct precursor to Team Topologies' formalized 'Thinnest Viable Platform' concept.
explicitIn practice, a combination of more than one named pattern, or a transition from one pattern to another, is often the best approach rather than adopting a single pure topology.conf: high
explicitA dedicated 'DevOps team' that mediates between development and operations (Anti-Type B) is a recognized bad pattern, distinct from — and inferior to — genuine direct Dev/Ops collaboration (Type 1).conf: medium
supportsTeam Topologies: Organizing Business and Technology Teams for Fast Flow · p10 — The DevOps-Team-Silo anti-pattern is a concrete instance of the kind of inter-team interaction the book later argues is wasteful when it falls outside the three healthy interaction modes (collaboration, X-as-a-Service, facilitating).
explicitThis catalog synthesizes and extends prior published work (Lawrence Sweeney via Ben Kepes's blog; DevOpsGuys' Twelve DevOps Anti-Patterns; Humble, Kim, and Edwards), adding three patterns the author had not seen discussed elsewhere: Shared Ops, DevOps-as-a-Service, and Temp DevOps Team.conf: high

Arguments

Organizations should choose their Dev/Ops team structure deliberately from a reference catalog of named patterns, diagnosed against their own product count and Ops's value-stream readiness, rather than assuming a single correct structure exists. strength: medium

Explicit premises:

The real goal of DevOps is value delivery, not cost/automation/config-management as ends in themselves.
Product count (via Conway's Law) and Ops's capability/appetite for value-stream alignment are the two named variables that determine fit.
Prior published work already documents several of these patterns; this page consolidates and extends that work.

Implicit premises:

A finite, nameable set of recurring patterns (rather than an open-ended design space) is sufficient to characterize most real organizations' Dev/Ops arrangements.
Diagnosing which named pattern an organization currently exhibits is a tractable and useful first step toward improving collaboration — the catalog is treated as actionable, not merely descriptive.

Inferences:

If product count and Ops readiness are the only two named contingency variables, the catalog likely under-specifies other drivers of fit (team size, regulatory constraints, legacy architecture) that the author doesn't name here — a question later addressed more systematically in Team Topologies via cognitive load and the reverse Conway maneuver.

Questions addressed

✅ What determines which Dev/Ops team structure will work for a given organization?
Product count (via Conway's Law) and Operations' capability/appetite to align with the value stream.
✅ Is there a single best DevOps team structure applicable across organizations?
No — the page explicitly rejects a single 'magic conformation', offering a catalog of contingent patterns instead.

Gaps

incompleteThe page's visual taxonomy of seven named anti-types (A-G) and the numbered team topologies is represented in this capture almost entirely through bare image filenames without the descriptive text that normally accompanies each pattern on the live site. Only Anti-Type B, Type 1, and Type 3 receive even a one-line gloss here (via the Sweeney attribution); the remaining anti-types and types (including the three the author claims as original additions — Shared Ops, DevOps-as-a-Service, Temp DevOps Team) are named but not defined in the extractable text.
Read next: The live site (web.devopstopologies.com) or Skelton & Pais's book-length successor (already in this corpus as extract-team-topologies) for the full definitions.
incompleteThe catalog names roughly a dozen patterns as the apparently sufficient reference set, but doesn't address why this particular granularity (rather than fewer or more categories) is the right level of abstraction — a question the author's own later work (Team Topologies) answers by collapsing the field down to exactly four fundamental topologies plus three interaction modes.
Read next: extract-team-topologies#5 (the 'exactly four fundamental team topologies' claim) directly revisits and resolves this.