Cuando leemos sobre «liderazgo ágil» es habitual ver siempre lo mismo: inspiración, visión, servant leadership, propósito... Todo tan cierto y a la vez tan abstracto que lo mismo sirve para gestionar un equipo de software que para entrenar a un equipo de balonmano.

Pero quizás la diferencia entre los equipos que funcionan bien y los que se atascan no está en el carisma del líder, sino en cómo están diseñadas y distribuidas las decisiones. Quién decide qué, con qué información, a qué velocidad, y qué pasa cuando se equivoca.

Es lo que podríamos llamar «arquitectura de decisiones». El liderazgo tradicional se basa en la toma de decisiones y creo que el liderazgo ágil consiste en no tomar las decisiones sino diseñar el sistema que las toma.

La decisión como flujo del sistema, no como atributo del jefe

Normalmente la información se traslada hacia arriba por la jerarquía y las decisiones hacia abajo. El problema es que cada salto de nivel supone latencia y pérdida de contexto. Las decisiones se toman con informaciones que el trayecto ha modulado y cuando la decisión llega abajo la realidad ha podido evolucionar.

David Marquet, capitán de submarino nuclear reconvertido en referente de gestión, lo resumió con la frase «en lugar de mover la información hacia la autoridad, hay que mover la autoridad a donde está la información».

Es la base de la agilidad: «equipos autoorganizados», pero cuidado: descentralizar no es repartir las decisiones y desear suerte. Son necesarios dos pilares: competencia técnica (quienes deciden tienen que saber hacerlo) y claridad de intención (y deben saber para qué). Si no, es más abandonar que descentralizar.

Aquí suele haber una verdad incómoda: en los equipos ágiles no suele estar establecido un mapa de decisión. Si preguntas quién puede decidir cambiar una librería, descartar una historia del sprint, o retrasar una entrega, las respuestas suelen ser una mezcla de «depende», «pregunta a fulano» o silencio. Sin duda hay una arquitectura, porque como equipo autoorganizado, las decisiones se toman, solo que nadie la ha diseñado: ha crecido sola, como la deuda técnica.

No todas las decisiones pesan lo mismo

Jeff Bezos popularizó una distinción que vale más que muchos manuales: hay decisiones reversibles (puertas de doble sentido: si te equivocas, vuelves atrás) y decisiones irreversibles (puertas de un solo sentido: cruzas y la puerta desaparece).

El error clásico de las organizaciones grandes es tratar todas las decisiones como irreversibles: comités, aprobaciones, análisis interminables... para decidir cosas que se podrían deshacer en una tarde. El error simétrico —menos comentado pero igual de caro— es tratar las irreversibles con la ligereza de las reversibles, que es como se acaba con un monolito imposible de migrar o un contrato del que no se puede salir.

De aquí se deriva una regla de diseño bastante limpia:

• Las decisiones reversibles deben bajar al nivel más cercano a la información, con permiso para equivocarse y aprender rápido.
• Las decisiones irreversibles tienen que subir lo justo, ralentizarse deliberadamente y documentarse.

Lo interesante es que la frontera entre unas y otras no es fija: buena parte del trabajo de ingeniería (tests, feature flags, despliegues incrementales, arquitecturas desacopladas) consiste precisamente en convertir decisiones irreversibles en reversibles. Cada vez que abaratas el coste de deshacer algo, estás ampliando la zona en la que el equipo puede decidir sin pedir permiso. La infraestructura técnica es, también, arquitectura de decisiones.

Decidir sin tener toda la información (o sea, decidir)

Si esperas a tener toda la información, no estás decidiendo: estás constatando. La decisión de verdad ocurre siempre con información incompleta, y la pregunta útil no es «¿tenemos datos suficientes?» sino «¿cuesta más esperar o cuesta más equivocarse?». Para las reversibles, casi siempre cuesta más esperar. Hay quien usa la heurística del 70%: si tienes el 70% de la información que querrías, decide; el 30% restante lo compras más barato actuando que analizando.

Aquí es donde encaja un marco que viene del ámbito militar y que describe sorprendentemente bien el trabajo ágil: el bucle OODA de John Boyd —Observar, Orientar, Decidir, Actuar—. Boyd, piloto de combate, sostenía que en un entorno cambiante no gana el que decide mejor en abstracto, sino el que itera el bucle completo más rápido: el que observa, ajusta su interpretación, decide, actúa, y vuelve a observar antes de que el contexto le deje obsoleto.

Suena a iteración en sprints: inspección y adaptación.

Pero el matiz importante de Boyd suele perderse: de las cuatro fases, la decisiva no es Decidir. Es orientar: el filtro de experiencia, contexto, cultura y modelos mentales con el que interpretamos lo que observamos. Dos equipos pueden mirar el mismo dashboard y ver cosas distintas; la diferencia está en la orientación. Ir muy rápido con una orientación equivocada no es agilidad: es ir al estrelladero. Nos quedamos con esto, porque es justo la fase que la IA no nos resuelve.

Y entonces llegó la IA y pisó el acelerador

La IA generativa está comprimiendo el bucle de forma asimétrica. Observar, cada vez más barato: resumir, analizar, detectar patrones en cantidades de información que antes eran inabordables. Actuar, cada vez más barato: generar el código, el documento, el prototipo en minutos. El bucle gira más rápido que nunca...

...y el cuello de botella se desplaza exactamente a las dos fases del medio: orientar y decidir. Es decir, al juicio.

