How to deal with an Inverse Conway Maneuver? - A talk by Romain Vailleux at Duck Conf 2021
Companies are complex systems made up of humans and technological systems in perpetual interaction. “Theses socio-technical” systems are Romain's favorite subject.
Melvin Conway observed that the communication structures of organizations directly influence the design of technical systems produced by those organizations.
In short: the organization chart of the company and the interpersonal relationships across people have more influence than designers and architects!
The principle of an "Inverse Conway Maneuver" is simple: to transform your business at a lower cost, first look at and influence how the teams interact. The rest will follow...
Inspired by the bestseller Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton and Manuel Pais, Romain gives some advice on how to put it into practice, reorganize your teams to better respond to the strategic challenges of your company and, at the same time, to design learning organizations where the individuals emancipate.
The company: a complex socio-technical system
Romain Vailleux, consultant at OCTO since 2015, is regularly contacted by business leaders who complain about the limits of their information systems:
“My CRM is not omnichannel; our mobile application is late; my API project is going crazy….”
The company is a complex system made up of humans and technological systems bounded by continuous interactions. This “socio-technical” system is twofold:
- The "Socio" side: human, sensitive, teams and their interactions
- The "Technical" side: machines, logic and rigor of processes and capital
These two dimensions interact within a single complex system, oscillating around a point of rarely optimal equilibrium. This system actively and valiantly resists any attempt of transformation...
Can you see the problem?
How do we create balanced and durable changes in the socio-technical system embodied by our companies? Within an optimal spending of time and energy?
Conway's law
Since the 1960s, Melvin Conway has also been interested in “socio-technical” systems. The law that bears his name (Conway's Law) reads as follows: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” This law is cited extensively by OCTO consultants who spot these patterns in companies and consistently find that the structure of the company's organisation influences the design of IT architecture and rarely the other way around.
Inverse Conway maneuver
This bold move is to use Conway's Law to indirectly achieve our end goals: to transform your business at a lower cost, modify its communication structures to influence the emergence of optimal architectural designs. The real question to ask is then: what is the right organization to reach a given architectural target?
In practice: Team first!
- Limit the cognitive load (business, technical, infra) of the team to avoid overflow and maintain a learning capacity.
- Choose a team size which facilitates interactions.
It is not easy to divide 150 people into several teams. Dunbar's work and other significant numbers come in handy:
- 150 : the number of people with whom you can maintain a relationship / recall simultaneously ;
- 50 : the number of people with whom you can maintain a relationship of mutual trust ;
- 15 : the number of people with whom you can maintain a strong relationship of trust ;
- 5 ( +/- 2) : the number of simultaneous objects that you can instantly remember (to reconcile with the cognitive load). This is also the maximum number of people with whom you can maintain a close collaborative relationship.
Focus on small teams and low cognitive load
Finding the optimal balance between team size and efficiency means positioning the cursor between:
- Team synchronization versus inter-team synchronization
- Having all the skills in the team versus create dependency on other teams
- Strongly coupled software bricks versus tending toward a decoupled architecture
The authors of Team Topologies: Organizing Business and Technology Teams for Fast Flow identify four types of teams :
- Stream-aligned team: flow and responsiveness, dedicated to achieving business objectives.
- Three other types of teams whose sole objective is to remove obstacles in the way of stream-aligned teams, and to minimize the cognitive load:
- Enabling team : disseminate good practices and increase the level of know-how of the teams (consulting / coaching / mentoring / training ...)
- Complicated-subsystem team : bundle cutting-edge skills and specializations into a product made available to the rest of the organization
- Platform team : simplify the use of common bases that accelerate the implementation of products
The 4 types of team of the model Team Topologies: Organizing Business and Technology Teams for Fast Flow
Finally, 3 modes of interaction between teams are proposed in this model:
- Collaboration: Operating with strong interdependencies, two teams intensify their interactions in order to finely adapt the integration of their software products. The mode of integration is therefore designed rather ad hoc with the objective of efficiency and specialization. The collaboration mode is also suited for addressing unique situations and uncertain contexts.
- X-as-a-Service : A mode of interaction favoring decoupling and standardization. A team makes its product available via standardized interfaces. The department's production team adopts a "product" culture.
- Facilitating : A temporary relationship between two teams with the aim of transmitting skills in a sustainable way from one to the other.
The 3 modes of interaction of the model Team Topologies: Organizing Business and Technology Teams for Fast Flow
The target organization is then designed and assembled like Legos® by successively adding the teams and the appropriate modes of interaction.
In practice: assembly of a real case
New target organization
The organization is designed and assembled step-by-step, taking into account the challenges and constraints of the company:
| #### Issues & constraints | #### Team | #### Mode of interaction |
| Resolve strong dependencies: “The PIM and CMS need to be synchronized very frequently and work in tandem.” | Complicated Subsystem team “Products” | Collaboration |
| Take into account the corporate strategy: "Our core business is to provide a customer experience that reflects the quality and innovation of our products." | Stream aligned teams “Front Web” et “Front Mobile” | Collaboration with Products |
| Support transformation projects: "Omnichannel means making CRM information and OMS services available to all channels." | Complicated Subsystem team “CRM” et “OMS” | X-as-a-service with “Products” |
| Combine rare skills with a skills transmission mission: “We opted for the Xforce solution on several bricks. But experts in the market are few and far between. ” | Enabling team “XForce” | Facilitation |
| Take into account the state of maturity of the application market: “The means of payment are multiplying. Developments in the payment block must benefit all sales channels. It must be able to be decommissioned / replaced easily if we change partners.” | Complicated Subsystem team “Service Paiement” | X-as-a-service with “Products” |
| Sharing best practices: “In addition, we noticed that certain best practices in the implementation of the payment service allowed us to earn 34 conversion points.” | Complicated Subsystem team “Service Paiement” | Collaboration with Products “Front Web” and “Front Mobile” |
Your model will evolve through time
The model is not set in stone; it will be initialized and then adjusted according to many evolving parameters:
- The mode of application integration
- The business strategy
- The maturity of application markets
- The maturity of the teams
- The existing architecture
- The law / risk (eg. Separation of responsibilities)
Some takeways
Bonus : The Sociotechnical Architect toolbox
