Primero la pausa

El rol de quien lidera no es dar la respuesta. Es formular la pregunta que conecta la idea con la realidad.

Casi un mes de trabajo. El producto era técnicamente sólido. Terminó desechado.

Entender realmente qué había pasado no fue algo que comprendiera de inmediato; me tomó tiempo.

Trabajaba entonces como científico de datos; estábamos preparando un producto para un cliente que quería que le ayudáramos a resolver un problema. Le propusimos una solución de análisis de datos avanzada, con la cual iba a poder tomar decisiones estratégicas más rápido y mejor.

Me pasaron un extracto de su información y armé el producto; técnicamente, estaba muy sólido. El día de la presentación, todos salimos contentos: el cliente, porque podía decir que trabajaba con la herramienta de moda, y nosotros, porque la habíamos desarrollado. Pero entonces vino el proceso de implementación y nos dimos cuenta de que ese producto era inviable. Semanas de trabajo desechadas.

El problema no fue técnico. Todo el desarrollo estuvo de acuerdo con el plan. Fue algo más. Algo más difícil de encontrar: nadie, en ningún momento del proyecto, se detuvo a hacer las preguntas que importaban antes de arrancar.

Pero justo ahí residía el problema. La emoción no responde a ninguna de las preguntas que importan.

El producto era inviable no porque fuera malo, sino porque nos dimos cuenta tarde de que el equipo del cliente no contaba con la infraestructura necesaria para operarlo ni para mantenerlo en funcionamiento. Y el problema más importante era otro: no tenía suficiente visibilidad sobre sus propios procesos para que lo que el producto arrojaba realmente ayudara a tomar decisiones. Habíamos construido algo sofisticado sobre una base que no estaba preparada para soportarlo.

Dimos marcha atrás. Entendimos qué necesitaban realmente: flujos de información, una estructura digital y tableros para tener visibilidad sobre su operación. Algo más simple, más aterrizado. Eso sí funcionó. Y el resto del proyecto se fue construyendo, ajustando y mejorando desde entonces.

Lo que cambió no fue la capacidad técnica ni el esfuerzo. Lo que cambió fue el proceso de pensamiento antes de arrancar: parar, entender el contexto real, preguntarse si la solución que tienes en mente es la que mejor le sirve a quien la va a recibir. Eso es lo que no hicimos al principio y lo que, desde entonces, me propuse hacer de manera distinta.

Lo que ese error me dejó

La lección no fue técnica. Fue sobre el momento que casi siempre pasamos por alto: la pausa antes de arrancar.

Lo que dificulta detenerse es que la emoción se percibe como una validación. Cuando todos están de acuerdo con una idea, cuando el cliente asiente y el equipo se entusiasma, parece que eso confirma que vas por el camino correcto. La energía en la sala se interpreta como una señal de que algo es bueno. Pero la emoción no responde a ninguna de las preguntas que importan.

¿Está el equipo listo para adoptar esto? ¿Tienen las habilidades para mantenerlo? ¿Tienen la infraestructura para que funcione en su operación real, no solo en una presentación? ¿Saben qué va a cambiar en su día a día si esto sale bien y qué pasa si algo falla en el camino?

Ninguna de esas preguntas es complicada. Pero hacerlas requiere algo que va en contra del impulso natural cuando hay entusiasmo: la pausa. Y pausar se siente como frenar el momentum, como ser el aguafiestas en la sala.

Ese no fue el único error de ese tipo en mi carrera. Fue uno de varios que me fueron construyendo un criterio que no venía de ningún curso, sino de haberme equivocado de formas específicas y de haber tenido que asumir las consecuencias. Cada error dejó algo concreto: una pregunta que, desde entonces, me hago antes de arrancar cualquier proyecto, adoptar cualquier herramienta o aceptar cualquier propuesta que suene bien en papel.

Cómo funciona ese criterio en la práctica

Cuando alguien en un equipo llega con una idea nueva, una herramienta que vio en otra empresa, una forma de trabajar que leyó en algún lado, una sugerencia que suena bien, la reacción natural es evaluar la idea en sí: ¿es buena o mala? Pero esa no es la pregunta que importa. La pregunta es otra: ¿tiene sentido para lo que tenemos hoy?

Esa distinción parece sutil, pero cambia todo. Una idea puede ser excelente en abstracto y completamente inviable en el contexto en el que se quiere implementar. No por falta de calidad, sino porque el equipo no cuenta con la infraestructura, las habilidades o la visibilidad necesarias para adoptarla y ponerla en marcha.

El rol de quien lidera no es tener la respuesta. Es hacer la pregunta que obliga a conectar la idea con la realidad. ¿Por qué crees que esto tiene sentido con nuestros procesos actuales? ¿Tenemos lo necesario para mantenerlo en funcionamiento? ¿Sabemos cómo vamos a medir si funcionó?

Esas preguntas no son para bloquear. Son para activar un proceso de pensamiento que casi nunca se activa: el de conectar lo que suena bien con lo que realmente existe.

Hay algo importante aquí que tiene que ver con los límites del liderazgo. Quien dirige no necesariamente sabe más de ventas que el equipo de ventas, ni más de operación que quien la vive todos los días. Lo que sí tiene es experiencia transversal: ha visto suficientes proyectos funcionar y caerse como para leer una idea nueva y saber rápido si tiene pies o no. Esa experiencia no sirve para dar la respuesta correcta. Sirve para formular la pregunta correcta. Son dos cosas muy distintas.

Cuando el líder entra con la respuesta, tapa el conocimiento que el equipo tiene y el que él no. Cuando entra con la pregunta correcta, el equipo conecta la idea con su propia realidad y regresa con algo mejor. No con la idea original a medias, sino con una versión más aterrizada, más conectada con lo que realmente tienen enfrente. Y esa versión tiene más valor que cualquier respuesta impuesta desde arriba, porque viene de quien conoce el área de verdad.

No es un proceso infalible. Pero obliga a pensar antes de actuar y eso solo ya cambia la calidad de lo que se construye.

Por qué el proceso importa tanto como la idea

Ningún proceso de este tipo es infalible. Habrá ideas que pasen el filtro y no funcionen. Y habrá otras que hoy no tienen cómo vivir, no porque sean malas, sino porque las condiciones aún no están listas. Esas se guardan, no se desechan.

Lo que sí cambia es lo que sucede después de cada decisión. Documentar no es llenar un formato que nadie volverá a leer. Es para registrar lo que se hizo, lo que se esperaba y lo que realmente ocurrió. Los errores, las victorias, los ajustes sobre la marcha. Todo. Para eso existen herramientas como un CRM o un tablero de seguimiento: no como vitrina tecnológica, sino como la memoria de lo que el equipo ha hecho y aprendido.

Cuando esa memoria existe, el siguiente reto no empieza desde cero. Empieza por saber qué se ha probado, qué funcionó y qué no. Y desde ahí se mejora.

Moverse rápido sin ese proceso no es agilidad. Es gastar esfuerzo y dinero en algo que, al final, no deja nada: ni el resultado ni el aprendizaje.