Pensamiento sistémico: ¿Dónde está el problema real cuando algo falla repetidamente en tu equipo?

El síntoma no es el problema (aunque lo parezca)

Es lunes por la mañana y tu equipo llega a la daily con las mismas caras de cansancio de siempre. Tres personas reportan que "casi terminaron" las tareas que llevaban "casi terminadas" desde hace una semana. Alguien menciona que necesita acceso a un entorno de pruebas que lleva bloqueado desde el sprint anterior. El Scrum Master anota el impedimento en la pizarra, junto a otros cinco que llevan ahí desde febrero.

Después de la reunión, el Product Owner te comenta: "Necesitamos mejorar el commitment del equipo". El delivery manager sugiere hacer un workshop de estimación. Recursos humanos propone una formación en gestión del tiempo.

Todas estas respuestas parten de la premisa de que el problema está en el equipo. Pero ¿y si el equipo simplemente está manifestando un problema que existe fuera de él?

Peter Senge, en su obra seminal La quinta disciplina (1990), describe este fenómeno como "desplazamiento de la carga": concentramos la atención en resolver síntomas porque son visibles y medibles, mientras las causas estructurales permanecen ocultas y sin abordar. La dificultad es que resolver síntomas proporciona alivio temporal —suficiente para validar la intervención— pero no elimina la causa raíz, por lo que el problema resurge en cuanto dejamos de aplicar el parche.

Donella Meadows, una de las voces más influyentes en pensamiento sistémico, lo expresó con claridad: "El comportamiento de un sistema es una consecuencia de su estructura" (Thinking in Systems, 2008). Si queremos cambiar comportamientos recurrentes, necesitamos modificar la estructura que los genera. Pero primero necesitamos verla.

Estructuras invisibles que generan disfunciones visibles

Las estructuras sistémicas no son diagramas organizacionales ni procesos documentados. Son patrones de incentivos, normas implícitas, flujos de información y relaciones de poder que condicionan el comportamiento de las personas dentro de un sistema. Están ahí, operando constantemente, pero rara vez se hacen explícitas.

Cuando el sistema recompensa lo contrario de lo que pide

Tomemos un ejemplo frecuente: una organización que dice valorar la innovación pero evalúa a los equipos exclusivamente por cumplimiento de plazos y scope cerrado. ¿Qué estructura invisible opera aquí?

• Incentivo formal: "Sean innovadores, propongan mejoras, experimenten"
• Incentivo real: "Entregren exactamente lo prometido, sin sorpresas, sin retrasos"
• Comportamiento resultante: Los equipos minimizan riesgos, evitan experimentos, entregan lo mínimo acordado

Chris Argyris llamó a esto "teorías en uso" versus "teorías proclamadas" (Organizational Learning II, 1996). Lo que las organizaciones dicen que valoran (su teoría proclamada) con frecuencia contradice lo que realmente recompensan o castigan (su teoría en uso). Los equipos no son ingenuos: leen la estructura real, no el discurso.

Este desajuste genera lo que Argyris denomina "aprendizaje de bucle simple": la organización mejora en hacer más eficientemente lo mismo, pero nunca cuestiona si eso que hace tiene sentido. El problema recurrente —en este caso, falta de innovación— no se resolverá con workshops de creatividad si la estructura sigue castigando el riesgo.

El cuello de botella que nadie ve (porque está en el organigrama)

Otro patrón habitual: un equipo depende sistemáticamente de aprobaciones de un comité o de un área externa que funciona con lógica y tiempos distintos. El equipo ágil trabaja en sprints de dos semanas; el comité de seguridad se reúne una vez al mes. El equipo está organizado por producto; arquitectura está organizada por tecnología y tiene sus propias prioridades.

Esto no es un "problema de alineación" que se resuelve con una reunión. Es un problema de diseño estructural: dos subsistemas optimizados para objetivos diferentes intentan colaborar sin que nadie haya diseñado el mecanismo de coordinación.

Russell Ackoff, pionero del pensamiento sistémico, sostenía que la mayoría de los problemas organizacionales son problemas de interacción entre partes, no problemas de las partes mismas (Systems Thinking for Curious Managers, 2010). Un equipo puede funcionar impecablemente en aislamiento y aun así experimentar disfunciones continuas si su entorno estructural no está diseñado para la colaboración que se espera de él.

