skip to content

Construir evidencia antes del consenso

7 min read

El falso binario no es pedir permiso o pedir perdón, sino construir evidencia antes de que exista consenso. Cuándo esa jugada funciona, cuándo se vuelve deuda de gobernanza, y cómo pasar de hacker interno a arquitecto institucional.

Hay una pregunta que todo profesional técnico termina enfrentando, casi siempre mal formulada: ¿pides permiso o pides perdón? Elegir cualquiera de los dos lados ya es haber aceptado un marco equivocado. Pedir permiso de más frena cualquier iniciativa que dependa de evidencia que todavía no existe —nadie autoriza con confianza lo que no puede evaluar—. Pedir perdón de más es apostar a que el resultado absuelva el método, y el ensayo anterior de esta serie ya mostró el límite de esa apuesta: la organización perdona la desviación cuando sale bien, pero perdonar no es autorizar, y confundir las dos cosas es la forma más rápida de acumular una deuda que en algún momento vence.

Hay una tercera postura, menos citable que las otras dos, y es la que de verdad sostiene una carrera técnica en el tiempo.

No prefiero pedir permiso ni pedir perdón; prefiero construir evidencia antes de que exista consenso.

No es imprudencia: la imprudencia actúa sin medir el terreno que pisa. Tampoco es obediencia: la obediencia espera un consenso que, en la mayoría de las decisiones que importan, no llega antes de que la ventana se cierre. Es una tercera cosa, más aburrida y más útil que ambas —prototipar la realidad que se está argumentando, en lugar de argumentarla en abstracto—. No se convence a un comité de que una escuela de negocios interna resolvería la adopción de una herramienta de datos con una diapositiva y una proyección. Se construye la escuela, se mide la adopción, y entonces el argumento deja de ser una hipótesis: es una cifra que ya ocurrió.

Las tres condiciones que hacen viable la jugada

Construir evidencia antes del consenso no es una heurística que se pueda aplicar siempre ni en cualquier terreno. Es una jugada de beneficio alto y riesgo condicional, y ese riesgo se administra reconociendo, antes de actuar, si se cumplen a la vez tres condiciones.

Riesgo técnico bajo. Si el prototipo falla, la falla tiene que quedar contenida: no puede tocar un sistema del que dependa la operación crítica, ni un dato que otra área ya esté usando para decidir. Un piloto que puede apagarse sin dejar cicatriz es un experimento. Uno que no puede apagarse sin romper algo es una apuesta disfrazada de experimento.

Beneficio visible rápido. La evidencia tiene que producirse antes de que alguien pregunte por qué se está produciendo. Si el resultado tarda meses en manifestarse, la ventana de “esto ya se resolvió, aquí está el dato” se cierra, y lo que queda es simplemente una decisión no autorizada sin nada todavía que la respalde.

El jefe puede apropiarse del éxito sin quedar expuesto. Esta es la condición que casi siempre se omite, y es la que de verdad decide si la jugada sobrevive. Un superior que patrocina —aunque sea tácitamente, aunque sea con la ambigüedad cómoda de “adelante, pero bajo tu cuenta”— necesita poder presentar el resultado como suyo si sale bien, sin que su nombre quede ligado al riesgo si sale mal. Si esa salida no existe, no hay patrocinio real; hay una persona sola sosteniendo una decisión que la organización todavía no ha decidido compartir.

Fuera de estas tres condiciones, la misma jugada —el mismo prototipo, el mismo entusiasmo, la misma convicción de que “una vez que lo vean, lo van a querer”— quema. Y conviene decirlo sin rodeos porque es la parte que la narrativa del éxito tiende a borrar: reconocer que una de las tres falta es trabajo que se hace antes de construir, no una lectura retrospectiva después de que algo salió mal. Riesgo técnico alto sin beneficio rápido es simplemente riesgo. Beneficio rápido sin manera de que el jefe se lo apropie deja al autor solo frente a la pregunta de quién autorizó esto. Cualquiera de las tres ausente convierte la evidencia que se iba a construir en la prueba que se usará para escribir el reporte de incidente.

De hacker interno a arquitecto institucional

