Divide-Conquer-Integrate?
Many organizations I have worked with have established teams as their basic unit for product development. These teams are usually (at least to some extent) small, stable and cross-functional. And each of them owns a specific domain. This setup often works well for maintaining and enhancing existing products and for adding new, small-ish features that fit neatly into one of these domains. One challenge, however, arises when the organization wants to build a new piece of functionality that requires the contribution of several teams. As an organization grows, it’s not uncommon to include ten or even more teams in such an endeavor. And it’s also not uncommon that initiatives of this kind become the norm rather than the exception. Now of course one important question becomes: How do we coordinate all these teams to build the new functionality in a reasonable way?
One pattern for coordinating several teams I have seen often can be described as Divide-Conquer-Integrate.
The Divide-Conquer-Integrate Model
In this model, all the needed teams come together to discuss how to best build the new functionality. In order to do so, they must collaborate and communicate closely, but only for the first step, which is the Divide portion of this process.
After the work has been divided between the different teams, each team goes off and works on their respective part. This is what we can call the Conquer stage. During this stage, the teams will usually give updates to each other and ask questions, but otherwise they mostly work on separate tracks.
After the teams all have built their parts, they convene once again, in order to integrate their team-contributions. This, again, often requires close collaboration.
This approach can be visualized like this:
Is this a good model for multi-team setups? It depends, of course. But I think it’s worth pointing out a couple of interesting aspects of this approach:
Only in the beginning and in the end of this process do the teams work as a Team of Teams, meaning they collaborate closely across team boundaries and have high cross-team cohesion. During the Conquer step, they work as a Group of Teams, meaning that each team focuses on their respective parts (illustrated by the jigsaw pieces).
While this might not always be a problem, it can create a substantial risk: The longer the Conquer step runs, the more jigsaw pieces the teams will produce. And the bigger the chance that the pieces don’t fit together. The bomb icon symbolizes this risk, which usually only materializes quite late in the process - when the teams try to integrate all the pieces.
The longer the Conquer step lasts, the more the teams will “drift apart”. This means they will become more and more focused on their individual team-tasks and less aligned on the big picture and the shared, cross-team goal. This exacerbates the risk of pieces not fitting together, because teams are losing a shared understanding of how what they are building will actually help achieve the common goal.
Some Alternative Ideas
What can we do about these risks? Maybe the most obvious solution would be to work as a Team of Teams the whole time, meaning that we maintain high-intensity of communication and collaboration across team boundaries. This is, unfortunately, easier said than done and requires organizational investment. And it might be a good investment, if we need to come together in multi-team setups repeatedly. I will write a separate post about some of the things I believe are required, in order to make Teams of Teams work.
A second thing we can (and should) do, is to think about our batch size. It should be obvious that the risks that I have outlined above are becoming bigger and bigger the longer the teams stay in Conquer mode (the more jigsaw pieces they create). So if we can cut our one big feature into two or three small medium-sized ones, that will take us a long way.
Lastly, it’s worth noting that in this model we are “building work around the teams” (I think I have first heard that phrase from my brother Stefan). We are leaving the team structure as it is and then trying to find the best way to coordinate our teams to do the work. An alternative approach would be to “build the teams around the work”. Here we would re-evaluate our existing team structure and maybe change it according to the task at hand. And in some cases we might even find out that we only need one team to build the new functionality. But that’s also a topic for future posts…
Mit vielen Teams viel schneller 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
