El río

En 1966, Bob Taylor tenía un problema de fontanería. No literal, pero la metáfora sirve. Taylor era el director de la oficina de investigación informática del Pentágono — la IPTO, dentro de ARPA — y en una salita contigua a su despacho tenía tres terminales. Uno conectado al MIT. Otro a Berkeley. Otro a Santa Mónica. Cada uno con su propio sistema operativo, su propio lenguaje de programación, su propio procedimiento de acceso. Tres cañerías que no se tocaban.

"It became obvious", diría años después, "that we ought to find a way to connect all these different machines."

ARPANET nació de esa frustración. No de un plan militar para sobrevivir a un ataque nuclear — eso es un mito que Taylor persiguió durante años sin éxito —, sino de la molestia cotidiana de un hombre que quería que la información fluyera y no podía. La escena está recogida en Where Wizards Stay Up Late, la crónica de Katie Hafner y Matthew Lyon sobre los orígenes de internet.

Veinte años más tarde, en otro despacho de otro centro de investigación, la historia se repitió. Tim Berners-Lee trabajaba en el CERN, rodeado de sistemas que no se hablaban: VAX/NOTES, CERNDOC, ENQUIRE, IBM GroupTalk, uucp News. Su propuesta de marzo de 1989, garabateada en un diagrama que hoy se conserva como pieza de museo, proponía unificarlos bajo un concepto que llamó Mesh. Un supervisor escribió en el margen: "Vague but exciting." Al poco tiempo, Mesh cambió de nombre. Se llamó World Wide Web.

Las dos escenas son versiones del mismo gesto: alguien mira un mapa de canales separados y decide que tiene que haber un río.

Mesh, mess

La palabra que eligió Berners-Lee es interesante. Mesh — malla, red, tejido — sugiere conexión sin jerarquía. Un espacio donde las cosas se tocan unas a otras sin un centro que las ordene. No un árbol, no una pirámide: una trama.

Cualquiera que trabaje hoy construyendo producto digital reconocerá en esa trama algo familiar. El ciberespacio que Berners-Lee ayudó a crear es efectivamente un mesh: distribuido, interconectado, sin fronteras claras, en cambio continuo. Pero esa misma palabra — mesh — suena sospechosamente parecida a otra: mess. Lío. Desorden. Caos.

No es una coincidencia etimológica — vienen de raíces distintas —, pero es una coincidencia funcional. Lo que empieza como una malla diseñada termina, con frecuencia, sintiéndose como un lío. Y no porque alguien lo haya hecho mal. Sino porque la naturaleza del espacio lo produce.

La ley

En 1968, un año antes de que se instalara el primer nodo de ARPANET, un matemático llamado Melvin Conway publicó un artículo breve en la revista Datamation. Se titulaba How Do Committees Invent? y contenía una observación que se ha convertido en una de las leyes más citadas de la ingeniería del software:

"Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure."

Conway no estaba hablando de internet. Estaba hablando de compiladores de COBOL. Pero su observación funcionaba a cualquier escala. Lo que decía era que no puedes separar lo que construyes de cómo te organizas para construirlo. La estructura de comunicación de la organización se imprime en el producto como una marca de agua. Si tienes cinco equipos, tu sistema tendrá cinco módulos. Si dos equipos no se hablan, sus componentes no se integrarán bien. No es una tendencia: es un homomorfismo. Una correspondencia estructural matemática.

Lo más provocador de Conway no es el diagnóstico. Es lo que se deriva de él. Si la organización se copia en el producto, y el producto cambia constantemente — como ocurre con cualquier producto digital —, entonces la organización tiene que poder cambiar con él. Conway lo decía con claridad en su conclusión: "flexibility of organization is important to effective design." Lo decía en 1968, antes de que existiera agile, Scrum o Spotify.

La corriente

Pero hay algo más profundo en la ley de Conway que pasa desapercibido cuando se la trata como una curiosidad de la ingeniería del software. Y tiene que ver con la palabra stream.