Esto cambia la economía del liderazgo. Cuando producir era caro, el valor estaba en ejecutar bien lo decidido. Cuando producir es barato, el valor está en decidir bien qué producir —y en validar más rápido de lo que se genera—. Es la misma lógica por la que en el post sobre Scrum y la IA apuntaba que el Product Owner evoluciona hacia un Product Architect: cuando la IA construye más rápido de lo que la organización valida, quien decide se convierte en el factor limitante de toda la cadena de valor.

Pero hay un riesgo más sutil que la saturación, y vale la pena nombrarlo: el sesgo de automatización. Cuando un sistema acierta el 90% de las veces, lo natural es dejar de revisar; y entonces el 10% restante pasa sin que nadie lo mire. La trampa es que el asentimiento se parece muchísimo al juicio: aprobar la propuesta de la IA sin haber podido evaluarla da exactamente la misma sensación que decidir. Pero no es decidir. Es firmar.

Aprobar la propuesta de la IA sin haber podido evaluarla da exactamente la misma sensación que decidir. Pero no es decidir. Es firmar.

Las dudas que abre esto (y que no llego a resolver)

Reconocemos que esta línea tiene preguntas abiertas:

• ¿Quién rinde cuentas por una decisión sugerida por IA? La respuesta fácil es «el humano que la aprobó». Pero si ese humano aprueba cuarenta sugerencias al día porque el flujo no le da para más, la rendición de cuentas se vuelve una ficción legal. La responsabilidad sin capacidad real de revisión no es responsabilidad: es un pararrayos.
• ¿Se atrofia el juicio que no se ejercita? El criterio se entrena decidiendo cosas pequeñas y comiéndose las consecuencias. Si la IA absorbe las decisiones pequeñas, ¿de dónde saldrá el criterio para las grandes? Nos preocupa especialmente en los perfiles junior: la IA está cortando los peldaños inferiores de la escalera por la que siempre se subió —decisiones menores, errores baratos, criterio creciente—.
• ¿Estamos descentralizando o re-centralizando sin darnos cuenta? Paradoja curiosa: delegamos descentralizando las decisiones hacia los equipos... y los equipos las delegan en un mismo modelo de IA, con los mismos sesgos y la misma «orientación». Decisiones formalmente distribuidas, cognitivamente homogéneas, pero sin la diversidad de juicio que era una propiedad del sistema que no estamos protegiendo.
• ¿Cuánta fricción es sana? Estamos eliminando fricción en los procesos, y en general es buena idea; pero una cierta fricción en la toma de decisiones irreversibles aporta un mecanismo de seguridad. Si la IA elimina la fricción, habrá que reintroducirla de forma deliberada. Gestionar no lentitud, pero sí sosiego: otro oficio nuevo.

Propuestas para ir modelando una arquitectura de decisiones tomadas por humanos

Por aportar alguna idea, puede tener sentido probar:

1. Hacer un inventario de decisiones. Una retrospectiva monográfica podría bastar para empezar: ¿qué decisiones tomamos recurrentemente? ¿Quién las toma hoy? ¿Quién tiene la mejor información para tomarlas?
2. Clasificar por reversibilidad, no por importancia. «Importante» es subjetivo y suele significar «me pone nervioso». Reversible/irreversible es operativo: las reversibles, abajo y rápido; las irreversibles, despacio y por escrito.
3. Sustituir instrucciones por intención. En lugar de decidir por el equipo, dar el contexto para que decida el equipo: qué se busca, qué restricciones hay, qué es innegociable. Es el commander's intent militar y lo que diferencia delegar de abandonar. Curiosamente, es la misma disciplina que exige escribir una buena especificación para una IA: si no sabes explicitar la intención, el problema no es de quien ejecuta.
4. Llevar un registro ligero de decisiones. Los ADRs (Architecture Decision Records) son el ejemplo conocido en software, pero el formato mínimo sirve para cualquier ámbito: qué se decidió, qué alternativas se descartaron, qué se sabía en ese momento. No es burocracia: es lo que permite, seis meses después, distinguir una mala decisión de una decisión razonable con mala suerte. Sin ese registro, toda retrospectiva de decisiones es un juicio con el diario del lunes.
5. Usar la IA para abrir opciones, no para cerrarlas. Como generadora de alternativas y abogado del diablo («¿qué estamos asumiendo?», «¿cómo podría salir mal esto?») es valiosísima. Como oráculo que entrega la respuesta final, es una máquina de fabricar asentimiento. La regla práctica: que la IA amplíe el menú, pero el plato lo elige el equipo.
6. Hacer retrospectivas de decisiones, no solo de tareas. En las retrospectivas se suele revisar qué hicimos y cómo nos coordinamos, pero rara vez cómo decidimos. Se trata de coger dos o tres decisiones del último trimestre y evaluar el proceso, no el resultado: ¿teníamos la información que era razonable tener? ¿Decidió quien debía? ¿Tardamos lo adecuado? El juicio también necesita su bucle de inspección y adaptación.
7. Proteger decisiones pequeñas para que las personas las tomen. Aunque la IA pudiera tomarlas mejor. No es ineficiencia: es el coste de entrenamiento del criterio para abordar decisiones que la IA no pueda tomar. Los pilotos siguen volando a mano de vez en cuando aunque el autopilot sea estadísticamente mejor, por la misma razón.

En definitiva, en un equipo ágil, el liderazgo no se ocupa de tomar las decisiones, sino de diseñar la arquitectura por la que fluyen: dónde se toman, con qué información, a qué velocidad, con qué red de seguridad, y ahora, además, qué rol asume la IA en cada punto de ese flujo.

Sin duda, esto es un esbozo para un mapa que está en construcción. Si estáis experimentando con cómo distribuir decisiones en vuestros equipos —con o sin IA de por medio—, las sugerencias y correcciones son bienvenidas.