Leyendo “Team Topologies” (un libro altamente recomendable, por cierto) he llegado al artículo donde Mel Conway explica su llamada “Ley de Conway” y me ha parecido que podría ser una buena lectura de verano para pensar sobre cómo se diseñan las organizaciones, especialmente desde un punto de vista agilista.
«La tesis fundamental de este artículo es que las organizaciones que diseñan sistemas (en el sentido amplio utilizado aquí) están obligadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones.»
Melvin E. Conway en “How do Committees Invent?” (Datamation, Abril 1968)
En este artículo, Conway define “diseñar un sistema” como «ese tipo de actividad intelectual que crea un todo útil desde la diversidad de sus partes». Leyendo esta definición desde una mirada más actual, nos puede parece un poco anticuada porque se describe el diseño de sistemas desde un punto de vista de “thinkers vs doers”, es decir, gente cuyo trabajo es pensar frente a gente cuyo trabajo es hacer, es decir, no pensar (ni cuestionar lo decidido por otros). Pero… en este mismo artículo, el autor concluye que:
«Se deben encontrar maneras de recompensar a los gestores del diseño (design managers) para que mantengan sus organizaciones ajustadas y flexibles».
Esto fue escrito hace 52 años (en 1968). Conway acepta y explica que cualquier diseño organizacional (deliberado o emergente) es el resultado de los esquemas de recompensa que establecemos (ya sean explícitos o implícitos).
«El propio acto de organizar un equipo de diseño significa que ciertas decisiones de diseño ya se han tomado, explícitamente o de otra manera.»
También describe el ciclo de vida del esfuerzo de diseñar un sistema. Me interesa especialmente cómo hacerlo sostenible, por lo que me detendré en la explicación de Conway sobre cómo los grandes sistemas tienden a desintegrarse. De hecho, el autor nos habla de que esto sucede en tres pasos:
- «La comprensión por parte de los diseñadores iniciales de que el sistema será grande, junto con ciertas presiones en su organización, hace irresistible la tentación de asignar demasiadas personas a un esfuerzo de diseño.»
- «La aplicación del conocimiento convencional en la gestión a una gran organización de diseño provoca que su estructura de comunicación se desintegre.»
- «El homomorfismo se asegura de que la estructura del sistema refleje la desintegración que ha ocurrido en la organización de diseño.»
La duda es si esta tendencia a la desintegración del diseño original es inevitable o no.
«El proceso parece ocurrir en 3 pasos, los dos primeros de los cuáles son controlables y el tercero es el resultado de nuestro homomorfismo.»
Pero, ¿qué demonios es eso del homomorfismo? Pues, básicamente, es el corazón de la Ley de Conway. Cito:
«Hemos demostrado que hay una relación muy cercana entre la estructura de un sistema y la estructura de la organización que lo diseñó. (…) Este tipo de relación de preservación de la estructura entre dos conjuntos de cosas se llama homomorfismo.»
Es decir, que todo lo que diseña una organización tiende a parecerse a cómo ésta está estructurada y, sobre todo, cómo se comunican entre sí sus diferentes componentes. Por ejemplo, si diseñamos aplicaciones en una empresa donde hay un equipo responsable de las bases de datos, habrá una base de datos, o algo que nos la recuerde (aunque no sea necesario). Y lo mismo sucederá con el (re)diseño de una organización. Por ejemplo, si tenemos un equipo responsable del Agile, pues lógicamente habrá algo que nos recuerde a ese equipo (aunque no sea necesario).
Y es que volvemos a los incentivos:
«La Ley de Parkinson juega un papel importante en la sobreasignación del esfuerzo de diseño. Desde el momento en el que el prestigio y el poder de la gerencia están ligados al tamaño de su presupuesto, ésta estará motivada para expandir su organización.»
¿Cuál es el principal incentivo de las personas que diseñan una organización ágil? Si no somos cuidadosos y atendemos a la advertencia de Conway, pues probablemente sea su propia supervivencia y extensión a lo largo de la organización pre-existente. No es raro, pues, que veamos que se diseñan (e implantan) jerarquías paralelas donde deberíamos estar simplificando estructuras. Y no creo que sea por mala intención, ni muchísimo menos, sino (también nos advierte Conway de ello) porque no vemos más allá de las lineas de comunicación que tenemos a nuestro alcance.
«Dada cualquier organización de un equipo de diseño, existe un conjunto de alternativas que dicha organización no puede seguir de manera efectiva porque no existen las vías de comunicación necesarias. Por lo tanto, no existe un grupo de diseño a la vez organizado e imparcial.»
En una gran organización es muy difícil avanzar por caminos que no estén previamente marcados porque es muy difícil establecer nuevos caminos de comunicación. Los buzones de correo están llenos, las agendas de reuniones también, igual sucede con las paredes (o ya están llenas de reclamos o está prohibidísimo usarlas para cualquier anuncio). Sólo nos quedan o los canales informales (un esfuerzo ímprobo que nos resta energía para nuestros propios objetivos) o crear nuevos canales, es decir, nuevas jerarquías. 🙁
Por tanto, si realmente queremos ser transformadores, tenemos que diseñar nuestra propia tarea como agentes de cambio para minimizar estas tensiones. Pondré un ejemplo personal.
En mi último trabajo (en una gran consultora), me empeñé en no tener equipo. Mi intención era conseguir que el valor de mis aportaciones fuera atrayendo a personas para que se convirtieran en agentes de cambio interno. Por un lado fue un error porque no tenía presupuesto con el que compensar el tiempo dedicado (la organización desincentiva trabajar gratis), lo cuál me dificultaba dar resultados que sirvieran de reclamo. Pero por otro lado fue un acierto porque evité crear una estructura innecesaria de agilistas a los que mantener permanentemente ocupados, por los mismos incentivos que desincentivan trabajar gratis.
Así pues, según Conway, si cedemos a las tensiones que nos provocan añadir más complejidad al diseño de nuestra organización, será inevitable que desarrollemos productos que reflejen esta complejidad innecesaria. ¿Qué debemos hacer entonces? Pues, la verdad, no tengo una respuesta, pero sospecho que los tiros van por crear incentivos alineados con el diseño de la organización que buscamos. Es decir, si buscamos una organización centrada en los clientes, pues revisar los incentivos de la organización (a todos sus niveles) para que el feedback de los clientes les llegue y puedan responder a éste con rapidez y eficacia, crear nuevos productos/servicios, etc. Y así con todo.
LA FOTO: Se trata de un diagrama que aparece en el artículo citado de Conway en el que se resume la Ley de Conway.
ACTUALIZACIÓN: Ayer estaba siguiendo con mi lectura del libro “Team Topologies” y me encontré con una cita de Ruth Malan acerca de las decisiones técnicas y, consecuentemente, de los roles técnicos, en particular los roles de gestión.
Mi tweet atrajo varias opiniones y conversaciones en las que participaron @ManuelPais (co-autor de “Team Topologies”) y @RuthMalan (experta en el trabajo de Conway), cosa que agradezco muchísimo. Inicialmente pensé en incorporarlas a este artículo, pero he pensado que seguramente divergían demasiado del tema inicial y que merece la pena dedicar un artículo exclusivamente al mismo. Así que “stay tuned”. 🙂