En abril de 1968, Melvin Conway publicó un artículo en la revista de informática Datamation, el título de dicho artículo era “¿Cómo inventan los comités?” (“How Do Committees Invent?” en el original). En este artículo el autor exploraba como las estructuras comunicativas y la forma de una organización afectan al resultado final del proceso de diseño y desarrollo de sistemas complejos.

Pocos recordarían este artículo hoy si no fuese porque contenía un teorema llamado a la fama. En el mismo Conway destaca como la estructura de la organización y de las interacciones entre las partes de la misma y sus miembros moldean tanto el diseño como la funcionalidad del sistema que la organización construye. El artículo ilustraba cómo entender las dinámicas de comunicación de la organización era crucial para el éxito de cualquier proceso colaborativo.

La famosa ley de Conway que nos quedó se lee como sigue:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Cualquier organización que diseñe un sistema (definido en sentido amplio) producirá un diseño cuya estructura sea una copia de la estructura de comunicación de la organización.

Si bien esta ley tuvo bastante repercusión ya en su momento, en los últimos diez años hemos podido ver como ha ido tomando mayor repercusión dentro de muchas comunidades del desarrollo de software, especialmente en la comunidad dedicada a definir y avanzar el paradigma de Microservicios, donde tiene especial relevancia ya que ayuda a justificar este enfoque arquitectónico en torno a la estructura de la organización (ver también la “Maniobra inversa de conway”).

Cuando nuestro trabajo es crear los sistemas y procesos que dan forma a un negocio, conocer la ley de Conway nos ayuda a pensar primero en la estructura de comunicación de nuestra organización (presente o futura) para dar forma a dichos sistemas y procesos, o incluso puede llevarnos a descubrir que dichas estructuras deben cambiar para que podamos llegar a tener sistemas que tengan sentido y sean más eficientes. Puede que descubramos que el modo en que estamos estructurando la comunicación y, en definitiva, los flujos de energía en nuestra organización puede (o debe) ser mejorado antes de pasar al siguiente paso en nuestra mesa de diseño.

El propósito de este artículo no es entrar a debatir la ley de Conway en profundidad ni enseñar a trabajar con ella para crear mejores sistemas y procesos, esto ya lo ha hecho con anterioridad gente mucho más espabilada que un servidor (recomiendo especialmente leer el completo artículo que a este respecto tiene publicado Martin Fowler). 

Mi propósito aquí es anterior, el ejercicio que quiero promover es que pensemos en cómo podemos hacer que nuestras organizaciones se conviertan en lo que podríamos llamar “Comunidades comunicativas”.  Poco sentido tiene ponernos a pensar en cómo estructurar los procedimientos y el diseño de nuestros sistemas de información si previamente no hemos construido un ecosistema en el que la comunicación sea real.

No es difícil encontrar organizaciones que funcionan a pesar de no tener una comunicación fluida interna, cada departamento va a su ritmo, a sus objetivos y con su modo y manera particular de trabajar, pero no existen canales y prácticas que favorezcan la comunicación real y fluida entre las distintas personas que participan de cada una de las actividades que la organización lleva a cabo.

Es responsabilidad de los equipos de la organización, y en especial de sus líderes, generar un entorno en el que nuestra organización se convierta en una Comunidad Comunicativa, es decir, en el que la comunicación interna se convierta en una palanca para conseguir el objetivo final de la organización (sea este cual quiera que sea). 

---

En línea con esto me gustaría plantear algunos puntos de trabajo que pueden promover el cambio que nos lleve a mejorar la comunicación interna.

Call often, call early(Evitar las “reuniones por defecto”)

En estos tiempos de comunicación en diferido (chat, email), oficinas distribuidas y trabajo remoto/híbrido conseguir una comunicación fluida entre personas es complicado.

Creo que es necesario establecer una cultura de lo que yo llamo “call often / call early”.

Hay que promover que las personas de nuestros equipos pierdan la pereza por comunicarse de manera frecuente e informal cuando sea necesario y tan pronto como sea necesario.

A lo largo del día un knowledge worker toma decenas de decisiones que pueden afectar al resultado final del proyecto en el que trabaja, algunas de ellas son las que podemos llamar “decisiones cruciales”.

Si nuestra organización ha caído en la rutina de “reunirse por defecto” (default to meetings) cada una de estas decisiones cruciales básicamente detiene el tren para que se organice una reunión al respecto, u obliga al trabajador a tomar una decisión mal informada o precipitada (que suele ser lo más común, ya que la reuniones son muy costosas y más tarde o más temprano todos aprendemos a odiarlas y evitarlas en la medida de lo posible).

Siempre va a haber asuntos que requieran de una reunión organizada, pero la mayor parte de los pequeños cruces de caminos que se nos presentan en el día a día, e incluso de las decisiones “cruciales” que nos podemos encontrar se pueden solucionar en tiempo casi real si somos proactivos y tomamos una mentalidad de “llamar amenudo, llamar pronto”.

