Most teams start out with the best intentions. Ship faster, keep things simple, stay close to the customer. But as companies grow, friction creeps in. Delivery slows, hand-offs multiply, and nobody’s quite sure why a feature that looked straightforward ended up stuck in a queue.
It’s rarely about motivation or skill. The cause is structural, in the web of boundaries and dependencies that quietly shapes how work gets done. The org chart looks logical. The day-to-day reality is more tangled. To make progress you have to see how those connections help or hinder teams delivering end-to-end.
Team Topologies gives you a lens for that. Instead of adding process, it helps you spot the patterns behind delivery drag and redesign teams for flow.
Intro to Team Topologies
Team Topologies is a framework for structuring teams around flow, fast delivery and a sustainable pace. At the heart of it are four team types:
- Stream-aligned (directly delivering customer value)
- Enabling (helping others build capability)
- Complicated Subsystem (deep specialists)
- Platform (internal product teams)
There are three modes of interaction between them: collaboration, X-as-a-Service, and facilitation.
How you structure teams and define their interactions affects delivery more than almost any single process or tool. Bottlenecks aren’t accidents. They show you how work moves across boundaries, or fails to. Healthy teams have clear ownership, few dependencies, and can deliver end-to-end without waiting in someone else’s queue.
Team Topologies in action
Take Acme Org, a fictional SaaS business helping retailers run their e-commerce back office. Acme’s product relies on connecting with dozens of third-party APIs, payments, shipping, analytics, and marketing tools.
To keep things “organised”, they created an Integrations team: a specialist group tasked with building and maintaining all these connections.
It sounds like a sensible idea. Here’s what actually happens. Three separate product teams, Payments, Orders and Fulfilment, are all trying to deliver features that depend on the Integrations team.
None of them can ship anything until Integrations builds or reviews their work. As the requests stack up, Integrations becomes a choke point. Roadmaps slip, teams start competing for attention, and everyone’s sprint goals end up at the mercy of one team’s queue.
That’s a structural problem rather than a people problem. Draw a map of how the work flows and you’d see tickets piling up in front of Integrations while everyone else waits. The teams are busy and nothing moves.
What Team Topologies would do
The answer isn’t more meetings or more alignment. It’s changing the shape of the system.
Push the integration work closer to the product teams. Give Payments, Orders and Fulfilment the skills, tools and permissions to own their own integrations, which removes the dependency altogether.
Refocus the Integrations team as an enabling or platform team. Their job shifts from gatekeeping delivery to building the internal tools, templates and automation that let product teams move on their own.
Make the boundaries explicit. Strong API contracts, automation and clear ownership remove the need for a weekly stand-up just to stay in sync.
You end up with teams that can deliver independently, getting support from specialists instead of being blocked by them. Better coordination doesn’t fix a bottleneck. Changing the architecture so you need less coordination does.
Example two: the enabling team that became a catch-all
Come back to Acme Org a year later. After the Integrations bottleneck, leadership decided they’d learned their lesson. To support product delivery they spun up an Enabling Team with a broad remit covering developer experience, DevOps support, onboarding, and helping out wherever teams got stuck.
At first it sounded promising. A few quarters in, the Enabling Team is swamped. They’re running onboarding one week, patching CI/CD scripts the next, and fielding a dozen Slack requests a day asking them to unblock a deployment or debug a pipeline. The boundaries are blurry, so every time a product team hits a wall the default is to ask Enabling.
Nobody knows whether Enabling is supposed to deliver features, run training or fix other teams’ problems. They can’t plan and they can’t say no, and the product teams are still stuck waiting.
What went wrong?
This is the glue team antipattern. Once your enabling team becomes the safety net, you’ve traded focused support for a lack of clarity. Every new dependency adds friction you can’t see. Work piles up, nobody owns the full outcome, and delivery quietly stalls.
How Team Topologies would solve it
Team Topologies would call for stronger boundaries and more explicit interaction modes.
Narrow the team’s scope. Make the mission specific and time-bound, so “help product teams migrate to the new CI/CD pipeline this quarter” rather than “help with everything DevOps”.
Use facilitation mode for knowledge transfer rather than delivery. The enabling team upskills the stream-aligned teams, runs the workshops and co-works on the gnarly migrations, then steps away. Ownership goes back to the product teams as soon as possible.
Say no to operational catch-all work. If a product team needs ongoing support, that’s a signal to invest in documentation, self-serve tooling or a dedicated platform, rather than handing the same task to the enabling team every month.
Get this right and the enabling team raises the bar across the org without becoming the default fixers. Product teams get stronger, the enabling team avoids burnout, and the system flows.
Example three: the platform team that became a product team
Check back in with Acme Org after a few years of rapid growth. Things start to creak. Every product team manages its own deployment scripts, each wires up authentication slightly differently, and monitoring is a grab-bag of open-source dashboards and half-finished alerts. Developers spend more time debugging infrastructure than building features.
Leadership decides it’s time to get serious about scale and reliability, so they form a Platform Team to build and own the paved path for the rest of engineering. Central CI/CD pipelines, a standard way to log and trace requests, a shared authentication service, and reusable tooling for standing up new microservices. Product teams are meant to rely on those internal services and stay focused on customer problems.
A while later, the Platform Team is thriving, sort of. They’re shipping tools, running demos and fielding requests from across the business. But a familiar pattern sets in, and product teams start complaining that the platform isn’t keeping up with what they need.
Requests for new features or fixes end up at the bottom of a long backlog or get deprioritised in favour of platform-led projects. Workarounds multiply. Some teams quietly fork the platform scripts or run their own pipelines, just to move faster. The “single platform” becomes a patchwork of versions, and both sides feel frustrated.
What went wrong?
This is the platform-as-product trap. The platform team starts prioritising its own roadmap over the changing needs of its internal customers. The platform stops multiplying everyone’s output and becomes another dependency, with all the bottlenecks and hand-offs that brings. Product teams wait, while the platform team tries to please everyone and often pleases nobody.
How Team Topologies would solve it
Team Topologies takes a different approach, built around flow and healthy boundaries.
Run the platform as a real product, with the product teams as your primary customer. That means a genuine feedback loop of regular check-ins, usage metrics and enough collaboration to know what actually helps them move faster.
Use X-as-a-Service mode as the default. The platform team exposes clear, well-documented APIs and self-serve tools. Product teams consume them as a service, and the platform team owns reliability, onboarding and support without ever blocking delivery.
Set boundaries on customisation. If a product team needs something unique, help them extend the service safely or give them an escape hatch, rather than putting everyone on one backlog.
Invest in developer experience and documentation. Platforms win adoption by being easy to use, not by gatekeeping, and that means onboarding guides and usage examples alongside the features.
Done right, the platform unlocks speed and consistency across the org without becoming a bottleneck. Product teams get to focus on shipping for their customers, knowing the platform is a partner rather than a gate.
Structure shapes flow
Most team design mistakes aren’t obvious at the start. You notice the symptoms first, so blocked delivery, endless coordination and mounting frustration, long before anyone asks whether the structure itself is the problem. That’s what Team Topologies is really about: changing the environment so good work happens without heroics.
If you keep finding the same bottlenecks, blurred responsibilities and catch-all teams propping up the system, you have an architecture problem rather than a people problem. Progress means sharper boundaries, clearer interactions, and giving teams the autonomy and the support to deliver.
The playbook isn’t complicated, but it takes discipline. Map your current team types, make the dependencies explicit, and shrink the need for coordination wherever you can. The healthiest orgs have fewer meetings, because the structure lets teams move without them.
Flow is a product of design. Get the architecture right and teams move faster, and they tend to be happier too.
Published on . Co-authored with AI.