Seguramente alguna vez has experimentado cómo en un grupo de personas conversando en un espacio cerrado, — no hace falta que sean tantas — el volumen de las voces comienza a elevarse progresivamente, hasta que es imposible escuchar sin gritar directamente al oído.

No fui consciente de la dinámica detrás de este fenómeno hasta que un profesor nos lo explicó en el instituto. Ese día el profesor original se había ausentado y el profe del otro grupo que impartía su clase en el aula contigua, nos echaba un ojo para asegurarse de que no la liábamos demasiado. Evidentemente, no pasaron ni diez minutos antes de que el bullicio se escuchara en toda la planta. El profesor tuvo que venir y, tras un par de chillidos para llamar nuestra atención y que se hiciese silencio, nos explicó:

Chicos, si cada uno habla más alto para hacerse escuchar, sus compañeros harán lo mismo y seguirán subiendo el volumen hasta que todos estén gritando.

Y a continuación, nos compartió un truco sencillo para evitar esta escalada de gritos. Sigue conmigo y te lo comparto al final del artículo.

El «equipo DevOps»

Imagina una organización con una cultura DevOps poco desarrollada. Tenemos por un lado, el equipo de desarrollo de producto, y por otro, el equipo de… llámale sistemas, infraestructura, plataforma, SRE, o para exagerar el que no han entendido de que va la cultura DevOps, el equipo de DevOps. En principio, ambos equipos comparten un objetivo común como: captar el mayor número posible de clientes y hacerles upselling de tantas funcionalidades como sea posible.

El equipo de desarrollo se enfoca en lanzar nuevas funcionalidades rápidamente para atraer nuevos usuarios o retener a los ya existentes. Cada vez que logran lanzar una nueva característica, el número de usuarios crece y, con él, también la carga sobre la plataforma.

Mientras tanto, el equipo de DevOps se encarga de la infraestructura y de mantener el sistema en producción. Cada vez que el equipo de producto lanza nuevas funcionalidades y atrae más usuarios, la infraestructura sufre presión adicional. Para responder a esta demanda, DevOps opta por soluciones rápidas y atajos, como escalar verticalmente —aumentar prestaciones de la infraestructura actual— o aplicar parches apresurados, lo que permite a producto seguir lanzando nuevas características sin tener que preocuparse demasiado por las limitaciones técnicas.

Este aumento de capacidad valida que la forma de trabajar funciona e incentiva aún más al equipo de desarrollo a lanzar más y más funcionalidades, lo que a su vez vuelve a poner presión sobre la infraestructura. De este modo, ambos equipos entran en un ciclo de escalada: el equipo de desarrollo sigue lanzando nuevas funcionalidades, y el equipo de DevOps sigue aumentando la infraestructura a toda prisa para mantener el sistema a flote.

A largo plazo, este ciclo se vuelve insostenible. A medida que el sistema se vuelve más complejo y los costos de infraestructura aumentan, tanto la velocidad de desarrollo de nuevas funcionalidades como la estabilidad de la plataforma comienzan a verse comprometidas, afectando negativamente el objetivo común inicial de ambos equipos.

Escalada

Estamos ante otro de los arquetipos de sistemas descritos por Donella Meadows en Pensar en Sistemas. Esta trampa se refiere a un ciclo competitivo en el que dos o más partes intentan superarse mutuamente, generando una espiral ascendente que puede terminar siendo destructiva para todos los involucrados.

El arquetipo se manifiesta cuando los agentes dentro de un sistema compiten por ganar ventaja o por acceder a recursos limitados, lo que desencadena un ciclo de «uno más que tú». Este ciclo tiende a acumular consecuencias negativas a medida que los involucrados se ven atrapados en una carrera sin fin.

