En muchas empresas, las mejores soluciones no esperan aprobación de arriba, simplemente se hacen. En este ensayo voy analizando cómo liderar en entornos donde la acción se adelanta al permiso. Y por qué ignorarlas puede costarte más que adaptarte.
Ya había escrito (de forma exploratoria) qué pasa cuando el permiso domina, ahora veamos qué ocurre cuando la acción se adelanta.
En las grandes empresas el cambio suele tener una velocidad geológica. Se anuncia algo, se aprueba en un comité, baja por la cascada corporativa y luego con suerte se ejecuta.
Cada paso tiene dueño y las áreas imponen su propia lógica política. Lograr que todo eso converse puede tardar una eternidad. Por mucho tiempo este proceso se mantuvo porque daba la impresión reconfortante de que alguien estaba a cargo, aunque en la práctica resolviera muy poco.
Matthew Stewart, en The Management Myth, decía que gran parte de la teoría de gestión funciona igual: ofrece marcos y terminología solemne que pocas veces conectan con la práctica real. Pero hoy siento que esa desconexión se ha vuelto intolerable. El sistema sigue en pie, los organigramas siguen colgados en la intranet, pero muchas personas asumieron que si algo tenía que pasar, no iba a venir de arriba.
Para entender cómo se expresa esto realmente, hay que dejar de leer las políticas oficiales y empezar a mirar la ilegalidad operativa del día a día.
Vemos a un supervisor de bodega que automatiza el envío del inventario con un script de Python que copió de un tutorial de YouTube. O a empleados procesando textos en ChatGPT desde sus celulares personales porque la red corporativa lo tiene bloqueado. Lo hacen simplemente porque funciona.
Estas decisiones nacen de una constatación silenciosa, la autorización dejó de ser una fuente legítima de acción. Cuando el proceso formal estorba más de lo que ayuda, la gente simplemente le hace el quite, simple.
Ahora, conviene detenerse aquí un segundo. Antes de declarar la muerte de la burocracia y celebrar el caos, hay que reconocer que estos controles no nacieron por un capricho de poder. Son anticuerpos. Nacieron como defensas contra catástrofes específicas.[1]
Una solución informal por brillante que sea trabaja en un vacío de consecuencias. Ese script casero del supervisor podría tener un error de redondeo que descuadre la contabilidad durante meses sin que nadie se de cuenta. Esa herramienta gratuita que usa el equipo de marketing podría estar alojando datos de personas en servidores que no cumplen la normativa, exponiendo a la empresa a multas que podrían meterle en problemas
El lento aparato burocrático en su versión idealizada es un filtro de validación distribuido. Es un sistema diseñado para proteger al organismo, asumiendo que el costo de lentitud es siempre menor que el costo de una crisis imprevista.
Pero incluso reconociendo ese valor de contención, lo informal sigue avanzando. Y lo hace porque el sistema formal perdió la capacidad de capturar las mejoras que ya están ocurriendo en el terreno.
Esto cambia las reglas no escritas del juego. El cargo y la información privilegiada pesan muy poco cuando alguien más ágil toma la delantera operativa. Liderar hoy se parece más a prestar atención a las cosas que estan ocurriendo.
Me ha tocado verlo de cerca, actuar sin autorización es la forma más pura de decidir qué importa.
Recuerdo el caso de una ex colega, cerca de 2013. Automatizó todo el seguimiento de una bodega gigante usando una mezcla de excel y VBA. Lo hizo sola, calladita. Por varios meses guardó el archivo en su pendrive personal, convencida de que si TI la descubría, la sancionarían por instalar «software no autorizado».
La ironía es que cuando finalmente salió a la luz, la gerencia tuvo que admitir que el sistema oficial era una cáscara vacía. Toda la operación logística real dependía de ese script clandestino que vivía en el bolsillo de mi colega.
¿Qué pasó después? TI lo integró al sistema oficial, le pusieron un nombre corporativo y lo escalaron a otras áreas.
Mi colega recibió un correo de agradecimiento del gerente de operaciones. Nunca vio un peso de ese ahorro, ni un peso de algún bono. El script se volvió infraestructura crítica, pero ella siguió siendo «la de bodega», con el mismo sueldo y las mismas restricciones de software. (A veces me pregunto cuántas macros duermen en carpetas ocultas del escritorio, esperando a que alguien se jubile para desaparecer con él. Yo mismo he escondido scripts que hacían mi trabajo más rápido por puro instinto de conservación.)
Esa es la asimetría perfecta… si el script fallaba, la echaban. Si funcionaba, la empresa se quedaba con el ahorro y ella con un correo genérico. No es raro que la mayoría prefiera no jugar.
Si intentamos ponerle un número a este fenómeno, las cifras nos podrian marear. La estimación clásica de que estas eficiencias recuperan dos mil horas al año es una ilusión.
La realidad es más cínica… la empresa prefiere perder cien palos al año por una ineficiencia que todos conocen, porque esa plata ya está presupuestada y no le duele a nadie. En cambio, si te ahorras diez lucas con un bot y cometes un error, te cae la auditoría encima.
Es más seguro dejar que el barco se hunda despacio que intentar un parche que no tenga tres firmas. Al final, el costo de no hacer nada nunca sale en el balance, pero es lo que termina matando la operación.
Si antes había que pasar por cinco firmas para validar un inventario, y ahora se resuelve con un bot que alguien armó en su turno de noche, el sistema oficial se ha vuelto irrelevante. Existe en el papel, se respeta en las reuniones. Pero la operación real sucede en otro lado.
El objetivo de fondo es recuperar la capacidad de acción. Las soluciones aparecen donde hace falta actuar, independientemente de si llegó el permiso. Quienes actúan por su cuenta generalemte están tomando mejores decisiones operativas que quienes siguen esperando instrucciones que nunca llegarán.
Por supuesto, la incertidumbre persiste….Cuando las cosas fallan y nadie tiene el cargo formal, el problema se vuelve huérfano. Pero este proceso se acelera porque la barrera de entrada tecnológica ya se derrumbó. La asimetría de información desapareció… el operario de línea tiene acceso al mismo repositorio global de soluciones (GitHub, foros) que el gerente de tecnología.
A esto del Shadow IT lo tratan como si fuera un virus, pero la verdad es que la gente se juega la pega por puro instinto de supervivencia. El que se manda un script solo está asumiendo que si la cosa funciona, el ahorro se lo lleva la gerencia y a él ni le dan las gracias.
Pero si el bot llega a borrar una coma de más, lo echan por la puerta de atrás sin pensarlo dos veces, alegando seguridad informática. Las empresas hoy caminan gracias a un montón de gente que se salta las reglas para que la línea no pare, sabiendo que si se caen, nadie les va a prestar ropa.
El dilema real es qué tipo de orden estamos dispuestos a tolerar. La fantasía corporativa sugeriría crear zonas de innovación o espacios seguros, corrales para que los empleados jueguen. Pero eso es intentar domesticar lo salvaje.
Quizás la salida más honesta sea una especie de darwinismo operativo.
En lugar de pedir permiso previo, pasamos a un modelo de auditoría posterior. Dejamos que la guerrilla operativa actúe.
El problema es que «funciona» es una palabra tramposa.
Para que el darwinismo operativo no sea una anarquía glorificada, necesitas criterios de supervivencia explícitos. Hablo de preguntas brutales… ¿Cuántas personas la usan sin que nadie les haya obligado? ¿Sobrevivió al primer mes sin que nadie reportara un desastre? ¿El ahorro de tiempo es medible o es solo una sensación? ¿Si el creador se va de la empresa mañana, alguien más puede mantenerla?
Si la herramienta no pasa ese filtro merece ser archivada. La mayoría de los scripts caseros mueren con su creador, y está bien que así sea. Solo unos pocos merecen convertirse en infraestructura oficial.
Ahora, hay una línea roja.
El darwinismo operativo funciona mientras las consecuencias sean reversibles. Si el script del supervisor de bodega descuadra el inventario, se puede corregir. Si la herramienta de marketing expone datos de clientes a un servidor en el extranjero, la empresa puede quebrar.
La regla es simple: permite la experimentación mientras el costo del fracaso sea asimétrico.[2] Es decir, que el ahorro potencial sea mucho mayor que la pérdida máxima posible.
Si un bot puede ahorrarte 50 millones al año pero, en el peor escenario, solo te cuesta 5 millones arreglar el desastre, adelante. Si puede ahorrarte 10 millones pero, si falla, te cuesta 100 millones en multas, ni lo toques.
El problema es que la mayoría de las empresas no tienen idea de cuál es su pérdida máxima aceptable. Trabajan con la ilusión de que el riesgo cero existe, y por eso prefieren la lentitud burocrática a la experimentación controlada.
Pero aquí nace la vulnerabilidad real de este modelo… el costo de la transición. ¿Cómo se convierte una herramienta clandestina en infraestructura crítica sin destruir el espíritu que la hizo útil en primer lugar?
La historia de mi colega en la bodega es la prueba de que el sistema corporativo no sabe absorber; sabe expropiar.
Cuando TI toma una solución que funciona la embalsama.[3] Terminan metiéndole parches de seguridad que sobran y destrozan la interfaz buscando cumplir con el estándar. Al final, quien inventó la herramienta pierde cualquier control sobre ella.
El resultado es una versión exageradamente lenta y con un sello corporativo que todo el mundo termina odiando, que termina siendo reemplazada por otro script clandestino.
Para que el darwinismo operativo funcione, se necesita un protocolo de no-esterilización. Tres reglas básicas para cuando una herramienta informal demuestra su valor:
1. Burocracia mínima viable (BMV): Solo se aplican los controles estrictamente necesarios para mitigarel riesgo existencial (por ejemplo, que los datos no salgan de la empresa). Si el script de Python funciona y es seguro, se le pone un contenedor seguro y se deja tal cual. No se reescribe en Java solo porque a TI le gusta Java.
2. La propiedad no se expropia: El creador de la herramienta no recibe solo un «correo de agradecimiento». Tienen que entregarle la propiedad del producto y un presupuesto decente para operarlo. Pagar un bono por el ahorro generado también es una salida razonable. Si le quitas la herramienta a quien la inventó, le quitas el incentivo a toda la organización para volver a innovar.
3. El derecho al fracaso escalado: Si la herramienta oficializada empieza a fallar o a volverse burocrática, los usuarios deben tener la libertad de volver a la versión informal o crear una nueva, sin represalias.
Si la empresa no está dispuesta a cumplir estas tres reglas, es mejor dejar la herramienta en la clandestinidad. A veces, un sistema paralelo que funciona es mil veces más valioso que un sistema oficial que solo sirve para justificar salarios.
Es un cambio de paradigma un tanto molesto: la innovación se vuelve un delito perdonable en lugar de una actividad planificada.
El desorden asusta, pero intentar ordenar a priori solo retrasa lo que ya funciona. Suele ocurrir que quienes toman las decisiones están a kilómetros de distancia de los problemas reales, sentados en oficinas climatizadas. Si queremos avanzar, tendremos que renunciar a la ilusión de control total.
La jerarquía no ha desaparecido, pero ha perdido el monopolio de la solución. El futuro del negocio se está escribiendo sobre la marcha y con los bolsillos vacíos. Y claro, con bastante susto de por medio, en los lugares donde el control central ya no alcanza a mirar.
Notas:
[1] Nota sobre la inmunología burocrática: Los anticuerpos no tienen criterio, solo patrones. Una política de seguridad creada en 2004 para evitar que un empleado descargue un virus por correo, hoy ataca con la misma ferocidad a un script de Python que ahorra 40 horas semanales. El sistema no evalúa la intención ni el valor de la herramienta, solo si coincide con una firma prohibida. Con el tiempo, la defensa se vuelve autoinmune: ataca al tejido sano (la productividad) con más violencia que a las amenazas reales.
[2] Nota sobre la racionalidad del miedo: A primera vista, bloquear la innovación parece estupidéz corporativa. En realidad, es el Problema Principal-Agente en su forma más pura. El gerente que aprueba el bot no se queda con los 50 millones de ahorro (eso va a los accionistas), pero si el bot falla y cuesta 5 millones, es su cabeza la que rueda. Para el individuo, rechazar la innovación no es un error de cálculo; es la estrategia de supervivencia matemáticamente óptima. La empresa no pierde por falta de inteligencia, pierde porque sus incentivos individuales castigan la varianza, no la ineficiencia.
[3] Nota sobre la embalsamación tecnológica: Esto no es sabotaje por maldad, es una falla de coordinación clásica. El departamento de TI (o Compliance) no es evaluado por la agilidad que aporta a la operación, sino por la cantidad de incidentes de seguridad que evita. Por lo tanto, su incentivo racional es convertir cualquier herramienta ágil en un monolito burocrático a prueba de balas. Están optimizando su propia métrica de supervivencia a costa de la productividad global. El resultado es un sistema «seguro» que nadie usa, y un sistema paralelo «inseguro» que mantiene la empresa a flote.