Diseñar el sistema donde la ingeniería puede crecer
En ingeniería confiamos en sistemas. Es lo que sabemos hacer: definir estructuras, reducir variabilidad, encontrar el diseño que produce el resultado esperado. Y cuando esa lógica funciona, funciona bien.
El problema aparece cuando la aplicamos a equipos de forma superficial, asumiendo que si ponemos a las personas correctas en los lugares correctos, el sistema funcionará solo.
La mayoría de los errores al entender un sistema no vienen de entender mal las partes, sino de no entender las relaciones entre ellas. — Donella Meadows, Thinking in Systems
Un equipo no es la suma de sus integrantes. Es el resultado de las conexiones, restricciones e incentivos que definen cómo esos integrantes trabajan juntos. Y ese sistema —diseñado conscientemente o construido por inercia— siempre está produciendo resultados.
He visto equipos con talento real que no evolucionan. No por falta de capacidad, sino porque operan en un entorno que nunca fue diseñado para que crecieran. Y también lo contrario: equipos sin condiciones ideales que avanzan de forma consistente porque alguien construyó deliberadamente el sistema correcto. La diferencia no siempre es visible desde fuera. Pero siempre está presente.
Gestión de trabajo no es gestión de personas
Uno de los errores más persistentes en liderazgo técnico es tratar ambas cosas como si fueran lo mismo. Asignar tareas, dar seguimiento, medir entregas organiza trabajo. Es necesario. Pero no construye un equipo.
Richard Hackman dedicó décadas a estudiar por qué algunos equipos funcionan y otros no. Su conclusión fue incómoda para quienes creen que el liderazgo consiste principalmente en asignar y controlar: más del 60% de la variación en efectividad de un equipo se explica por las condiciones en las que opera, no por el talento individual de sus integrantes. Las condiciones importan más que la capacidad instalada.
Un ingeniero no produce valor por seguir instrucciones. Produce valor por su capacidad de entender un problema, decidir con criterio y ajustar cuando algo no está funcionando. Si eso es verdad —y la experiencia lo confirma consistentemente— entonces el liderazgo técnico no puede centrarse únicamente en qué se hace. Tiene que centrarse en las condiciones que permiten hacerlo bien.
Ahí es donde muchos sistemas fallan silenciosamente. El feedback aparece cuando algo sale mal. La conversación profunda sobre el trabajo ocurre en la retrospectiva, no en el día a día. El error se corrige, pero rara vez se analiza. Lo que debería ser un mecanismo continuo de ajuste se vuelve una respuesta puntual al problema. Bajo esa lógica, el aprendizaje es reactivo. Y un sistema reactivo no escala.
El aprendizaje organizacional necesita estructura, no intención
Aprender de forma consistente no es cuestión de intención. Es cuestión de estructura.
Cada sistema está perfectamente diseñado para producir los resultados que produce. — W. Edwards Deming
Si un equipo no aprende, no es falta de talento. Es falta de diseño. Y hay una implicación de esto que en ingeniería deberíamos reconocer de inmediato, pero que rara vez conectamos con el liderazgo: la Ley de Conway.
En 1968, Melvin Conway observó que las organizaciones diseñan sistemas que replican su propia estructura de comunicación. Lo que comenzó como una observación técnica sobre arquitectura de software es, en realidad, una afirmación sobre sistemas humanos: la forma en que un equipo está organizado define, en gran medida, lo que ese equipo puede construir. Los silos de comunicación producen silos en la arquitectura. Los cuellos de botella organizacionales producen cuellos de botella en el sistema.
Eso tiene una consecuencia directa: si quieres cambiar lo que el equipo produce, primero tienes que cambiar cómo el equipo funciona. No al revés. Y cambiar cómo funciona un equipo requiere diseño deliberado, no solo buenos propósitos ni un par de reuniones de alineación.
La confianza no es cultura: es infraestructura operativa
Ese diseño deliberado depende de una condición que no siempre se construye de forma explícita: que las personas puedan decir lo que realmente están viendo.
Amy Edmondson encontró algo contraintuitivo al estudiar equipos de alto desempeño en entornos de alta presión: los mejores equipos no son los que cometen menos errores, sino los que pueden hablar de ellos sin miedo. En equipos con baja seguridad psicológica, la energía que debería ir al trabajo va a la gestión de la percepción. Las personas filtran lo que dicen, protegen su posición y evitan las conversaciones incómodas. El resultado es un sistema que no puede procesar información honesta.
Y sin información honesta, no hay mejora real.
La confianza, en ese contexto, no es un valor cultural abstracto. Es infraestructura operativa. Su ausencia tiene costos concretos: reuniones donde nadie dice lo que realmente piensa, decisiones tomadas fuera de la conversación formal, problemas que escalan porque nadie quiso señalarlos antes de que crecieran. Un sistema sin confianza se protege en lugar de aprender. Y un sistema de autoprotección no mejora. Se mantiene.
La empatía como herramienta de diagnóstico
Hay una dimensión del liderazgo que rara vez aparece en las conversaciones técnicas: la empatía como herramienta de diagnóstico. No como concesión emocional. Como capacidad de entender cómo se experimenta el sistema desde dentro.
Un proceso puede verse correcto en papel y generar confusión al ejecutarse. Una decisión puede ser lógica y ser imposible de implementar sin el contexto que solo tiene quien hace el trabajo. Un equipo puede parecer desenganchado cuando en realidad está saturado. Sin esa comprensión, cualquier intervención opera sobre síntomas, no sobre causas.
La distinción importa más de lo que parece. Falta de capacidad y falta de contexto producen síntomas similares pero requieren respuestas completamente distintas. Resistencia y saturación se parecen desde fuera, pero una se resuelve con conversación y la otra con rediseño de carga. Confundir las dos no solo no resuelve el problema: lo agrava.
En tecnología hablamos constantemente de diseño, pero casi siempre lo asociamos a sistemas, productos o arquitectura. Rara vez al trabajo mismo. Cada forma de organizar el trabajo produce un patrón. Cada estructura de reunión define qué conversaciones son posibles. Cada proceso de toma de decisiones establece quién tiene voz real. Cuando esos elementos no se diseñan conscientemente, los define la inercia. Y la inercia rara vez produce el sistema que uno querría sostener si lo pensara con detenimiento.
Lo que no se cuestiona, escala mal
Los procesos se definen una vez y se mantienen, incluso cuando el contexto cambió. Lo que en su momento tenía sentido se convierte, con el tiempo, en una restricción que nadie cuestiona porque nadie recuerda por qué existe.
Peter Senge describe en La Quinta Disciplina una trampa frecuente en sistemas complejos: las soluciones de hoy se convierten en los problemas de mañana. Lo que se resolvió de forma expedita, sin entender sus consecuencias más amplias, aparece después como una restricción que nadie sabe de dónde viene.
Fred Brooks documentó algo parecido desde otra perspectiva. En The Mythical Man-Month observó que agregar personas a un proyecto tardío lo hace más tardío, no porque las personas no sirvan, sino porque la complejidad de coordinación crece más rápido que la capacidad adicional. Escalar sin revisar la estructura no es eficiencia. Es amplificar los problemas que ya existen.
Los equipos que evolucionan no asumen que su forma de trabajar es correcta por definición. La tratan como un sistema vivo: la revisan, identifican dónde genera fricción y la ajustan antes de que esa fricción se vuelva crónica. En ingeniería prototipamos antes de escalar. Ese principio aplica exactamente igual a la forma de trabajar.
Diseñar el sistema, no solo el equipo
Todo esto converge en algo que parece simple pero que requiere disciplina sostenida para construirlo.
El feedback define cómo aprende el equipo. La estructura determina si ese aprendizaje se sostiene. La confianza permite que ocurra sin fricción innecesaria. La empatía revela lo que no es visible desde afuera. El diseño deliberado evita que la inercia tome decisiones por omisión. Y la capacidad de cuestionar cómo se trabaja evita que las decisiones correctas de hoy se conviertan en el obstáculo de mañana.
Cuando ese sistema está bien construido, el equipo evoluciona. No porque todos sean excepcionales, sino porque el entorno permite que el talento opere con claridad. Cuando no lo está, incluso los mejores ingenieros se desgastan.
El liderazgo técnico, en ese contexto, deja de ser coordinación. Se convierte en diseño. No construyes un equipo con talento. Diseñas el sistema donde ese talento puede crecer.
Y ese sistema —consciente o no— siempre está produciendo resultados. La pregunta es si son los que realmente quieres sostener.
Déjame tus comentarios al respecto que opinas.
