Progettare la composizione del team: La legge di Conway
La legge di Conway
E’ importante prendersi del tempo per progettare la composizione di un team? Certamente si!
Di solito il team lo troviamo già fatto, oppure è definito e impacchettato dal nostro capo in base a logiche di saturazione delle risorse: poter scegliere anche solo uno o due componenti ci pare un lusso inatteso.
Eppure, progettare la composizione del team è importante.
Nel #teamgiusto, con Paolo Chinetti, dedichiamo un intero capitolo ad approfondire il tema della progettazione di un team.
Esiste una ‘legge’, anzi una euristica, molto interessante che si è sviluppata nel mondo dell’implementazione del software. Se ci fate caso, le organizzazioni tendono a riprodurre in forme sempre più ampie una stessa struttura caratterizzante. Questa tendenza è tipica degli organismi viventi, degli ecosistemi e, in generale, di tutti i sistemi resilienti. L’azienda imprenditoriale ‘espande’ e riproduce il modulo della gestione personale del fondatore, la multinazionale ripete in ogni paese il pattern del management team di successo del paese di origine, un organismo di ricerca moltiplica nelle proprie strutture i moduli della propria organizzazione della conoscenza.
E si tratta di formati organizzativi che introducono delle regole ben precise di comunicazione e di trasferimento delle informazioni. Ogni volta che cerchiamo di modificare una organizzazione, interveniamo sui meccanismi di trasferimento delle informazioni che si sono consolidati nel tempo. E possiamo indurre infragilimenti, diseconomie o collassi.
Nel 1967 Mel Conway, un informatico attento al pensiero sistemico, coniò una ‘legge’ (euristica, da vero ingegnere) che porta il suo nome. La legge di Conway ci dice: organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
In un certo senso, questa ‘legge’ riprende l’immagine di una organizzazione che cresce come un frattale riproducendo omoteticamente una sua parte in rapporti di scala più grandi. Conway aggiunge che anche gli output di questa organizzazione saranno influenzati dal modo in cui essa definisce la struttura dei suoi sistemi di trasferimento delle informazioni; in altre parole: il sistema di trasferimento dell’informazione di una organizzazione definisce profondamente la struttura risultante dei suoi progetti. Se ci riportiamo al punto di vista della squadra: un team è plasmato dalle modalità di trasferimento dell’informazione del sistema organizzativo cui appartiene e altrettanto lo sono i risultati che produce.
Senza progettare un team, e senza tener conto di come è strutturata l’organizzazione che lo incorpora, il prodotto che otterremo (sia esso un servizio o un vero e proprio prodotto) sarà predeterminato nella sua struttura.
Attenzione perché questa legge empirica ci dice anche un’altra cosa: è inutile progettare il team come un elemento a sé senza tener conto dell’organizzazione ospitante. La maggior parte delle ri-organizzazioni fallisce per questo.
Una euristica come la legge di Conway è uno strumento molto utile nella cassetta degli attrezzi di un team leader o di un membro attivo del team. Se ci pensate, è, ancora una volta, la conferma della natura (eco)sistemica del team giusto e di quanto esso sia influenzato dai molteplici e più ampi sistemi nei quali è calato.
Quale relazione intravedete fra la struttura del vostro team e quella della vostra organizzazione? Quali elementi in comune hanno? Cosa funziona o non funziona di simile in entrambi i casi?
Come descrivereste il sistema di raccolta e trasferimento delle informazioni della vostra organizzazione? E quello del vostro team? Quali condizionamenti esercitano questi sistemi sulla struttura dell’output del vostro team?
Buona progettazione del Vostro team!
Conway’s law
Is it important to take time to plan the composition of a team? Yes of course!
Usually we find the team already done, or defined and packed by our boss on the basis of saturation of resources logics: being able to choose even just one or two components seems to us an unexpected luxury.
Still, designing the team is important.
In #teamgiusto, with Paolo Chinetti, we dedicate an entire chapter to deepen the theme of designing a team.
There is a very interesting ‘law’, indeed a heuristic, that has been developed in the world of software implementation. If you notice it, organizations tend to reproduce the same characterizing patterns at larger scale. This trend is typical for living organisms, ecosystems and in general for all resilient systems. The entrepreneurial company ‘expands’ and reproduces the founder’s personal management module, the multinational firm repeats in each country the pattern of the successful management team of the country of origin, a research organization multiplies in its own structures the modules of its knowledge organization .
And these are organizational formats that introduce very specific rules of communication and information transfer. Whenever we try to change an organization, we touch and modify information transfer mechanisms that have been consolidating over time. And we might induce fragility, diseconomy or collapse.
In 1967 Mel Conway, a computer scientist aware of systems thinking, created a ‘law’ (heuristic, like a true engineer) that keeps his name. Conway’s law tells us: Organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.
In a certain sense, this ‘law’ explains the behavior of an organization that grows like a fractal by homothetically reproducing a part of itself in larger scale ratios. Conway adds that the outputs of this organization will also be affected by the way it defines the structure of its information transfer systems; in other words: the information transfer system of an organization deeply influences the resulting structure of its projects. If we return to the team’s point of view: a team is shaped by the information transfer methods and schemes of the organizational system to which it belongs, and so are the results it produces.
Without designing a team, and without taking into account how the organization that incorporates it is shaped, the product we will obtain (be it a service or a real product) will be predetermined in its structure.
Consider that this empirical law also tells us another thing: it is useless to design the team as an element in itself without taking into account the host organization. Most reorganizations and good teams fail because of this.
A heuristic such as Conway’s Law is a very useful tool in the toolbox of a team leader or an active team member. If you think about it, it is, once again, the confirmation of the (eco) systemic nature of the team giusto and of how much it is influenced by the multiple and wider systems in which it is embedded.
What relationship do you see between your team structure and the one of your organization? What elements do they have in common? What is working or doesn’t work in both cases?
How would you describe your organization’s structure and information transfer system? What about your team? What influences do these systems exert on the structure of your team’s output?
Enjoy the composition of your team!