Muchos frameworks de escalado ágil —SAFe, LeSS, Nexus— abordan precisamente esto: rediseñar estructuras organizacionales para que la agilidad no quede confinada a islas de equipos rodeadas de burocracia. Pero no se puede escalar agilidad sin cambiar estructuras. Los equipos no pueden "ser más ágiles" dentro de estructuras que los ralentizan.

Diagnosticar el sistema: de qué sirve ver el problema si no puedes cambiarlo

Supongamos que ya identificaste la estructura invisible. Has detectado que el problema recurrente no es "falta de compromiso del equipo" sino incentivos mal alineados, dependencias estructurales no resueltas o información que no fluye entre áreas. ¿Y ahora qué?

Aquí es donde el pensamiento sistémico se vuelve incómodo. Porque ver el sistema no te da automáticamente el poder de cambiarlo.

Niveles de influencia: qué puedes cambiar desde dónde estás

Meadows propone una jerarquía de "puntos de apalancamiento" en sistemas: lugares donde una intervención pequeña puede producir cambios significativos (Leverage Points: Places to Intervene in a System, 1999). Pero la paradoja es que los puntos de mayor impacto —cambiar paradigmas, modificar reglas del sistema— suelen estar fuera del alcance de quienes más sufren las disfunciones.

Si eres Scrum Master de un equipo, puedes cambiar cómo facilitas retrospectivas, pero no puedes cambiar la estructura de incentivos corporativa. Si eres Agile Coach, puedes visibilizar disfunciones sistémicas, pero no siempre tienes el mandato o la influencia política para modificarlas. Si eres líder de transformación, puedes cambiar estructuras, pero no siempre tienes el respaldo ejecutivo para hacerlo sin resistencia feroz.

Gene Kim, en The Unicorn Project (2019), narra esta tensión de forma magistral: protagonistas que ven claramente las estructuras disfuncionales pero no tienen el poder formal para cambiarlas. Recurren entonces a "mejoras subversivas": cambios informales, coaliciones, experimentos piloto que demuestran que otro modo es posible. A veces funciona. A veces no.

Señales de que el problema es estructural (y necesitas apoyo ejecutivo)

¿Cómo saber si estás ante un problema sistémico que requiere intervención de niveles superiores? Algunas señales:

El problema reaparece con equipos diferentes. Si rotas personas y el patrón persiste, no es un problema de competencias individuales.

Las soluciones locales funcionan temporalmente y luego se revierten. Un equipo implementa mejoras, pero cuando la presión organizacional aumenta, vuelven a los comportamientos anteriores.

Las personas describen el problema como "es que aquí así funcionamos". Cuando el comportamiento disfuncional está normalizado, la estructura lo sostiene.

Cualquier cambio propuesto requiere aprobaciones de áreas que no tienen incentivos para facilitarlo. Si cada mejora necesita negociar con silos que pierden poder o recursos al aprobarla, la estructura bloquea por diseño.

En estos casos, visibilizar el sistema es un acto de honestidad profesional. Un Scrum Master que identifica una disfunción estructural y pretende que el equipo la resuelva internamente está desplazando responsabilidad hacia abajo. Un coach que diagnostica incentivos mal alineados y no lo escala a quien puede actuar sobre ellos está siendo cómplice del sistema.

Intervenciones posibles cuando no puedes cambiar la estructura (todavía)

Reconocer que un problema es sistémico no siempre significa rendirse. A veces significa trabajar estratégicamente dentro de las restricciones existentes mientras se construyen condiciones para el cambio estructural.

Hacer visible el costo del sistema actual

Los sistemas disfuncionales persisten porque sus costos están ocultos o distribuidos. Si nadie mide cuánto tiempo pierden los equipos esperando aprobaciones, la organización no percibe urgencia en cambiar el proceso de aprobación.

El informe State of DevOps (DORA, 2023) muestra que las organizaciones de alto rendimiento miden sistemáticamente los costos de las dependencias y los tiempos de espera. No para castigar áreas, sino para hacer evidente dónde el sistema genera fricción innecesaria.

Hacer visible no es quejarse. Es instrumentar: medir lead time por fase del proceso, identificar dónde se acumulan los cuellos de botella, cuantificar el trabajo en progreso bloqueado. Datos que permiten conversaciones sobre rediseño, no sobre culpas.

Diseñar experimentos de bajo riesgo que prueben alternativas

Si la estructura formal no se puede cambiar aún, ¿se pueden crear estructuras informales que operen en paralelo? Equipos que prueban formas de trabajo diferentes, acuerdos entre áreas para agilizar aprobaciones en ciertos contextos, pilotos con métricas que demuestren resultados.