Supongamos que las tres condiciones se cumplieron y el prototipo funcionó. Aquí es donde la mayoría de las carreras técnicas se estancan, porque tratan el éxito como el final de la historia en lugar de como el inicio de una obligación distinta.

Un prototipo que prende sin autorización formal —por bien que funcione— deja detrás una vulnerabilidad institucional, no solo un logro personal. Corre sin dueño formal, sin presupuesto asignado, sin una decisión explícita de a qué área pertenece cuando la persona que lo construyó cambie de rol o se vaya. Mientras nadie lo cuestione, es un activo. El día que alguien pregunte “¿quién es responsable de esto?” y la respuesta sea “nadie, técnicamente”, el mismo activo se convierte en el problema que alguien más tiene que resolver bajo presión.

Ese es el sentido preciso en el que el éxito sin gobernanza es deuda: no una metáfora, sino la misma estructura que una deuda técnica —algo que funciona hoy porque nadie ha cobrado todavía el costo de no haberlo formalizado—. Y como toda deuda, tiene una fecha en la que alguien la cobra: una auditoría, un cambio de liderazgo, un incidente que obliga a preguntar quién aprobó qué. La jugada de operar sin gobernanza es defendible como origen. Es indefendible como estado permanente.

El movimiento que separa a quien tuvo una buena idea de quien construye una carrera es formalizar antes de que la deuda venza, no después. Eso significa convertir el prototipo en programa: nombrar áreas dueñas, definir presupuesto, escribir el proceso que debió existir desde el principio y que ahora existe porque el prototipo demostró que valía la pena escribirlo. El arquitecto institucional no es el hacker interno con más experiencia. Es el hacker interno que entendió que el prototipo que no se institucionaliza tiene fecha de caducidad, y que esa fecha la pone otra persona si uno no la pone primero.

La narrativa correcta hacia arriba

El mismo hecho se puede contar de dos maneras, y la diferencia entre ambas no es cosmética: decide si la conversación que sigue es sobre gobernanza o sobre disciplina.

La narrativa que quema es “me salté el proceso porque el proceso era lento”. Es honesta, y es también la que menos sirve, porque coloca al interlocutor en la posición de tener que decidir si sanciona o si deja pasar una infracción —y esa decisión, tomada bajo esos términos, rara vez termina bien para quien la provocó.

La narrativa que funciona es distinta, y no es una manipulación del lenguaje: es una descripción más precisa de lo que realmente ocurrió. “Esto fue un piloto de adopción, acotado y reversible, que ya generó evidencia. Ahora propongo formalizarlo como programa, con las áreas dueñas correspondientes —formación, comercial, datos— definiendo presupuesto y responsables.” El hecho no cambió. Lo que cambió es que ahora se presenta como lo que efectivamente fue: un prototipo diseñado para producir evidencia rápido y con riesgo contenido, no una transgresión que hay que perdonar. La primera narrativa pide indulgencia. La segunda pide una decisión de gobierno. Solo una de las dos construye autoridad.

El cierre de la serie

La primera entrega de esta serie contaba cómo una escuela de negocios interna resolvió la adopción de una herramienta de datos que, en los números, ya era correcta. Vale la pena cerrar donde esa historia abrió: el problema nunca fue construir la herramienta. Fue cerrar la brecha de credibilidad de una unidad de datos —lograr que la organización confiara en sus números y los adoptara como propios.

Ese es el punto que esta entrega, mirando el episodio desde la carrera, viene a subrayar. La evidencia que se construyó antes de que existiera consenso no valió por el dashboard que produjo. Valió porque cerró esa brecha de credibilidad, y una brecha de credibilidad cerrada es un activo que persiste incluso cuando la herramienta específica que la cerró ya se reemplazó dos veces. El dashboard es reemplazable. La autoridad que una unidad de datos gana cuando la organización deja de pedirle explicaciones y empieza a citarla como árbitro no se reemplaza tan fácil —y esa autoridad, no el código detrás de ella, es lo que efectivamente queda en la hoja de vida.

Construir evidencia antes del consenso no es un truco de carrera. Es la disciplina de saber cuándo el terreno lo permite, formalizar antes de que el éxito se vuelva pasivo sin dueño, y contar después la historia por lo que fue: no una infracción que salió bien, sino un prototipo que hizo su trabajo.