Cuando el estado de una reserva viene determinado por el afán de sobrepasar el estado de otra reserva –y viceversa–, se activa un bucle de retroalimentación reforzador que conduce al sistema a una carrera armamentística, a una carrera por la sanidad, a una campaña de desprestigio, a una escalada de ruido, de violencia. Los procesos de escalada crecen de manera exponencial y pueden llegar hasta el límite a una velocidad sorprendente. Si no se pone ningún remedio, la espiral solo se detendrá con la destrucción de uno de los dos rivales: porque el crecimiento exponencial no puede durar eternamente.

— Donella Meadows. Pensar en sistemas

La estructura de este sistema se basa en la interacción de dos bucles de equilibrio que, al competir entre sí, se refuerzan mutuamente. Debido a este comportamiento competitivo —o incluso paranoico— de los participantes, la situación oscila entre los actores mientras cada uno intenta superar al otro.

Cuando desglosas la estructura, el motivo de su crecimiento se vuelve mucho más evidente. Los dos bucles de equilibrio, que en teoría deberían equilibrarse, en realidad actúan como un solo bucle de refuerzo, lo que lleva a cada participante a una situación no deseada. Si analizáramos la media de las oscilaciones de estos bucles combinados, podríamos ver que la salud de la plataforma empeora continuamente. Dada la naturaleza exponencial de este ciclo de refuerzo, pronto alcanzaríamos puntos de no retorno debido a la deuda técnica y el aumento de complejidad.

Competencia vs colaboración

La escalada se torna más peligrosa cuando se fomenta una cultura competitiva en los equipos sin equilibrarla adecuadamente con incentivos de colaboración. Si los equipos solo compiten por cumplir sus propios objetivos sin alinearse con el resto de la organización, el ciclo puede volverse destructivo. Hemos visto casos similares cuando exploramos la trampa de perseguir el objetivo equivocado.

No obstante, con la cohesión adecuada y metas claras compartidas, la competencia bien canalizada puede transformar la escalada en algo positivo. En lugar de desencadenar una espiral destructiva, se puede convertir en una carrera hacia la mejora continua, donde los equipos, motivados tanto por competir como por colaborar, impulsen el crecimiento y la innovación de la organización de manera sostenible. Este equilibrio entre competencia y colaboración es clave para evitar caer en las trampas del sistema, tengo a medias un artículo específico sobre este tema.

Escalada de crutrés

La escalada también puede verse como una versión de la trampa de la erosión de metas, donde la espiral competitiva va en un sentido negativo, compitiendo no con otros, sino con el desempeño anterior. En lugar de un crecimiento exponencial positivo, el sistema cae en una espiral descendente en la que las metas se ajustan a la baja, erosionando la calidad o el desempeño esperado. Esto es particularmente evidente en organizaciones donde la presión para mantener la velocidad o la cantidad de lanzamientos acaba degradando la calidad de las funcionalidades o la estabilidad del sistema.

La salida

Como hemos visto, este arquetipo se convierte en una peligrosa trampa cuando se combina con otras trampas que he ido mencionando en mis artículos anteriores. Como ocurre con la mayoría de las trampas, la mejor forma de evitarlas es no haber caído en ellas en primer lugar, y para lograrlo es crucial fomentar una cultura de cohesión y de búsqueda de objetivos comunes.

En el ejemplo del equipo DevOps, una cultura DevOps correcta habría evitado caer en la trampa. Como sugiere «La primera vía de DevOps», es fundamental enfatizar el rendimiento del sistema completo en lugar del rendimiento de un silo o departamento en particular.

Para romper este ciclo de escalada, ambos equipos deben colaborar y establecer límites claros (ver Team API) y prioridades comunes, en lugar de trabajar de forma reactiva. Trabajando de forma coordinada y persiguiendo los mismos objetivos, ambos equipos podrían desarrollar soluciones escalables a largo plazo, reduciendo la reactividad.

Si ya nos encontramos atrapados en la trampa, la clave para romper el ciclo es intervenir en los bucles de retroalimentación, buscando crear bucles de equilibrio en lugar de refuerzos continuos de la competencia. Si eres parte del ciclo, una opción viable es buscar un desarme unilateral: en ocasiones, si una de las partes detiene la escalada, la otra pierde incentivos para continuar.