John Kotter, en Accelerate (2014), propone operar con una "red de cambio" paralela a la jerarquía formal: personas de diferentes niveles que experimentan con nuevas formas de trabajar sin necesidad de cambiar todo el organigrama de golpe.

No siempre funciona. A veces los pilotos exitosos se quedan en pilotos porque escalarlos requiere desmantelar estructuras de poder. Pero es una estrategia más efectiva que esperar el big bang de la transformación que nunca llega.

Proteger al equipo del sistema (sin pretender que el sistema no existe)

Hay Scrum Masters y coaches que actúan como amortiguadores: filtran presiones organizacionales irracionales, negocian plazos imposibles, blindan al equipo para que pueda trabajar con cierta cordura. Esto no resuelve el sistema, pero crea espacios donde las personas pueden funcionar sin destruirse.

El riesgo es que esta estrategia se vuelva insostenible. El amortiguador termina quemándose porque absorbe toda la disfunción. O el equipo queda protegido de la realidad organizacional hasta que el protector se va y todo colapsa.

Heidi Helfand, en Dynamic Reteaming (2020), sugiere que en organizaciones con estructuras muy disfuncionales, una estrategia viable es rotar personas entre equipos para evitar que la toxicidad del sistema se concentre siempre en las mismas personas. No es ideal, pero es una forma de distribución de daño.

Cuando la única intervención posible es salir del sistema

Esto no suele aparecer en artículos sobre transformación ágil, pero es una verdad pragmática: no todos los sistemas se pueden cambiar, y no siempre vale la pena intentarlo.

Si trabajas en una organización con incentivos fundamentalmente alineados contra la colaboración, información retenida como fuente de poder, y un liderazgo que no tiene interés genuino en cambiar nada de esto, puedes invertir años desgastándote sin lograr mejoras sostenibles.

No es fracaso personal. Es reconocimiento de límites. Como dice Jerry Weinberg en Quality Software Management (1992): "No importa qué tan bien hagas tu trabajo, no puedes cambiar un sistema que no quiere cambiar".

El pensamiento sistémico no es neutralidad: implica elegir qué cambiar

Ver el sistema es un acto político. Porque en cuanto haces visible una estructura disfuncional, alguien se beneficia de ella. El área que retiene información para mantener poder. El comité que justifica su existencia generando burocracia. El middle management que bloquea cambios porque teme perder relevancia.

Edgar Schein, en Humble Inquiry (2013), señala que diagnosticar culturas organizacionales implica navegar dinámicas de poder: quién tiene interés en que ciertas cosas se visibilicen y quién tiene interés en que permanezcan ocultas.

Por eso el pensamiento sistémico no es una herramienta aséptica de análisis. Es una herramienta de diagnóstico que te obliga a preguntarte: ¿qué estoy dispuesto a nombrar? ¿A quién estoy dispuesto a incomodar? ¿Qué consecuencias estoy dispuesto a asumir?

Muchas disfunciones organizacionales son conocidas por todos y discutidas por nadie. Porque nombrarlas implica confrontar estructuras de poder. Y no todos tienen el capital político, la estabilidad laboral o la energía emocional para hacerlo.

No hay fórmula para esto. Pero sí hay una pregunta útil: ¿qué cambiaría en esta organización si las personas pudieran nombrar libremente las estructuras que generan las disfunciones que experimentan?

Herramientas prácticas para diagnosticar estructuras sistémicas

Aunque el pensamiento sistémico a menudo se presenta como una mentalidad abstracta, existen técnicas concretas que ayudan a hacer visible lo invisible.

Mapeo de bucles de retroalimentación

Un bucle de retroalimentación es una cadena causal donde el resultado de una acción afecta a la acción misma. Pueden ser de refuerzo (el efecto amplifica la causa) o de compensación (el efecto contrarresta la causa).

Ejemplo de bucle de refuerzo problemático:

• La presión por entregar lleva a acumular deuda técnica
• La deuda técnica ralentiza entregas futuras
• La ralentización aumenta la presión por entregar
• Resultado: espiral descendente

Ejemplo de bucle de compensación que bloquea cambios:

• Un equipo mejora su velocidad mediante automatización
• Mayor velocidad atrae más demanda de stakeholders
• Más demanda satura al equipo
• El equipo ralentiza para gestionar la demanda
• Resultado: la mejora se autocancela

Identificar estos bucles permite intervenir en el punto adecuado. A veces, romper un bucle negativo requiere cambiar incentivos externos al equipo, no mejorar prácticas internas.

