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 the queue.
It’s rarely about motivation or skill. The real culprit is structural: the invisible web of boundaries, dependencies, and team interactions that quietly shapes how work gets done. The org chart might look logical, but the day-to-day reality is usually more tangled. To make real progress, you have to see how these connections help or hinder teams from delivering end-to-end value.
That’s where Team Topologies comes in. Instead of adding more process, it offers a lens to spot the patterns behind delivery drag and practical ways to design teams for flow rather than friction.
Intro to Team Topologies
Team Topologies is a framework for structuring teams to optimise for flow, fast delivery, and 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)
Three modes of interaction: collaboration, X-as-a-Service, and facilitation.
The way you structure teams and define how they interact has more impact on delivery than almost any single process or tool. Bottlenecks aren’t accidents. They’re examples of how work moves (or doesn’t) across boundaries. Healthy teams have clear ownership, minimal dependencies, and can deliver end-to-end value without getting stuck in queues.
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 a sensible idea, but here’s what actually happens. Three separate product teams, Payments, Orders, and Fulfillment, are all trying to deliver features that depend on the Integrations team.
None of them can ship customer value until Integrations builds or reviews their work. As more needs stack up, Integrations become a choke point. Roadmaps slip, teams start pushing for attention, and suddenly everyone’s sprint goals are at the mercy of one team’s queue.
This isn’t just a people problem, it’s a structural problem. If you drew a map of how work flows, you’d see tickets piling up in front of Integrations while everyone else waits. Teams are busy, but nothing moves.
What Team Topologies Would Do
Team Topologies: don’t add more meetings or try to “align” more. Change the shape of the system.
-
Push the integration work closer to the product teams. Give Payments, Orders, and Fulfillment the skills, tools, and permissions to build and own their own integrations, reducing dependencies and hand-offs.
-
Refocus the Integrations team as an enabling or platform team. Their job shifts from being a delivery gatekeeper to building internal tools, templates, and automation so the product teams can move faster on their own.
-
Make boundaries explicit. Strong API contracts, automation, and clear ownership remove the need for weekly stand-ups just to keep everyone “in sync”.
Instead of a bottleneck, you get a network of empowered teams who can deliver value independently, with support, not blockage from specialists. Bottlenecks aren’t fixed with better coordination. They’re fixed by changing the architecture, so you need less of it in the first place.
Example Two: The Enabling Team That Became a Catch-All
Let’s zoom back in on Acme Org a year later. After their bottle-necked Integrations team experiment, leadership decided they’d learned their lesson. To “support” product delivery, they spun up a new “Enabling Team” with a broad remit: developer experience, DevOps support, onboarding, and “helping out” wherever teams got stuck.
At first, it sounded promising. But a few quarters in, reality hits: the Enabling Team is swamped. They’re running on-boarding one week, patching CI/CD scripts the next, and fielding a dozen Slack requests a day (“Can you unblock our deployment?” “Can you help debug our pipeline?”). The boundaries are blurry, and every time a product team hits a wall, the default is: “Let’s ask Enabling”.
Now, nobody knows whether Enabling is supposed to deliver features, run training, or just fix other teams’ problems. They can’t plan, can’t say no, and ironically, the product teams are still stuck waiting.
What Went Wrong?
This is a classic case of the glue team antipattern. When your “enabling” team becomes the safety net, you’ve traded focused support for a lack of clarity and flow. Every new dependency adds invisible friction: 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 modes of interaction:
-
Narrow the Enabling Team’s scope. Make their mission specific and time-bound: e.g. “Help product teams migrate to the new CI/CD pipeline this quarter”, not “help with everything DevOps”.
-
Use facilitation mode for knowledge transfer, not delivery. The enabling team’s job is to upskill stream-aligned teams, run workshops, and co-work on gnarly migrations then step away. Ownership returns 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 sign the problem should be solved by investing in documentation, self-serve tooling, or a dedicated platform not by repeatedly handing tasks to the enabling team.
When you get this right, the enabling team creates real leverage: raising the bar for everyone, without getting stuck as the default “fixers”. Product teams actually get stronger, the enabling team avoids burnout, and the system flows instead of clogs.
Example Three: The Platform Team That Became a Product Team
Let’s check back in with Acme Org. After a few years of rapid growth, things start to creak: every product team manages their own deployment scripts, each has a slightly different way of wiring up authentication, 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. They form a Platform Team. The goal: 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 now supposed to rely on these internal services, so they can stay focused on customer problems.
Fast-forward, and the Platform Team is thriving…sort of. They’re shipping tools, running regular demos, and fielding requests from across the business. But a familiar pattern sets in: product teams complain that the platform isn’t keeping up with their needs.
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 rather than meeting the evolving needs of internal customers. Instead of being a force-multiplier, the platform becomes just another dependency, with all the bottlenecks and hand-offs that entails. Product teams are stuck waiting, while the platform team tries to please everyone (and often pleases no one).
How Team Topologies Would Solve It
Team Topologies offers a different approach, one that’s all about flow and healthy boundaries:
-
Run the platform as a true “product”, but with product teams as the primary customer. This means building a real feedback loop: regular check-ins, usage metrics, and active collaboration with teams to understand 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 these as a service, with the platform team responsible for reliability, onboarding, and support but not for blocking delivery.
-
Set boundaries on customisation. If a product team needs something unique, the platform team helps them safely extend or “escape hatch” the service without everyone waiting on a single backlog.
-
Invest in developer experience and documentation. Great platforms win adoption by being easy to use, not by gatekeeping. That means investing in onboarding guides, usage examples, and active enablement not just feature delivery.
Done right, the platform team creates leverage: they unlock speed and consistency for the whole org, without becoming a bottleneck themselves. And product teams can focus on what matters shipping for their customers knowing the platform is a partner, not a gatekeeper.
Structure Shapes Flow
Most team design mistakes aren’t obvious in the beginning. You notice the symptoms: blocked delivery, endless coordination, mounting frustration. Long before anyone stops to ask if the structure itself is the problem. That’s what Team Topologies is really about: not more process, but changing the environment so that good work can happen without heroics.
If you keep finding the same bottlenecks, blurred responsibilities, or “catch-all” teams propping up the system, it’s probably not a people problem, it’s an architecture problem. Real progress means making boundaries sharper, interactions clearer, giving teams the autonomy (and support) to actually deliver.
The playbook isn’t complicated, but it takes discipline. Map your current team types, make dependencies explicit, shrink the need for coordination wherever you can. The healthiest orgs don’t have more meetings. They have fewer because the structure lets teams move with purpose.
Team Topologies is a reminder that flow is a product of design. Get the architecture right, and teams don’t just move faster. They get happier, too.
Published on .