Team Topologies: The Org Chart Is an Architecture Decision

I've spent most of this blog talking about system boundaries — reference architectures, evaluation harnesses, decision-logging. Team Topologies, the model Matthew Skelton and Manuel Pais laid out in their 2019 book, is about a different boundary that shapes an AI platform just as much: the one between teams. Conway's Law says your system's architecture will mirror your communication structure whether you plan for it or not. Team Topologies is what happens when you stop treating that as an unfortunate side effect and start designing the org chart on purpose.

Four team types, not an infinite variety of them

The model's core claim is that almost every effective team in a software organization is one of four types, and treating a team as the wrong type is where most platform bottlenecks actually come from.

The stream-aligned team is the default, and it should be the majority of your teams: it owns a flow of value end-to-end, from a customer-facing capability or a business domain, and it can ship without waiting on a queue somewhere else. The platform team exists to give stream-aligned teams self-service capability — compute, inference infrastructure, shared evaluation tooling — so that "add a feature" doesn't secretly mean "also provision infrastructure by hand." The complicated-subsystem team owns something that genuinely needs deep, rare specialist knowledge — a custom retrieval-ranking model, a fine-tuning pipeline, a real-time inference optimization layer — and its job is to encapsulate that complexity so nobody else has to hold it in their head. The enabling team is deliberately temporary: it exists to build a capability into another team's skills — evals, prompt engineering practice, observability — and then leave, on purpose, once that team can operate independently.

That last property is the one people miss. An enabling team that never leaves isn't an enabling team anymore, it's a dependency, and it's usually a sign the "temporary" coaching relationship quietly became a permanent bottleneck nobody decided to create.

Three ways teams are allowed to interact

The other half of the model, and the half that actually prevents the bottlenecks, is that it constrains how teams interact — not with unlimited ad hoc collaboration, but with three named modes, each with a different cost. X-as-a-service is the cheapest: one team consumes another's output through a well-defined interface, with no ongoing coordination overhead — a stream-aligned team pulling inference capacity from a platform team through an API is the shape you want most of the time. Collaboration is expensive but sometimes necessary: two teams working closely together, typically for a bounded period, because the problem genuinely isn't well understood enough yet to hand off through an interface. Facilitating is what an enabling team does: one team helps another get unstuck or level up, with an explicit end date.

The mistake I see most often in AI teams is running everything as collaboration by default, because it feels helpful and fast in the moment. It isn't — it's the most expensive mode you have, and it doesn't scale past a couple of teams before everyone's calendar is coordination meetings. The fix isn't less collaboration, it's collaboration used deliberately for the narrow cases that actually need it, with an explicit plan to move the relationship to X-as-a-service once the interface is well enough understood to define.

Why this maps onto AI platforms specifically

AI platform teams have a structural temptation Team Topologies warns against directly: because the technology is unfamiliar and moving fast, it's tempting to route everything through a small group of specialists — the people who understand embeddings, prompting, and eval design — instead of building that capability into stream-aligned teams. That group starts as a reasonable complicated-subsystem or enabling team and quietly becomes a queue, because every team building an AI feature now has to wait on the two or three people who "actually understand this stuff."

The fix I've used is the enabling-team pattern taken literally: a small central team's explicit mandate is to make itself progressively less necessary, by turning what it knows into the platform-level primitives I've written about before — reference architectures, shared eval harnesses, guardrail components — and coaching stream-aligned teams to use them directly. The central team's job isn't to keep building the AI features. It's to work itself out of the critical path.

The team boundary is a design decision, same as any interface

Cynefin tells you how to approach a problem. The Technical Debt Quadrant tells you what to do about a system you've already built. Team Topologies answers a question neither of those touch: who should own this, and how should they be allowed to talk to everyone else. Draw that boundary badly and no amount of good architecture inside each team fixes the coordination tax between them — Conway's Law collects that tax whether or not you ever chose to pay it.