En inglés, stream es a la vez corriente de agua y corriente de datos. Río e información comparten nombre. No es una casualidad del idioma: es una pista sobre la naturaleza del espacio. Lo que fluye en el producto digital es información. Lo que fluye dentro de la organización que lo construye es también información: conversaciones, decisiones, documentos, código, datos. El bien sobre el que trabajas y el bien con el que trabajas son el mismo.

Esto marca una diferencia radical con cualquier industria anterior. Una constructora se coordina con planos, reuniones y contratos, pero produce hormigón y acero. Un hospital funciona con historiales, protocolos y turnos, pero su resultado es la salud física de un paciente. Un bufete de abogados trabaja intensamente con información, pero su producto final — un contrato, una sentencia, una fusión ejecutada — vive fuera del medio en el que se organizó. En todos estos casos, la sustancia de la organización y la sustancia del producto son distintas. Se tocan, se influyen, pero no se confunden.

Y sin embargo, algo está cambiando en todas ellas. A medida que la constructora gestiona obra con software, que el hospital digitaliza sus procesos clínicos, que el bufete automatiza la revisión de contratos, cada una de estas industrias empieza a enfrentarse a problemas que antes solo tenían las empresas de producto digital. La coordinación se vuelve más difícil. Los equipos técnicos y los de negocio dejan de entenderse. La estructura organizativa empieza a imprimirse en el software que producen — exactamente como describe Conway. El río les llega. No porque hayan decidido ser empresas tecnológicas, sino porque el software, al entrar, trae consigo su naturaleza: la del medio que no distingue entre lo que eres y lo que produces.

Una organización nativa de producto digital simplemente vive en esa realidad desde el principio. Está hecha de comunicación — Slack, repositorios, documentos, tickets, llamadas — y produce comunicación — software, APIs, interfaces, flujos de datos. El medio de la organización y el medio del producto son indistinguibles. Conway no es una analogía ingeniosa: es casi una tautología. Claro que la estructura de comunicación se copia en el producto. Están hechos de lo mismo.

Peter Drucker vio venir esto antes que nadie. Cuando acuñó el término knowledge worker en 1959, estaba señalando exactamente esta mutación: el trabajador ya no transforma materia en producto, transforma información en información. Y eso lo cambia todo.

"The knowledge worker cannot be supervised closely or in detail. He can only be helped. But he must direct himself, and he must do it toward performance and contribution, that is, toward effectiveness."

— Peter Drucker, The Effective Executive

En la lógica tradicional de cualquiera de esas industrias, el trabajador opera sobre un material que es distinto del medio en el que se organiza. El albañil pone ladrillos, el cirujano opera tejido, el abogado redacta cláusulas — pero ninguno de ellos está hecho del mismo material que su producto. Hay una separación natural entre la organización y lo que produce. Esa separación permite un tipo de gestión: el gestor diseña el proceso, el trabajador lo ejecuta sobre el material. Pero cuando el software entra en escena — ya sea como producto principal o como infraestructura que atraviesa la operación —, esa separación se empieza a disolver. El trabajador del conocimiento no ejecuta un plan — contribuye a un flujo. Y el flujo es la misma sustancia de la que está hecha la organización. Por eso ninguna industria que incorpore software de forma sustancial puede seguir gestionándose con los modelos que funcionaban cuando organización y producto vivían en medios separados. No es una cuestión de estilo ni de filosofía gerencial. Es una cuestión de física: el material no lo permite.

La entropía

Drucker, que tenía el don de las frases que parecen obvias hasta que las piensas dos veces, escribió también:

"Only three things happen naturally in organizations: friction, confusion, and underperformance. Everything else requires leadership."

— Peter Drucker, Managing Oneself

Es una frase que habla de termodinámica social. El estado natural de una organización no es el orden — es la entropía. Dejada a su suerte, cualquier organización se degrada. No porque la gente sea mala o incompetente, sino porque la complejidad crece más rápido que la capacidad de coordinarla. Conway ya lo había descrito como un proceso de tres pasos: primero, la tentación de asignar demasiada gente; después, la fragmentación de las rutas de comunicación al crecer; por último, el homomorfismo que garantiza que esa fragmentación se traslade al sistema.

