Cuando la historia supera a los hechos

Cuando la historia suena mejor que los hechos

Por qué un CTO no debe confundir una explicación elegante con una decisión bien tomada.

Hay una trampa bastante común en tecnología y en dirección. Cuando empieza a faltar trazabilidad, se arma una historia que cierre, porque claro, siempre es más cómodo tener una versión ordenada que aceptar que ya no estás tan seguro de qué pasó. El problema es que una narrativa retrospectiva puede hacer ver una decisión débil como si hubiera sido sólida, aunque en realidad no haya mejorado nada.

Como CTO, me he encontrado con ese patrón más veces de las que quisiera. Aparecía una iniciativa, luego salían defensores, se justificaban atajos y, con el tiempo, el equipo terminaba hablando del resultado como si hubiera sido el desenlace natural de un plan bien pensado. Pero explicar después no es lo mismo que decidir bien antes. Una cosa acomoda el relato; la otra sostiene el negocio.

Lo curioso de esto es que la defensa casi siempre se activa al primer cuestionamiento. “Aquí siempre ha funcionado así”. “No estás viendo el contexto”. “Eso en papel suena bien, pero en la operación no aplica”. Y sí, a veces hay contexto que no se ve desde afuera, pero muchas otras veces esa reacción solo protege el ego y evita revisar algo más incómodo: que la decisión no estaba tan bien sustentada como se quería contar. Si una observación se descarta únicamente porque no encaja con la versión oficial, la organización pierde la oportunidad de revisar supuestos, detectar resistencias reales y corregir errores de fondo.

Muchas empresas no se caen por falta de ideas. Se caen por exceso de justificación posterior. Se toma una decisión con información incompleta, luego se la viste de lógica, y después se la defiende como si esa lógica hubiera existido desde el arranque. Eso mata el aprendizaje, porque mezcla hecho, interpretación y deseo. Y la gobernanza también se rompe, porque al final nadie sabe con precisión qué se decidió, por qué, con qué riesgo y bajo qué restricciones.

Para un líder tecnológico, la consecuencia es bastante directa. Si una crítica externa no sirve para contrastar la realidad, el equipo deja de afinar. Si una implementación se celebra sin revisar su impacto en costes, operación o velocidad de ejecución, lo único que haces es mover la complejidad de un lado a otro. Y si el sistema premia relatos convincentes antes que trazabilidad, tarde o temprano vas a repetir los mismos errores, solo que con distinto lenguaje.

La parte incómoda es que la disciplina real consiste en reconstruir mejor los hechos. Antes de hablar de arquitectura, de IA o de inversión, hay que poder decir con claridad qué problema se intentaba resolver, qué alternativas existían, quién asumió el riesgo y qué resultado produjo realmente la decisión. Sin eso, la explicación puede sonar bien. Pero no sirve para dirigir. Y dirigir, a la larga, exige memoria precisa, criterio y la disposición de revisar lo que incomoda.