Building a Team of Teams (3/3)
written by Marcin Floryan and Arne Roock
Part 3: Technical capabilities
You might want to read part 1 (A Case for a Team of Teams) and part 2 (Team Cohesion) first.
A successful team of teams starts with a strong foundation of technical practices in each of the individual teams. They need to have clear ownership of their components, modular architecture, sufficient cross-functional skills to develop them and an end-to-end responsibility for the full software lifecycle. Practices such as automated testing, continuous deployment, observability, monitoring and alerting are non-negotiable.
Not only do these practices enable fast local delivery, they also ensure that every component remains observable and operable by others. In a team-of-teams setting, issues will often span components and teams – without shared, accessible telemetry, diagnosing and resolving them together becomes unnecessarily difficult.
It may be tempting to assume that when a number of teams start working in a team-of-teams engagement they can relax the need for clear boundaries between technical components and that increased coupling will not hurt progress. In reality, the opposite is true – relaxing boundaries almost always harms progress. Teams need crystal clear and singular ownership of each piece of software, and components must remain decoupled and capable of evolving independently.
When engineers from across teams swarm together to build a new piece of software, it must be unambiguous which team, existing or new, will take long-term ownership of that component once the work is complete. Equally important during such swarming efforts is clarity around design decisions. Cross-team collaboration must include deliberate time for joint design sessions, so that teams collectively agree on how new components fit into the existing ecosystem. Capturing decisions explicitly, for example using lightweight Architecture Decision Records¹ (ADRs), ensures alignment even after engineers disperse.
With clear ownership, it is still helpful to practice what Martin Fowler calls weak code ownership² and is sometimes also called innersourcing. The idea is that all code repositories are open for contributions from outside the owning team, but the owning team has the final say on what and how code is integrated. Even though teams work towards a shared goal, no team in the team-of-teams setup should block the flow of work for others.
This approach only works if code and documentation are easily discoverable. Contributions should not depend on personal connections or gatekeeping. Instead, repositories, API documentation and onboarding guides must be clearly documented and accessible for self-service across the team-of-teams environment.
Having clear software boundaries defined by explicitly documented interfaces such as APIs and contracts is essential. Code written by every team should be both always releasable and continuously released to production, even if it doesn’t yet provide full functionality.
While each team owns its releases, shared integration cadences or regular checkpoints help maintain alignment. This does not mean synchronising every deployment, but establishing common rhythms ensures integration happens often and issues surface early.
This is only possible when all teams share a robust continuous integration and continuous delivery infrastructure and, when needed, use semantic versioning and feature flags so that functionality can be incrementally deployed and activated as required.
At Spotify, we have deliberately invested in a robust software development platform and an outstanding developer experience to make all of the above both possible and natural. This includes providing self-service tooling, reducing friction in daily workflows, and ensuring that every team can operate autonomously yet integrate easily. Our teams have also collaborated with an acute understanding of Conway’s law, used Domain Driven Design to create component boundaries aligned with business needs, and drawn inspiration from Team Topologies to optimise team boundaries and minimise hand-offs. Together, these foundations enable seamless technical collaboration across teams working towards shared goals.
Summary
Building a successful team of teams requires technical excellence, not just collaboration rituals. Clear ownership, modular design, and shared infrastructure enable autonomy without sacrificing integration. Innersourcing, discoverable documentation, and strong developer platforms make it easy to contribute without blocking flow. With the right foundations, teams can move fast together: continuously, confidently, and at scale.
__________
¹ https://en.wikipedia.org/wiki/Architectural_decision
² https://martinfowler.com/bliki/CodeOwnership.html
The Authors
Marcin Floryan
Marcin is an expert in engineering leadership and organisational development with over two decades of experience as a software engineer, coach, and technical leader. Throughout his career he has worked with startups, scale-ups, and large technology companies across various industries. For the past decade he took a deep dive into platform engineering and organisational transformation at Spotify in Stockholm, leading teams of 120+ people and delivering systems serving hundreds of millions of users. Since 2025 Marcin has been working as VP of Software at Marshall Group, applying his expertise in a new context of a hardware-focused organisation.
Marcin on LinkedIn
Marcin’s Website
Arne Roock
Arne is an expert in Agile methods and (leadership) team effectiveness with two decades of experience as a professional trainer, coach, and facilitator. In his time as a consultant he worked with both startups and big corporations in different industries. For the past ten years he took a deep dive into the tech industry as an embedded coach with Jimdo in Hamburg and Spotify in Stockholm. In 2024 Arne started his own consulting business in which he helps organizations create effective teams and leadership structures.
Arne on LinkedIn
Arne’s Website
Mit vielen Teams schnell liefern
Im Juni halte ich zusammen mit meinem Bruder Stefan eine Schulung zum Thema Team-of-Teams. Ort und Termin: 08./19.12.2025 in Hamburg
Mehr Info