En una cadena de montaje o en un quirófano, la entropía se combate con procesos. Se estandariza. Se mide. Se aprietan tuercas. Pero en el espacio digital — en el río — el proceso no basta. Porque lo que produces no es estático. Y porque, como vimos, el material del que está hecha la organización y el material que produce son el mismo. La entropía no solo degrada la operación: degrada directamente el producto. Los bugs culturales de Horowitz y los impedimentos invisibles de Catmull no son problemas de gestión que afectan indirectamente al software. Son problemas del mismo medio que el software.

El código invisible

Las organizaciones de producto digital lo saben, o al menos lo intuyen. Llevan años intentando encontrar formas de organizarse que respondan a la naturaleza del espacio en el que operan. Los nombres van cambiando — squads, tribus, equipos multifuncionales, equipos de plataforma — pero el problema de fondo es siempre el mismo: cómo hacer que la estructura no sea un dique que frene la corriente.

Ben Horowitz lo expresó con una metáfora que habla directamente de esta dificultad:

"That's the nature of culture. It's not a single decision—it's a code that manifests itself as a vast set of actions taken over time. No one person makes or takes all these actions. Cultural design is a way to program the actions of an organization, but, like computer programs, every culture has bugs. And cultures are significantly more difficult to debug than programs."

— Ben Horowitz, What You Do Is Who You Are

La cultura es código. Pero es código que se ejecuta de forma distribuida, sin compilador, sin tests, sin logs. Cuando algo falla no aparece un error en pantalla — aparece una reunión que no debería existir, una decisión que nadie toma, un equipo que no se siente dueño de nada.

Ed Catmull, desde Pixar, describió el otro lado del problema con una honestidad poco frecuente:

"We start from the presumption that our people are talented and want to contribute. We accept that, without meaning to, our company is stifling that talent in myriad unseen ways. Finally, we try to identify those impediments and fix them."

— Ed Catmull, Creativity, Inc.

El punto de partida de Catmull no es que la gente falle. Es que la organización la frena sin querer. El talento ya está ahí. Los impedimentos son invisibles. Y el trabajo del liderazgo no es diseñar la cultura desde arriba, sino quitar los obstáculos que impiden que fluya.

Topologías del flujo

No es casual que la industria de producto digital haya producido, en los últimos años, una literatura propia sobre cómo organizarse. Es un síntoma. Cuando un campo necesita tantos libros sobre un tema, es que el tema no está resuelto.

Matthew Skelton y Manuel Pais publicaron Team Topologies en 2019. Su propuesta organiza los equipos en cuatro tipos: equipos alineados con el flujo de valor (stream-aligned teams), equipos de plataforma, equipos habilitadores y equipos de subsistemas complicados. Lo relevante no es la taxonomía — hay muchas —, sino el nombre que le dan al equipo fundamental: stream-aligned. Alineado con la corriente. Es la misma palabra — stream — que nombra a la vez el río y el flujo de datos. Y no es casual. Lo que Skelton y Pais están diciendo, quizá sin pretenderlo del todo, es que el equipo que entrega valor debe reconocer que ya está dentro del agua. No se trata de posicionarse frente a algo externo. Se trata de aceptar que la organización y el producto están hechos de la misma sustancia, y organizarse en consecuencia.

Amy Edmondson publicó The Fearless Organization el mismo año. Su argumento ataca el problema desde otro ángulo: si el espacio digital es inherentemente incierto — si los problemas están débilmente definidos, si el producto cambia constantemente, si nadie tiene todas las respuestas — entonces necesitas que la gente pueda equivocarse sin miedo. La seguridad psicológica no es un lujo humanista. Es una condición operativa. Sin ella, la información no fluye, los errores se esconden, y la organización se vuelve ciega ante sus propios bugs culturales.

