Making Cross-Team Collaboration Work
I can’t count the number of times I’ve seen cross-team collaborations go wrong. One memorable time, a central platform team owned so much of the core product functionality that they brought dependent teams to a virtual halt for more than half a year as they waited in line for changes. Another time, a collaboration between three teams became so misaligned that the core functionality had to be redesigned and rebuilt three times.
These challenges aren’t inevitable. By following a few principles, you can design team interactions that encourage fast, reliable delivery. The book Team Topologies offers one such framework. Its focus on team types and interaction modes is insightful and practical, and I’ve drawn on it repeatedly over the years. I also agree with the authors’ observation that good team organization is tied closely with good system architecture, via Conway’s Law.
That said, not every part of the framework fits every organization or stage of growth. Labels like “stream-aligned teams” and “complicated subsystem teams” can feel abstract or premature in early projects. What matters most, I believe, are how teams interact and the principles guiding those interactions.
To that end, I’ve distilled Team Topologies’ concepts and my own experience into five rules that simplify and accelerate cross-team collaboration. Here’s what I’ve learned.
1. Integrate Teams Through Services, Not Directly
All systematic, long-term interactions between development teams should happen through well-defined services, APIs, or automated contracts. Relying on ad hoc communication, shared databases, or one-off handovers creates bottlenecks and slows teams down over time.
This principle aligns with Team Topologies’ “X-as-a-Service” interaction pattern. Building services requires foresight and discipline, but the payoff is worth it: teams can work independently while remaining aligned. This independence is critical for enabling ownership, which leads to the next principle.
2. Teams Own the Experience for Specific Users
Each team should take full responsibility for delivering value to a clearly defined group of users or customers, internal or external. When that scope becomes too large, group teams by shared users and divide responsibilities further, ideally by specific user needs.
This principle builds on Team Topologies’ concept of “stream-aligned teams” but applies broadly. Even platform teams benefit from defining their internal users and focusing on their needs. When teams are fully responsible for their users, they can prioritize effectively and deliver value quickly. But to achieve this autonomy, we need to reduce reliance on internal dependencies, which brings us to the next rule.
3. Customer-Facing Teams Maximize Their Independence
External-facing teams should own as much of their work as possible, starting from direct customer interfaces and working inward. However, this ownership must be tempered with other organizational needs, such as using platform-provided tools and services for key efficiencies and consistencies.
This autonomy reduces delays and accelerates delivery. For example, a customer-facing team building a new feature should be able to make necessary changes to their API, web interface, or data pipeline without waiting on another team. Platform teams enable this independence by providing foundational tools and guardrails—like design systems or infrastructure pipelines—that empower external-facing teams to deliver quality and consistency, faster.
4. Platform Teams Enable Cross-Team Independence
Platform teams provide shared services and infrastructure that allow other teams to work independently. Customer-facing teams should only interact with each other through platform-provided services.
This approach reduces cognitive load and friction. If Team A needs to integrate with Team B, they should request an API or tool from a platform team rather than building a direct integration. Platform teams are better positioned to design reusable solutions, handle the heaviest scaling challenges, and enforce cross-cutting standards. They become the enablers of cross-team collaboration and long-term scalability.
5. Collaborate Intensely, Briefly
Cross-team collaboration should happen within defined timeframes, ideally measured in weeks, and should be a focus for all involved. When building or consuming an API, both teams should work together in real time until the full integration is complete. Walking away halfway creates delays and misalignment.
For example, if one team needs an API from another, both teams should commit to the project simultaneously. Together, they can build the API and verify its fit within the feature. If necessary, the requesting team might even contribute API code for review, unblocking progress while keeping ownership clear. For larger projects, appointing a leader to break work into smaller, manageable pieces ensures collaboration remains focused and efficient.
Closing Thoughts
In the early stages of a project or startup, prioritizing product-market fit often takes precedence over optimizing team structures and architectures. But as the business grows, cross-team collaboration becomes a limiting factor. Left unchecked, it can create bottlenecks that are painful—and expensive—to fix.
Start small: introduce services, clarify team responsibilities, and define collaboration timeframes. Over time, incremental changes can eliminate bottlenecks and enable faster delivery, fewer dependencies, and more empowered teams.
Where do you see friction in your team interactions? Are there opportunities to streamline collaboration? I’d love to hear your thoughts.
