Recuerdo hace tiempo estar en una conversación que duró casi dos horas. Había gente de tres equipos distintos, cada uno con su perspectiva, su frustración y su versión de lo que estaba pasando. El tema era un problema que llevaba meses sin resolverse. Todos sabían que era urgente. Todos tenían opiniones. Pero no avanzamos nada.
Al salir de esa reunión me quedé pensando en algo que tenía dando vueltas en la cabeza desde que vi la serie de Netflix “El problema de los tres cuerpos”. La serie, por cierto, empezó muy bien pero terminó bastante mal, por lo que no es una recomendación 😅. Pero el concepto detrás del nombre me dejó pensando.
Y con esto no estoy hablando de aliens ni de civilizaciones extraterrestres. Estoy hablando de un concepto de la física que, sin querer, explica perfectamente por qué tantos equipos se quedan pegados en discusiones eternas sin llegar a ningún lado.
El problema de los tres cuerpos
En 1687, Isaac Newton formuló las leyes de la gravitación universal y mostró que se podía predecir con precisión el movimiento de dos cuerpos que interactúan entre sí. Dos planetas, dos estrellas, lo que sea. Si tienes dos cuerpos y conoces sus condiciones iniciales, puedes calcular exactamente cómo se van a comportar en el futuro.
Pero en 1889, Henri Poincaré demostró que cuando metes un tercer cuerpo al sistema, todo se vuelve un caos. Las interacciones entre los tres objetos se influencian mutuamente de formas tan complejas que el sistema se vuelve impredecible. No hay fórmula que valga. No hay solución general. El problema, literalmente, no tiene solución.
No es que sea difícil. No es que falte tecnología o cálculos más avanzados. Es que es matemáticamente imposible predecir el comportamiento de tres o más cuerpos que interactúan entre sí al mismo tiempo.
Y eso es exactamente lo que pasa en el trabajo mucho más seguido de lo que creemos.
La trampa en la que todos caemos
Piensa en la última vez que estuviste metido en una discusión sobre un problema complejo en donde trabajas. Uno de esos donde hay múltiples frentes abiertos, diferentes equipos involucrados, varias soluciones posibles y nadie se pone de acuerdo.
Lo más probable es que en esa conversación estuvieran pasando varias cosas al mismo tiempo. Alguien proponía una solución y otro la tumbaba con un argumento válido desde otra perspectiva. Alguien más planteaba una alternativa y eso abría un frente nuevo que nadie había considerado. Y así, cada intento de avanzar generaba una nueva razón para no hacerlo.
Eso es un problema de tres o más cuerpos.
Variables distintas, cada una con su propia complejidad, chocando entre sí de formas que hacen imposible llegar a una respuesta clara. Porque cada vez que alguien propone algo, otro salta con una objeción legítima desde otro ángulo. Y cuando intentan resolver esa objeción, aparece otra. Y otra. Y otra.
Es un ciclo que no lleva a ningún lado. Y mientras más gente se mete a la conversación, más caótico se pone. Igual que en la física, meter más variables al sistema no lo simplifica. Lo complica.
Lo peor es que muchos equipos se quedan atrapados en ese ciclo durante meses. El problema sigue creciendo, los resultados se siguen yendo al piso, la frustración sube y las conversaciones se repiten una y otra vez sin que nada cambie. Y no es porque la gente sea tonta o porque no les importe. Es porque están tratando de resolver un problema que, tal como lo están planteando, no tiene solución.
Un ejemplo que se siente familiar
Imagina una compañía que en sus primeros años construyó un componente de login para que sus usuarios pudieran entrar a las diferentes soluciones que ofrecía. Al principio funcionaba bien. Era sencillo, hacía lo que tenía que hacer y nadie se preocupaba mucho por él.
El problema es que se construyó en una etapa muy temprana de la compañía. Nunca se definió un dueño claro. El equipo de desarrollo original se encargaba de mantenerlo, pero con el tiempo esa gente fue rotando, el conocimiento se fue perdiendo y nunca existió un gobierno real sobre ese componente. Nadie decidió formalmente quién era el responsable, qué se podía tocar, qué no y bajo qué reglas.
Con el tiempo, diferentes equipos empezaron a meterle mano por su cuenta. Unos le agregaban cosas, otros le cambiaban partes, cada uno con su propia lógica y sin coordinarse con nadie. El componente se fue convirtiendo en un Frankenstein. Con el tiempo, empezó a fallar. Y esas fallas empezaron a pegarle a los resultados de varios equipos de producto que dependían de él.
Ahí arrancaron las conversaciones. Y ahí se armó un problema de los tres cuerpos.
Por un lado, los equipos de producto levantaban la mano. Sus resultados estaban cayendo porque el componente no servía bien. Necesitaban que se resolviera ya.
Por otro lado, el equipo de componentes transversales decía que ellos no habían construido ese componente, que no tenían los recursos para trabajar en eso, y que entonces los equipos de producto deberían tomarlo si querían resolver el problema.
Pero los equipos de producto respondían que eso no era un componente de producto. Era transversal. Así que el dueño natural debería ser el equipo de componentes transversales.
Y mientras tanto, el equipo técnico tenía su propia pelea. Unos decían que era un tema de refactor. Otros decían que lo mejor era “darle cariño” y arreglarlo. Y otros más sugerían que era más fácil contratar una solución de un tercero y dejar de pelear con eso.
Todas estas conversaciones pasaban al mismo tiempo. Mezcladas. Sin separación. Y ninguna avanzaba porque cada intento de resolver un frente chocaba con los otros dos.
El resultado fue casi un año de discusiones sin llegar a nada. El problema seguía creciendo. Los resultados seguían cayendo. Y nadie hacía nada al respecto porque nadie se hacía responsable, no se sabía cuál era la solución correcta y tampoco había recursos asignados para resolverlo.
Un problema que parecía imposible de resolver. Porque lo estaban tratando como un problema de tres cuerpos.
Lo que se debió hacer desde el principio
Desde el momento en que esta situación se identificó, alguien debió haber reconocido que no era un solo problema. Eran tres problemas distintos, enredados entre sí, haciéndose pasar por uno solo. Y mientras siguieran tratándolos como uno, jamás iban a llegar a una respuesta.
La solución era aislarlos. Separar cada variable y entenderla por sí sola. Porque cuando aíslas un cuerpo del sistema, su comportamiento se vuelve predecible. Y cuando un problema es predecible, se puede resolver más fácil.
Problema 1. ¿Cómo se resuelve técnicamente?
¿Se hace un refactor? ¿Se arregla lo que hay? ¿Se contrata algo de un tercero? Las tres opciones estaban en la mesa, cada una con sus argumentos. Pero este problema le tocaba resolverlo a la gente que sabe de tecnología.
Así que los desarrolladores y los tech leads se sentaron a analizarlo. Después de unos días de estudiarlo, llegaron a una conclusión clara. Lo mejor era hacer un refactor. Era una solución core del negocio. Contratarla significaba perder control sobre algo crítico. Arreglarla por encima era seguir poniendo curitas sobre un problema estructural. La respuesta era reconstruirlo bien, cumpliendo todas las necesidades del negocio.
Primer problema resuelto.
Problema 2. ¿Quién es el dueño?
Acá es donde la conversación siempre se enredaba porque el equipo de componentes transversales decía que no tenía recursos, y por eso los equipos de producto debían tomarlo. Pero eso es mezclar dos problemas distintos.
Si aislamos la pregunta y la miramos sin pensar en recursos ni en la solución técnica, la respuesta es obvia. Es un componente transversal. Por definición, su dueño es el equipo de componentes transversales. Con recursos o sin recursos, la responsabilidad es de ellos. Los equipos de producto no deberían cargar con un componente que no es parte de sus productos. No hay vuelta que darle.
Segundo problema resuelto.
Problema 3. ¿De dónde salen los recursos?
El equipo de componentes transversales no tenía la gente para trabajar en esto. Estaban metidos en otras iniciativas estratégicas. Entonces, ¿de dónde sale la capacidad?
Este es el problema más complejo de los tres, porque requiere conversaciones difíciles. Hay que entender cuánto le está costando a la compañía no resolver esto. Hay que estimar cuántas personas se necesitan. Hay que evaluar si se puede resolver despriorizando otras cosas. Y hay que medir el apetito real de la organización por resolverlo.
Acá hay varios caminos posibles. La compañía podría decidir de manera consciente que no tiene los recursos y que hay cosas más importantes que hacer. Aceptar el problema tal como está y convivir con él. También podría despriorizar otras iniciativas para liberar capacidad. O incluso invertir recursos adicionales de su propio bolsillo para resolverlo. Cualquiera de esas opciones es válida siempre y cuando sea intencional. Lo que no se puede hacer es dejar los otros dos problemas resueltos y este inconcluso, porque eso tumbaría absolutamente todo. La clave está en ser conscientes, definir cuál es el camino que se va a tomar y que todos estén alineados.
En este caso, después de cuantificar el impacto y compararlo con las iniciativas que tenía priorizadas el equipo de componentes transversales, se dieron cuenta de que sí podían hacer cambios en las prioridades. Había un grupo de iniciativas cuyo impacto era menor que el costo de seguir sin resolver este problema. La decisión fue despriorizar temporalmente esas iniciativas para liberar capacidad, ejecutar el refactor, recuperar los resultados y luego retomar lo que se había pausado.
Tercer problema resuelto.
Y así, un problema que pareció imposible durante casi un año se resolvió en cuestión de semanas. No porque apareciera alguien más inteligente con una solución mágica. Sino porque dejaron de tratarlo como un problema de tres cuerpos y empezaron a tratarlo como tres problemas independientes.
Todos quedaron alineados. Todos sabían qué se iba a hacer, quién era el responsable, de dónde salían los recursos y cuándo deberían empezar a ver resultados. Sin más conversaciones circulares. Sin más frustración. Sin más parálisis.
Cómo abordar problemas complejos
Lo que acabamos de ver pasa todo el tiempo. Y no siempre son tres problemas. A veces son dos. A veces son cinco. A veces son más. Pero el ejercicio es prácticamente el mismo.
Paso 1: Identifica cuántos problemas tienes
Lo primero es caer en cuenta de que probablemente no estás frente a un solo problema. Pregúntate cuántas variables o dimensiones distintas están en juego. ¿Es un tema técnico? ¿De ownership? ¿De recursos? ¿De priorización? ¿De alineación estratégica? Cada una de esas dimensiones es un problema independiente. Tu primer trabajo es identificarlas y separarlas.
Paso 2: Aísla cada problema
Una vez que tienes claros los problemas, sepáralos. Literalmente. No dejes que la discusión de uno contamine la del otro. Cada problema tiene que analizarse por sí solo, sin las restricciones o condiciones de los demás. Si estás definiendo quién debería ser el dueño, no pienses en los recursos. Si estás evaluando la solución técnica, no pienses en quién la va a ejecutar. El momento de conectar todo llega después. Primero, entiende cada pieza por separado.
Paso 3: Entiende cada problema antes de buscar soluciones
Este paso es donde la mayoría la embarra. Antes de pensar en qué hacer, necesitas tener claridad absoluta sobre qué estás tratando de resolver. ¿Cuál es el problema real? ¿Cómo se ve el éxito al resolverlo? Si no tienes esto claro, cualquier solución que propongas va a ser un tiro al aire.
Paso 4: Pon todas las opciones en la mesa
Cuando ya entiendes el problema, es momento de explorar soluciones. Y acá hay dos trampas comunes en las que no puedes caer.
La primera es creer que ya sabes la respuesta. Nadie se las sabe todas. La persona que llega diciendo “esto se resuelve así” sin haber mirado las opciones, normalmente está resolviendo el problema que quiere resolver, no el que necesita resolver.
La segunda es pensar en blanco y negro. La gente tiende a ver dos opciones extremas. O hacemos esto, o no hacemos nada. Pero la realidad siempre tiene matices. Entre esas dos opciones de esquina hay un montón de combinaciones, de caminos intermedios, de versiones posibles. Todas merecen estar en la mesa.
Incluso no hacer nada. Dejar las cosas como están también es una opción válida que hay que evaluar. No siempre es la mejor, pero es clave entenderla. Porque no tomar una decisión también es tomar una decisión. Es decidir que todo siga igual. Y mucha gente no es consciente de eso.
Paso 5: Analiza con pros y contras
Para cada opción, identifica las consecuencias de tomarla. ¿Qué ganas? ¿Qué pierdes? ¿Qué riesgos asumes? Este análisis no tiene que ser perfecto, pero sí tiene que ser honesto. No puedes maquillar una opción para que se vea mejor solo porque es la que te gusta.
Paso 6: Recomienda y decide
A partir de ese análisis, el equipo que está evaluando el problema, que deberían ser los que más saben del tema, plantea una recomendación. No una opinión. Una recomendación con fundamento. Esa recomendación se lleva a los líderes y stakeholders, se discute y se toma una decisión.
Paso 7: Repite por cada problema y ejecuta
Repite este proceso por cada uno de los problemas que identificaste al principio. Y cuando tengas una decisión para cada uno, ya tienes el mapa completo. Socialízalo, alinea a los equipos y arranca a ejecutar.
La humildad de no sabérselas todas
Si algo he aprendido con los años es que el trabajo de un buen líder o de un buen profesional no es tener todas las respuestas. Eso es pura 💩.
Las cosas cambian demasiado rápido. La tecnología cambia. La gente cambia. El mercado cambia. Rara vez los años de experiencia te dan la certeza absoluta de saber qué decisión tomar en cada momento. Y la persona que actúa como si la tuviera normalmente termina resolviendo parte del problema, resolviéndolo mal o simplemente tomando una decisión a dedo que después les explota a todos en la cara.
La gente más inteligente que conozco no es la que se las sabe todas. Es la que sabe que no sabe. Son los que entienden que resolver problemas complejos no se trata de llegar con la respuesta mágica, sino de tener la disciplina y la curiosidad para descomponer el problema, entender cada pieza, mirar las opciones y tomar decisiones informadas. Una a una.
Eso no significa que todo va a salir perfecto. Va a haber trade-offs. Va a tocar despriorizar algo para priorizar otra cosa. Va a haber momentos en los que el éxito no se alcance al 100% y toque quedarse en un punto intermedio. Eso es completamente normal.
Lo importante no es tener la respuesta perfecta. Lo importante es tener un proceso estructurado para encontrar la mejor respuesta posible. Y los mejores no son los que encuentra soluciones a problemas imposibles. Son los que tiene la humildad de reconocer que no se trata de eso. Se trata de romper los problemas en pedazos, abordar cada uno con curiosidad y rigor, y armar la solución pieza por pieza.
De esta manera, la próxima vez que te enfrentes a una situación así, para un momento. Mira bien lo que tienes enfrente. Pregúntate si estás tratando de resolver un solo problema o si en realidad son varios haciéndose pasar por uno. Y si es así, recuerda lo que la física nos enseñó hace más de un siglo.
Un problema de tres o más cuerpos no tiene solución.
Sepáralos. Entiende cada uno. Resuélvelos uno a uno.
¡Gracias por leer! Puedes seguirme en LinkedIn, donde semanalmente comparto contenido sobre Product Management y liderazgo.
Que tengas un buen día 🙏
Rómulo
P.D. Si te gustó esta newsletter, dale “me gusta” 💙**, compártela y, si aún no lo has hecho, considera suscribirte.**
Excelente, esa solución se asimila al viejo dicho "El tigre toca matarlo a pedacitos" Pero acá se desarrolla con toda la estructura. Genial Rómulo , gracias pdt me suena el caso