Three Ways Teams Work Together Without Creating Bottlenecks

You have a platform team that built a great CI/CD pipeline. A stream-aligned team needs to use it. But instead of just running their deployments, they keep asking the platform team questions. The platform team gets pulled into every release. Soon, nobody is doing their actual work.

This is the moment when knowing team types is not enough. You also need to know how teams interact. Team Topologies describes three interaction patterns that help teams collaborate without creating new dependencies or slowing each other down. Each pattern fits a different situation, and knowing which one to use -- and when to switch -- makes the difference between smooth delivery and constant coordination overhead.

Collaboration: Working Together on Unclear Problems

Collaboration happens when two teams work closely together for a defined period. They share communication channels, sync frequently, and often sit in the same space. This pattern is useful when the problem is not yet well understood and requires expertise from both teams.

Imagine a stream-aligned team wants to add a feature that requires changes in a subsystem managed by a complicated-subsystem team. Neither team can solve this alone. The stream-aligned team knows the feature requirements. The complicated-subsystem team knows the internal architecture. They need to work together to find the right design, write connected code, and verify nothing breaks.

Collaboration is powerful, but it has a cost. It consumes attention from both teams. It creates temporary dependencies. That is why collaboration should not last forever. Once the problem is solved and the pattern becomes clear, the interaction should shift to a lighter pattern. Prolonged collaboration makes teams dependent on each other and distracts them from their own value streams.

The key question to ask: Do we still need deep joint work, or can we now document what we learned and move on?

X-as-a-Service: Providing Capabilities Without Handholding

In the X-as-a-Service pattern, one team provides a capability that other teams can consume without knowing the implementation details. The providing team owns the interface, availability, and quality. The consuming team just uses it -- like calling an API or running a pre-built pipeline.

This is the natural interaction between a platform team and stream-aligned teams. The platform team provides environments, CI/CD pipelines, or monitoring tools as services. Stream-aligned teams do not need to understand how the pipeline is built or maintained. They just use it.

The success of this pattern depends on one thing: a stable and clear interface. If the service changes frequently, or if documentation is incomplete, consuming teams get frustrated. They start building their own solutions. That defeats the purpose of having a platform team.

X-as-a-Service reduces communication overhead and lets each team move at its own pace. But it only works when the providing team treats the interface as a product, not as an afterthought.

Facilitation: Teaching Teams to Be Self-Sufficient

Facilitation is the pattern where one team helps another improve a specific capability without taking over the work. This is the core pattern for enabling teams.

An enabling team does not come to do the work for a stream-aligned team. They come to teach, coach, and provide examples or guides. For example, an enabling team that specializes in application security can help a stream-aligned team understand how to write secure code, manage secrets, or integrate security scanning into their pipeline. Once the stream-aligned team can do it on their own, the enabling team steps back and moves to another team that needs help.

Facilitation is different from collaboration because the enabling team does not build the product. It is different from X-as-a-Service because the enabling team does not provide a permanent service. The goal of facilitation is to make other teams independent.

The trap here is never-ending facilitation. If an enabling team stays with one team too long, they become permanent babysitters. The team never learns to operate without them.

All Three Patterns Can Run in Parallel

These three patterns are not exclusive. In a healthy organization, all of them run at the same time. A stream-aligned team might use the platform team's services through X-as-a-Service, collaborate with a complicated-subsystem team on a tricky feature, and receive facilitation from an enabling team on testing practices.

The important thing is to be aware of which pattern is active and when to switch. Collaboration that continues without clear reason creates new dependencies. X-as-a-Service with an unstable interface destroys trust. Facilitation that never ends prevents teams from becoming self-sufficient.

Practical Checklist for Choosing Interaction Patterns

Before you set up a new interaction between teams, run through this quick check:

The following flowchart summarizes the key decision points from the checklist:

flowchart TD A[New team interaction needed] --> B{Problem well understood?} B -- No --> C[Collaboration] C --> D[Set end date] B -- Yes --> E{Can capability be provided without handholding?} E -- Yes --> F[X-as-a-Service] F --> G[Treat interface as product] E -- No --> H[Facilitation] H --> I[Plan enabling team exit]
  • Is the problem unclear and requires joint discovery? Use collaboration, but set an end date.
  • Does one team have a stable capability others need? Use X-as-a-Service, and treat the interface as a product.
  • Does a team need to learn a new skill? Use facilitation, and plan for the enabling team to exit.
  • Is collaboration lasting longer than expected? Ask if the pattern has become habit instead of necessity.
  • Is the X-as-a-Service interface causing frustration? Fix the interface or documentation before adding more features.
  • Is the enabling team still needed after several months? The team may not be learning. Switch to a different approach.

The Takeaway

Interaction patterns are not just theory. They are practical tools to decide how much coordination is healthy and how much is wasteful. Collaboration solves hard problems but should be temporary. X-as-a-Service speeds up delivery but requires stable interfaces. Facilitation builds capability but must have an exit plan.

The teams that deliver well are not the ones that collaborate on everything. They are the ones that know when to work together, when to provide a service, and when to teach and step back.