Building a Team of Teams (1/3)
written by Marcin Floryan and Arne Roock
Part 1: A Case for a Team of Teams
Getting together a number of different teams to collaborate effectively and smoothly on a single piece of work is a hard challenge. Very often each team has their own ways of working, ways to coordinate and communicate, a bunch of systems to own and local priorities to focus on.
In the last few decades, with the spread of agile ways of working, we have been evolving organizations in ways that increase team autonomy and allow individual teams to achieve more without too much of a need for coordination. This increase in autonomy did not only require a higher degree of trust, delegation and servant leadership but also had serious technical implications. For example, we have been building cross-functional teams - teams that bring together all required skills to deliver on their mission without being dependent on, for example, an external team of database experts. We have been standardising and abstracting up the technology stacks so that teams didn’t have to rely on a dedicated team of architects to consult on every new development. Speaking of technical architectures - implementing microservices and generally higher levels of components decoupling meant that teams were no longer constrained by working in a single monolith with a strict release cadence. We have also seen, and continue to see, a shift away from project-based organisations and towards a focus on products - with clear local team ownership of a product or part thereof.
However, as the size of our user base, codebase and product extent increases, many organizations, especially larger ones, find that they can no longer deliver the most impactful business improvements by relying solely on the excellent deliveries that can happen in a single team. This prompts many organizations to engage in some form of “up-scaling” mechanism. These may or may not rely on some of the existing “scaling frameworks” and almost always involve bringing in a dedicated coordination mechanism, most typically in the form of a project management or program management function.
In this post we will not talk about “boxed” scaling frameworks. Instead, we will reflect on our experiences with large scale development, where multiple teams formed a highly effective team of teams and delivered a large piece of functionality quickly and with little overhead.
What is a Team of Teams?
A while ago we (Marcin and Arne) were having coffee and talked about the “good old times” at Spotify. What was particularly interesting was that we had very similar experiences with large-scale development - although we had both worked in very different parts of the organization. We had both been part of large initiatives that went very smoothly. Although many different teams were involved and had to coordinate their actions, the work was flowing, folks were engaged, the energy was great and people had fun. And then we also saw these initiatives that were the complete opposite: everything was slow, the process felt bureaucratic, folks were stressed and often disengaged. Making even the smallest progress felt like swimming against a strong current. The first scenario we described as a team of teams - many small teams moving as one big one. The second scenario we called a group of teams.
What was the difference, we wondered? Which conditions might have made the difference between a team of teams and a mere group of teams? After several conversations, enormous bowls of coffee and tea and a lot of scribbling, we agreed that although there are certainly many contributing factors, we believe that there are two main ingredients that are essential for building a true team of teams: Team cohesion and technical capabilities. These will be the two topics for the upcoming two posts in our mini series, but we will leave this illustration as a little teaser.
Summary
Many organizations find themselves in a situation, where even highly effective, autonomous teams can no longer deliver meaningful pieces of work on their own. Instead, they need to communicate and coordinate with other teams. We distinguish two types of multi-team systems: loosely coupled groups of teams and close-knit teams of teams. In the upcoming two posts we will elaborate the key ingredients for forming effective teams of teams: Coherence and technical capabilities.
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: 11./12.06.2025 in Hamburg
Mehr Info