Obviamente tenemos que crear unos límites para evitar las interrupciones constantes, pero si cada miembro de nuestro equipo cambia el chip y elimina la pereza a preguntar cuanto antes podemos hacer que la productividad se multiplique y que el producto final sea lo más parecido a lo que realmente la organización necesita para tener éxito.

Entrenar en el uso de las herramientas

Las herramientas muerden, aprende a usarlas correctamente

Gran parte de nuestro trabajo se basa en saber utilizar las herramientas de las que disponemos. Cada industria y cada área tienen las suyas y es responsabilidad de cada uno descubrirlas, aprender a utilizarlas y entrenarse para sacarles el máximo partido.

Mi abuelo materno solía decir, cuando le ayudaba en alguna tarea que las herramientas, aún siendo buenas en general podían modernos si las utilizabamos mal, esto lo decía para corregirme cuando yo intentaba utilizar alguna herramienta para un uso que no era el que le correspondía, y mayormente para evitar que en mi inconsciencia me aplastase un dedo con el martillo o me llevase algún corte por hacer mal uso de alguna de sus muchas herramientas.

Por algún motivo está máxima se quedó conmigo hasta el día de hoy.

Volviendo a la comunicación en nuestras organizaciones, ¿estamos usando las herramientas correctas para cada una de las necesidades de nuestros equipos? Reflexiona sobre esto. Hoy en día disponemos de múltiples herramientas de comunicación, email, chat, tableros online, videollamadas, calendarios, etc. y muchas veces las usamos de manera incorrecta. Cada momento, cada necesidad y cada tipo de comunicación tiene una herramienta correcta. 

Por poner ejemplos, todos hemos estado en reuniones que podían haber sido un email, todos hemos sufrido conversaciones de slack en canales en los que faltaba gente (o sobraba) sobre temas que se tenían que haber tratado cara a cara, todos hemos pasado por alto un email reportando una incidencia de primera prioridad que se tendría que haber reportado por chat (o teléfono) y a todos nos han molestado con una llamada a nuestro teléfono personal para comentarnos algo que podíamos haber leído en un email pasado mañana.

Todos somos víctimas y culpables, así que seamos conscientes de que, en el camino hacia crear una verdadera comunidad comunicativa en nuestra organización tenemos que aprender a utilizar las herramientas de comunicación de la manera más efectiva y entrenar a los que nos rodean para que hagan lo mismo.

Romper las fronteras

Es muy frecuente que los equipos caigan en el aislamiento, cada uno tiene sus propios objetivos (con suerte compatibles y alineados), cada uno tiene sus propios ritmos y cada uno tiene sus propios problemas internos y externos, de modo que muchas veces se acaba tendiendo a minimizar los flujos de comunicación. Esto es un error.

El equipo X necesita una nueva feature en el producto, así que la pide, la explica en una reunión y se sienta a esperar que se la sirvan, y el equipo de producto y tecnología está conforme, “que me digan lo que tengo que hacer y que me dejen hacerlo”. Nadie tiene tiempo para más.

Si realmente queremos ser efectivos en el proceso deberíamos hacer que el proceso fuera integrado e integrador, durante todo el ciclo de creación de una nueva feature (o un nuevo procedimiento para solucionar un problema dado) todos los interesados deben estar en conexión contínua, si no estaremos creando una feature factory, y probablemente una factory que termine por entregar cosas que nadie quiere realmente.

Debemos crear un proceso que permita el feedback continuo, hacer una buena inception al principio que haga que todas las partes realmente estén en la misma página y comprendan lo que se quiere hacer, crear un espacio de verdadera comunicación en el que la ideación de nuevas features sea un proceso colaborativo. De otro modo nos espera una carrera de obstáculos en la que difícilmente las necesidades de nuestros stakeholders quedarán satisfechas.

Si tenemos fronteras que impiden que los equipos de producto y tecnología trabajen en estrecha coordinación con el resto de equipos (a los que dan servicio) estaremos, en el mejor de los casos creando productos y servicios muy por debajo de nuestra capacidad real.

Conclusión

Si has llegado hasta aquí te mereces que explique la conclusión a la que quiero llegar.

Más adelante seguiré hablando de la ley de Conway y de sus usos y virtudes, pero primero tenía que explicar cómo, en mi opinión, la comunicación es el pilar principal y primero sobre el que tenemos que construir una organización (sea una startup, una pyme o una gran corporación) de modo que pueda funcionar al máximo rendimiento posible, ofreciendo al mundo un producto o servicio que merezca la pena.

Una vez hayamos convertido nuestra organización en una verdadera “Comunidad comunicativa” podremos beneficiarnos del uso de la Ley de Conway para alinear nuestra estructura con nuestra arquitectura, antes, igual, estaremos dando palos de ciego.

Seguiremos hablando de esto en futuros episodios, por hoy, espero que esta pieza haya sido de tu agrado, y que te animes a suscribirte (si no lo has hecho todavía) a compartir con alguien a quién le pueda interesar o a dejar un like.

Gracias por tu tiempo y tu atención.