why topologies fail
applying team topologies well is hard. applying it badly is easy — and most orgs do, because each of the four team types has a common failure mode that looks superficially similar but behaves very differently. this lesson is a field guide to the five you'll see most.
- the fake platform team a team branded as platform that's actually a ticket queue. the distinguishing sign: the interface is human, not product. consumers negotiate with engineers instead of reading docs. every new capability requires a conversation.
- the matrix org every engineer belongs to multiple overlapping structures — squads, chapters, guilds, working groups. nobody owns anything cleanly because everybody's attention is split. often imported from a framework (spotify, safe) without understanding that the framework needs clear defaults, not just structures.
- the permanent enabling team an enabling engagement that outlives its purpose. the coach starts doing the work instead of coaching. the host team loses the skill and the ownership. what was supposed to be a three-month facilitation becomes permanent infrastructure.
- the runaway complicated-subsystem a specialist team that keeps acquiring scope. it started with one hard problem; now it owns the pipelines, the deployment, the adjacent tooling, a bit of platform. at some point it stops being specialist and becomes a shadow engineering department.
- the hidden handoff a team that appears stream-aligned on the org chart but operates as two or three sub-teams doing synchronised handoffs. the signal is that the team needs a document to coordinate with itself.
the common root.
four of these failures — fake platform, permanent enabling, runaway
subsystem, hidden handoff — share a single origin: a team's
nominal type drifted away from its actual behaviour, and nobody
corrected it. topologies need maintenance. the matrix org is a
different failure: too many overlapping assignments, so nothing gets
owned.
spot the anti-pattern
eight scenarios
each scenario is a team that's drifted into one of the five anti-patterns. match each one to its failure mode. watch for the nominal team type vs what the team is actually doing.
- the 'platform' team runs a jira queue. teams file tickets for infra, ci, secrets, k8s. the team works through tickets with roughly three-week turnaround. no self-service, no public roadmap. → fake platform team if the interface is a ticket queue, it's not a platform — it's a shared-services bureaucracy. a real platform is consumed self-service, with a public product roadmap.
- every engineer belongs to a 'squad' for delivery, a 'chapter' for craft, and a 'guild' for cross-cutting concerns. standups happen in squads. career ownership is in chapters. reorgs are announced in guilds. → matrix org spotify-model by name, matrix by behaviour. people on three teams have three managers' worth of meetings and one team's worth of focused work. ownership gets diluted, and cognitive load explodes.
- the sre coach has been embedded with the payments team for 18 months. they wrote the runbooks, they own the on-call rotation, and they tune the alerts when payments gets paged. → permanent enabling team enabling teams transfer skill and leave. 18 months of 'helping' with on-call means payments doesn't own its own operations — sre does, without anyone deciding. either formalise sre as platform, or actually leave.
- the ml team started owning one scoring model. now they also own feature stores, model deployment, data quality pipelines, and an internal llm gateway. they've grown to 22 people and still say their mandate is 'the ml stuff'. → runaway subsystem complicated-subsystem teams stay small and narrow on purpose. a 22-person 'ml team' is actually 3-4 specialist teams in a trenchcoat: a platform (feature store, deployment), a complicated-subsystem (the model), and maybe an enabling arm.
- the checkout team ships every release in three repos — web, ios, android — and coordinates the three-way release with a shared google doc. they've been 'one team' on the org chart for two years. → hidden handoff one team shouldn't need a release-coordination doc with itself. the three-platform split is actually three teams, and the google doc is the handoff protocol. either truly merge (shared codebase, shared on-call) or split honestly into three stream-aligned teams.
- the 'developer productivity' team is a tier-2 support function attached to the cto office. they have no public roadmap, their okrs are defined by cto priorities, and their work changes every quarter based on what's urgent. → fake platform team a platform serves internal customers as a product. if the 'platform' reports to an exec whose goals rotate quarterly, it doesn't have customers — it has sponsors. that's a staff team, not a platform team.
- the cloud-migration 'tiger team' was stood up two years ago to move services from on-prem to aws. the migration finished last summer. the team is still there, 'helping with cloud stuff'. → permanent enabling team its purpose ended; it didn't. either dissolve it and return people to stream-aligned work, reframe it as a cloud platform team (with a real product), or accept that it's become a staff body.
- one data team of 18 people serves the whole org: pipelines, dashboards, a/b test analysis, ml scoring. every stream-aligned team with a data need files a request. cycle time on requests is 6 weeks. → fake platform team a shared-services bottleneck wearing platform-team clothes. either build a real data platform (self-service pipelines, tools, a public product), or decentralise data engineers into stream-aligned teams. six-week request cycles mean the shape is wrong.
fixing each one
- fake platform → product discipline or decentralisation either invest in making the platform a real product (self-service, roadmap, discoverable docs, proper onboarding) or acknowledge it can't be one and redistribute the engineers into stream-aligned teams. fake platforms always pick a direction eventually; better to pick on purpose.
- matrix → one primary team per person everyone has exactly one team that owns their delivery and their attention. chapters and guilds can still exist, but as low-cost voluntary communities, not as structures competing for the person's time.
- permanent enabling → finish the engagement write an exit criterion. name a date. if the host team isn't ready by that date, the enabling team leaves anyway — the work stays with the host. if the work genuinely needs an owner long-term, reframe as platform, not as permanent coaching.
- runaway subsystem → split along the spread look at what the team actually does and group the work into the four types. the core complicated-subsystem stays small and specialist; the adjacent platform work becomes a platform team; surrounding stream-aligned surfaces get redistributed.
- hidden handoff → merge or split honestly if the work really is one flow, merge the teams: shared codebase, shared on-call, one release train. if it's really multiple flows, acknowledge that and stop calling it one team. coordination docs are a symptom; the disease is org-chart vs reality mismatch.
next: evolving topologies — how to move teams between types without destroying delivery momentum.