Los "cinco porqués" aplicados a nivel sistémico

La técnica de los cinco porqués, popularizada por Toyota, funciona también para diagnóstico organizacional, pero hay que aplicarla con cuidado.

Mal uso:

• ¿Por qué el equipo no cumple plazos? Porque no estiman bien.
• ¿Por qué no estiman bien? Porque no tienen experiencia.
• ¿Por qué no tienen experiencia? Porque son juniors.

Este tipo de análisis culpabiliza hacia abajo y se detiene antes de encontrar la estructura.

Buen uso:

• ¿Por qué el equipo no cumple plazos? Porque aparecen tareas imprevistas.
• ¿Por qué aparecen tareas imprevistas? Porque los stakeholders piden cambios a mitad de sprint.
• ¿Por qué piden cambios a mitad de sprint? Porque no participan en planificación.
• ¿Por qué no participan en planificación? Porque tienen reuniones ejecutivas los lunes que coinciden.
• ¿Por qué no se coordina la agenda? Porque cada área funciona con calendarios independientes.

Ahora sí llegaste a algo estructural: silos organizacionales que no coordinan.

El truco está en seguir preguntando hasta que la respuesta señale una norma, un incentivo o una estructura organizacional, no una deficiencia individual.

Análisis de congruencia organizacional

Nadler y Tushman propusieron en los años 80 un modelo de diagnóstico que sigue siendo útil: analizar la congruencia entre cuatro componentes de una organización:

1. Trabajo: Qué se debe hacer (objetivos, tareas, flujos)
2. Personas: Quién lo hace (competencias, cultura, incentivos)
3. Estructura formal: Cómo está organizado (equipos, jerarquías, procesos)
4. Estructura informal: Cómo funciona realmente (relaciones, comunicación, poder)

Las disfunciones suelen estar en las incongruencias entre estos elementos. Por ejemplo:

• El trabajo requiere colaboración multidisciplinaria, pero la estructura formal organiza por especialidad.
• Las personas tienen incentivos individuales, pero el trabajo requiere resultados colectivos.
• La estructura informal (quién consulta a quién) contradice la estructura formal (quién reporta a quién).

Identificar estas incongruencias ayuda a diagnosticar por qué ciertos problemas persisten: porque el sistema está fundamentalmente desalineado.

Arquitectura de la comunicación: la ley de Conway

Melvin Conway formuló en 1968 una observación que sigue vigente: "Las organizaciones diseñan sistemas que replican su estructura de comunicación". Si tu empresa tiene equipos de frontend, backend, base de datos y QA separados, probablemente termine con un sistema en capas que refleja esa separación.

Matthew Skelton y Manuel Pais profundizan esto en Team Topologies (2019): las estructuras de equipo determinan qué tipo de software es posible construir. Si quieres arquitecturas desacopladas, necesitas equipos autónomos. Si mantienes dependencias estructurales entre equipos, tendrás dependencias técnicas.

Cuando un equipo tiene problemas recurrentes de integración, coordinación o dependencias técnicas, vale la pena preguntarse: ¿es un problema técnico o es el reflejo inevitable de cómo está organizada la empresa?

A veces la solución no es mejorar prácticas de ingeniería. Es rediseñar equipos.

Cómo llevar esto a conversaciones reales (sin que te despidan)

Identificar estructuras disfuncionales es una cosa. Generar conversaciones que lleven a cambiarlas es otra.

Enmarcar hallazgos como oportunidades, no acusaciones

Nadie quiere oír "el problema es que ustedes organizaron esto mal". Funciona mejor: "Detectamos un patrón: cuando X ocurre, siempre resulta en Y. ¿Qué pasaría si probamos Z?"

La diferencia no es solo semántica. Es estratégica. Presentas datos, identificas un patrón, propones un experimento. No señalas culpables.

Usar métricas que hagan evidente el costo sistémico

Como mencionamos antes, medir tiempos de espera, bloqueos, retrabajos, permite objetivar la conversación. Ya no es "creo que tenemos un problema". Es "el 40% del tiempo del equipo se gasta esperando aprobaciones".

El Flow Framework de Mik Kersten (Project to Product, 2018) propone medir cuatro métricas clave:

• Flow Velocity: Cuánto valor se entrega
• Flow Time: Cuánto tarda en entregarse
• Flow Efficiency: Qué proporción del tiempo es trabajo activo vs. espera
• Flow Load: Cuánto trabajo hay en progreso