Si lo que llamamos equipo de DevOps, adoptara un enfoque de equipo de plataforma que provea una plataforma como servicio, podría haber ofrecido una salida efectiva para retirarse de la escalada de la infraestructura. Una técnica interesante para lograr esto es el «backpressure». En lugar de simplemente escalar infinitamente los recursos disponibles, con el «backpressure» se puede aplicar alguna de estas estrategias:

• Controlar al productor: la velocidad de producción es decidida por el consumidor, ralentizándola o acelerándola según sea necesario.

• Almacenar temporalmente: crear un buffer para manejar picos de datos entrantes de manera temporal.

• Descartar: muestrear un porcentaje de los datos entrantes para reducir la carga.

Os recomiendo este artículo donde Jay Phepls explica detalladamente esta técnica.

Cerrando

Volviendo al fenómeno de la escalada del volumen de voz, en 2019 asistí a mi primer open space, el SOSZ19. En medio del evento, me encontré con el mismo fenómeno de escalada de gritos para hacerte escuchar, lo típico en todo networking al que había asistido antes. De repente, noté que todos a mi alrededor comenzaban a levantar la mano. Extrañado, hice lo mismo y detuve mi acalorado networking. En cuestión de segundos, el silencio reinó en la sala. Un ejemplo brillante de desarme de la escalada, esta vez mediante la introducción de otra escalada, pero que utilizaba el sentido visual en lugar del auditivo.

No he sido capaz de encontrar el origen de esta técnica, creo que viene de la comunidad agile, a ver si alguien lo sabe y nos lo amplía en los comentarios.

Y respecto al truco del profesor de instituto, también aplicó la escalada, pero dándole la vuelta al objetivo. Nos explicó que si poníamos el foco en hacer lo contrario, el único límite sería que nuestro grupo no nos escuchara. Nos dijo algo como:

Qué tal si os proponéis hablar lo más bajo posible, retándoos a hablar lo más bajo que vuestro subgrupo pueda escuchar.

Voilà, funcionó! De repente pasamos a un murmullo suave y constante, el aula parecía un velatorio, que casualmente es el objetivo en un velatorio — al menos en los de mi pueblo en Cuba en aquella época.

Sin embargo, en cuanto un grupo se sale del protocolo u objetivo global, es fácil volver a caer en la escalada en la otra dirección. En realidad esto ocurre con cualquier dinámica que implique un contrato social, basta con que una masa crítica rompa el contrato para que se provoque una escalada paranóica del «yo uno más que tú».

Bonus para padres

Si ves a dos hermanos insultándose, luego pasando a los empujones, tirones de pelo y eventualmente a los golpes, ya sabes que esto no tendrá fin por sí solo. Edúcalos para que esta escalada nunca ocurra (y de paso escribe un libro sobre cómo 😉), o intervén en cuanto detectes los primeros signos.

Serie: las trampas de los sistemas complejos

Esta entrega forma parte de una serie sobre las trampas de los sistemas complejos aplicadas al desarrollo de productos:

• Elusión de las reglas y persecución del objetivo equivocado: La trampa del testing coverage.

• Desplazamiento de la carga hacia la intervención: La trampa de la adicción al parche.

• Deriva hacia el bajo rendimiento: La Trampa de la Erosión de Metas y el Síndrome de la Rana Hervida.

• Exclusión competitiva: La trampa del «rockstar developer».

• Resistencia a las políticas: La trampa de los atajos y el falso dilema entre calidad y velocidad.

• Tragedia de los recursos comunes: La tragedia del código compartido.

• Escalada: (este artículo)

Si te interesa el tema del pensamiento sistémico aplicado al desarrollo de producto, de vez en cuando organizo talleres sobre cómo usar y sacarle partido a estas herramientas. Si estás interesado en que lo imparta para tu equipo o en algún evento, escríbeme.