Sin esa base, da igual el estilo de liderazgo que se quiera practicar.

Que estos dos libros aparecieran casi al mismo tiempo no es coincidencia. Son respuestas complementarias al mismo problema: cómo construir organizaciones que puedan bañarse en el río que habitan sin ahogarse.

El liderazgo reescrito

En diciembre de 2025, el podcast de Lenny Rachitsky — probablemente el más influyente del ecosistema de producto — publicó una conversación con Matt MacInnis, CPO de Rippling. El título era provocador: "10 contrarian leadership truths." Entre las ideas: infraequipar deliberadamente los proyectos. Luchar contra la entropía con energía e intensidad. No asumir que añadir personas añade productividad. Entre las referencias citadas: la Ley de Conway.

Un podcast de 2025 citando un paper de 1968 sobre compiladores de COBOL. La industria lleva casi sesenta años descubriendo la misma cosa por distintos caminos.

Lo que MacInnis describe como "contraintuitivo" solo lo es si vienes de la lógica industrial. En la lógica del río, tiene todo el sentido. Un equipo pequeño y comprometido lee mejor la corriente que un ejército de remeros. Conway ya lo había escrito: dos personas, si están bien elegidas y sobreviven a la experiencia, producirán un sistema mejor que cien. Las asunciones que sirven para pelar patatas y levantar muros de ladrillo no sirven para diseñar sistemas.

Satya Nadella lo sintetizó en una frase que parece simple:

"Leaders are those who step up, not those who shout the loudest."

En un entorno donde los problemas no están predefinidos y las soluciones no son lineales, el liderazgo no puede ser directivo. Tiene que ser emergente. No el que grita más fuerte desde la orilla, sino el que se mete en el agua y lee la corriente. Los seis estilos de liderazgo que Daniel Goleman describe — coercitivo, autoritativo, afiliativo, democrático, ejemplar, coach — no son opciones para elegir una. Son registros para combinar según lo que el momento exige. Un líder que solo sabe gritar "haz lo que te digo" puede funcionar en una crisis. Pero si ese es su único registro, secará el río.

El río

Hay una forma de leer la historia del producto digital como una progresión técnica: de los mainframes a internet, de internet al móvil, del móvil a la nube, de la nube a la inteligencia artificial. Esa lectura es correcta pero incompleta.

La otra lectura — la que intento trazar aquí — es organizativa. Desde que Taylor conectó aquellos tres terminales, las personas que construyen productos digitales están aprendiendo que el espacio en el que trabajan no se comporta como una fábrica. No es predecible. No es lineal. No se puede gestionar con organigramas estáticos ni con procesos fijos. Es un río: fluye, cambia de curso, arrastra lo que encuentra, erosiona las estructuras rígidas, premia a quien se adapta.

Las tensiones que viven las organizaciones de producto — entre autonomía y alineamiento, entre velocidad y calidad, entre estructura y flexibilidad — no son señales de que algo está roto. Son la consecuencia natural de construir dentro de un espacio que es, por naturaleza, fluido. La Ley de Conway es una ley natural de este espacio: tu organización se imprime en lo que construye. Si tu organización es rígida, tu producto será rígido. Si tu organización fluye, tu producto fluirá.

La publicación constante de libros, frameworks y podcasts sobre cómo organizar equipos de producto no es un signo de inmadurez de la disciplina. Es lo contrario: es la señal de que la disciplina ha entendido que el problema organizativo es inseparable del problema técnico. Que no puedes construir bien si no te organizas bien. Y que organizarse bien, en este espacio, no significa encontrar la estructura perfecta y quedarse en ella. Significa mantener la capacidad de cambiar cuando el río cambia.

Berners-Lee llamó Mesh a su propuesta. Una malla. Lo que construimos sobre esa malla se siente, muchas veces, como un mess. Un lío. La tentación es buscar el orden, el control, la tuerca que se aprieta al ritmo correcto. Hay que equilibrar esa tentación con una alegre entrega a bañarnos en el río.