A minimalist editorial illustration showing a large boulder labelled "Delivery" resting on a lever. One end of the lever is labelled "AI" and is being pushed hard with almost no effect, while a smaller handle near the fulcrum labelled "Decision Rights" remains untouched, illustrating that the greatest organisational leverage often comes from governance rather than coding speed. Above the scene appears the title "What AI Doesn't Change."

Sobre la importancia de encontrar la palanca adecuada

La presión del directorio para mostrar retorno del gasto en IA suele producir el mismo primer movimiento: tirar más fuerte de la palanca de la IA. Más mandatos de adopción, más seguimiento de uso, otra ronda de capacidad de tokens comprada para sostener el ritmo acelerado — todo eso se pliega a lo que la mesa directiva ya lee como progreso. Es un instinto razonable: esa palanca está dentro de la autoridad directa del CTO, es lo bastante visible como para explicarla en una sola diapositiva, y produce un número que parece movimiento. Noto, sin embargo, que seguir invirtiendo en esa dirección casi siempre agrega capacidad a una sola etapa del sistema — la del código en sí — mientras que, como [ya escribí antes](https://thesoftwarecoach.co.uk/es_ES/10x-productivity-unforseen-effects/), introduce una variabilidad propia que la mayoría de las planificaciones no contempla. Para bastantes organizaciones en crecimiento, tirar más fuerte de la palanca apenas mueve el resultado que realmente le importa a la mesa directiva.

No todos los puntos donde podés intervenir en un sistema tienen el mismo peso. Algunas palancas son fáciles de alcanzar y casi no producen nada cuando las tirás. Otras quedan más alejadas de la vista y pueden repercutir en gran parte del sistema cuando se mueven. La facilidad para alcanzarlas no predice de forma confiable cuál es cuál. Encuentro que la verdadera habilidad está en rastrear los efectos de primer y segundo orden de una palanca antes de tirar de ella, en lugar de asumir que la que tenés más a mano es suficiente — o irrelevante.

Sin embargo, encuentro que la palanca de adopción de IA casi siempre es la fácil. La que realmente gobierna la entrega a escala está más cerca de los derechos de decisión — quién está formalmente autorizado para resolver un conflicto de prioridades entre dos escuadras, quién es dueño de un límite arquitectónico que ambos equipos asumieron en silencio que le correspondía al otro. Esa estructura existía antes de la IA. Simplemente no estaba bajo mucha presión, porque el volumen de decisiones que llegaban a ella era manejable.

La IA cambia la tasa de llegada, no la estructura. Dos equipos ahora pueden producir cada uno una implementación funcional contra un contrato de API que ninguno confirmó formalmente, en una fracción del tiempo que antes llevaba — y el desajuste sale a la luz antes, más seguido, y con más código ya construido encima. Cada uno de esos desajustes necesita a alguien con autoridad para resolverlo. Si esa autoridad nunca se hizo explícita, cada caso se convierte en una escalada, un PR estancado, una conversación que tiene que pasar antes de que cualquiera de los dos equipos pueda seguir con seguridad. La organización no está más lenta porque el código se volvió más rápido. Está más lenta porque la estructura de gobernanza ahora tiene que absorber decisiones a un ritmo para el que nunca fue diseñada.

Acá es donde la solución instintiva se desvía. Frente a esa fricción, la respuesta suele ser más de la palanca visible — mandatos de uso de IA más estrictos, seguimiento de velocidad más granular, presión para “alinearse mejor” sin especificar cómo. Nada de eso toca los derechos de decisión, porque rediseñarlos es más difícil que armar un dashboard. Requiere decidir, explícitamente, quién es dueño de qué — que es exactamente el tipo de trabajo organizacional que las palancas fáciles te permiten evitar.

Nada de esto es un argumento en contra de adoptar IA. Es un argumento para revisar, antes de aplicar más presión sobre la palanca que ya tenés a mano, si esa palanca alguna vez estuvo conectada a la restricción real. Ya escribí antes sobre dónde suele estar realmente el cuello de botella a escala] — esto es la capa de gobernanza debajo de esa misma observación: saber que la restricción no es el código sólo sirve una vez que encontraste la palanca que realmente está conectada a ella.

Si esto te resonó, el siguiente paso es gratuito.

Una guía práctica para convertir la mejora del equipo en un sistema repetible — el mismo enfoque que uso con mis clientes. Sin ventas, solo el marco de trabajo.

Descargar: Perspectivas para la Mejora →

Si estás listo para ir más allá, exploremos cómo aclarar los derechos de decisión en tus equipos en crecimiento puede funcionar para tu organización. Escribime hoy, y busquemos juntos la palanca que realmente está conectada a la restricción.


Discover more from The Software Coach

Subscribe to get the latest posts sent to your email.

Leave a Comment

Your email address will not be published. Required fields are marked *