Estas métricas hacen visible el impacto de estructuras que generan bloqueos, dependencias o multitarea excesiva.

Buscar aliados en diferentes niveles

El cambio sistémico rara vez lo impulsa una sola persona. Requiere coaliciones: gente de diferentes áreas que ve el mismo problema y tiene incentivos para abordarlo.

Un Scrum Master solo puede visibilizar. Un Product Owner puede priorizar soluciones. Un líder de ingeniería puede autorizar cambios. Un ejecutivo puede modificar incentivos. Necesitas a varios de estos actores alineados para cambiar estructuras.

Esto es lo que Kotter llama "urgencia genuina": no pánico, sino convergencia de actores clave que reconocen que el statu quo tiene costos intolerables.

Saber cuándo parar

No todas las batallas se pueden ganar. A veces has visibilizado la estructura, has propuesto alternativas, has conseguido aliados, y aun así la organización decide no cambiar. Porque el costo político es demasiado alto, porque hay prioridades contradictorias, porque simplemente no es el momento.

En esos casos, insistir puede convertirse en una forma de autodestrucción profesional. No estamos diciendo que abandones. Estamos diciendo que elijas conscientemente dónde inviertes tu energía sabiendo que no todos los sistemas quieren ser transformados.

Ver el sistema no te hace responsable de arreglarlo solo

Uno de los peligros del pensamiento sistémico es asumir que, porque ahora ves la estructura completa, deberías poder resolverla. Pero eso sería caer en otra trampa: la fantasía del superhéroe que arregla organizaciones.

Los sistemas complejos no los cambia una sola persona. Los cambian coaliciones, presión externa, crisis que hacen insostenible el statu quo, liderazgo que decide apostar por algo diferente.

Tu trabajo, si eres Scrum Master, Agile Coach, Product Owner o líder de equipo, no es arreglar toda la organización. Es:

• Hacer visible lo que está generando disfunciones recurrentes
• Proteger a tu equipo de las partes más tóxicas del sistema mientras trabajas en cambiarlas
• Experimentar con alternativas en los espacios donde tienes influencia
• Construir alianzas con quienes tienen poder para cambiar estructuras
• Saber cuándo escalar un problema y cuándo reconocer que está fuera de tu alcance

Y, quizá lo más importante: saber cuándo el sistema no va a cambiar y tú necesitas salir de él antes de que te destruya.

Porque el pensamiento sistémico también incluye reconocer que tú eres parte del sistema. Y que cuidarte es, a veces, la única intervención estratégica posible.

Bibliografía

Ackoff, R. L. (2010). Systems Thinking for Curious Managers. Triarchy Press. ISBN: 978-0956263865

Argyris, C. (1996). Organizational Learning II: Theory, Method, and Practice. Addison-Wesley. ISBN: 978-0201629831

DORA (2023). Accelerate State of DevOps Report 2023. Google Cloud. https://cloud.google.com/devops/state-of-devops

Helfand, H. (2020). Dynamic Reteaming: The Art and Wisdom of Changing Teams. O'Reilly Media. ISBN: 978-1492061298

Kersten, M. (2018). Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press. ISBN: 978-1942788393

Kim, G. (2019). The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data. IT Revolution Press. ISBN: 978-1942788768

Kotter, J. P. (2014). Accelerate: Building Strategic Agility for a Faster-Moving World. Harvard Business Review Press. ISBN: 978-1625271747

Meadows, D. H. (2008). Thinking in Systems: A Primer. Chelsea Green Publishing. ISBN: 978-1603580557

Meadows, D. H. (1999). Leverage Points: Places to Intervene in a System. The Sustainability Institute. http://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/

Schein, E. H. (2013). Humble Inquiry: The Gentle Art of Asking Instead of Telling. Berrett-Koehler Publishers. ISBN: 978-1609949815

Senge, P. M. (1990). The Fifth Discipline: The Art & Practice of The Learning Organization. Doubleday. ISBN: 978-0385517256

Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press. ISBN: 978-1942788812

Weinberg, G. M. (1992). Quality Software Management, Vol. 1: Systems Thinking. Dorset House Publishing. ISBN: 978-0932633224

Club Agile: ¿Quieres profundizar en diagnóstico organizacional y pensamiento sistémico aplicado a transformaciones ágiles? Únete a Club Agile, donde compartimos casos reales, herramientas de análisis y conversaciones sobre qué hacer cuando identificas problemas estructurales. Accede aquí.