La ley de Conway
El origen de muchas malas decisiones en arquitectura de sistemas
Cuando entré a trabajar en Epos Now, una startup FinTech, me encontré con un desafío que no era el típico “hay que escalar la tecnología”. Sí, la empresa estaba creciendo rápido. Sí, la base de usuarios aumentaba cada día. Sí, había que modernizar el stack inicial diseñado por becarios de la universidad. Y sí, también había que escalar la tecnología… Pero nada de eso resultó ser realmente el cuello de botella. El mayor freno era organizativo. La estructura de equipos y la forma de trabajar habían moldeado (para mal) lo que habíamos construido.
Era una organización puramente reactiva, con un equipo de ingeniería que operaba en modo caja negra y reportaba directamente a los jefes de producto. Y esa estructura se veía reflejada en la arquitectura del producto, que era un monolito difícil de mantener, con límites difusos, sin ownership y con decisiones impulsadas por quien gritara más fuerte ese día.
Aunque igual esto no te sorprende. Si has trabajado en una organización con una comunicación lenta, difusa o caótica, habrás visto cómo las decisiones técnicas se vuelven rehenes de las decisiones organizativas. Equipos bloqueados porque dependen de otro equipo, que a su vez depende de otro equipo, que a su vez depende de… vete tú a saber quién. Cosas mal parcheadas porque “ese componente lo toca otro equipo y no puede hacerlo ahora mismo”. Retrasos, frustración y esa sensación de que “esto podría ir mucho más rápido, pero algo nos está frenando”.
Ese “algo” tiene nombre desde 1968: la ley de Conway. Y es implacable.
“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”
— Melvin Conway, 1968
O, dicho de otro modo, la organización de la empresa se refleja en la arquitectura del sistema que esta produce.
Unos meses antes de que yo llegara, la empresa había contratado a un CTO que ya había empezado a trabajar en el problema del desorden, separando al equipo de ingeniería del de producto, con sus propios líderes (yo incluido) y procesos. Esta separación permitió que ingeniería recuperara autonomía y gobierno para priorizar la calidad, la arquitectura y la infraestructura, y no únicamente las nuevas funcionalidades.
Pero esto solo no resuelve el problema. Según la ley de Conway, si no diseñas tu organización para producir la arquitectura que quieres, te impondrá una arquitectura que no quieres. Y eso es precisamente lo que pasaba.
El equipo de ingeniería recibía peticiones de todas partes: jefes de producto, VPs, COO, CEO… Con tantos canales de entrada, el software estaba fragmentado, con prioridades cambiantes, decisiones inconexas, sistemas acoplados y una arquitectura infumable.
Aunque inicialmente entré para liderar infraestructura, a los pocos meses me convertí en director de ingeniería. Esto me permitió tener una visión mucho más global de todo y la verdad es que el paisaje era desolador. Pero también me brindó la oportunidad de trabajar en uno de los retos más interesantes en mi carrera profesional. Con la salida del CTO, vino una reorganización y mi compañero James y yo terminamos por tomar las riendas del caballo desbocado. Teníamos clara la visión arquitectónica que queríamos: pasar del monolito a un conjunto de dominios bien definidos, cada uno con sus servicios, su modelo mental y su equipo de liderazgo.
La respuesta vino de aplicar la ley de Conway inversa, aunque nosotros no sabíamos que se llamaba así. Simplemente la dedujimos a base de cabezados, y darnos cuenta de que como la información fluía tenía un impacto directo en lo que produciamos. Esta idea fue formalizada por Jonny Leroy y Matt Simons, de ThoughtWorks, en 2010. La resumen así:
Instead of systems and products reflecting the structures that developed them, organizations are shaped by the design of the products they build for customers. This improves products’ time-to-market and quality through a dedicated focus on value creation.
Esta es la tendencia hoy en las empresas tecnológicas. Se organizan los equipos según la arquitectura del servicio que queremos construir, no según funciones genéricas (p. ej., frontend, backend, database, sysadmins…). Esto es la espina dorsal de Team Topologies, de Manuel Pais y Matthew Skelton (muy buen libro si necesitas ideas para organizar equipos).
James y yo terminamos por organizar los equipos de Epos Now en distintas tribus: Money, Data, POS, Integrations… que a su vez tenían distintos flujos de trabajo: mobile app, Web app, hardware, payments, my account… Cada equipo con ownership claro, fronteras bien definidas, un product manager único como punto de entrada, autonomía técnica y responsabilidad absoluta sobre su servicio. La diferencia fue inmediata. Había menos confusión, priorizaciones más claras, menos bugs, ciclos de desarrollo más cortos… y equipos más motivados.
Y casi como por magia, la arquitectura que queríamos empezó a alinearse con la nueva organización. Pero no era magia, era simplemente la ley de Conway funcionando a nuestro favor.
Reorganizar equipos implica quitar poder, cambiar hábitos y poner límites a quien antes podía pasar por encima del proceso. Eso no gustaba. Hubo resistencia. Mucha. Especialmente fuera de ingeniería. Pero con transparencia, diálogo, paciencia y resultados, la mayoría entendió que esta organización no era un capricho, sino una necesidad.
¡Muchas gracias por leerme!