El año en que ayudé a dirigir a 700 personas a las que no podía dar órdenes
Tenía veintiún años, era becario y uno de los cuatro coordinadores de un equipo de veinticuatro personas que reclutó y dirigió a 700 voluntarios en apoyo de un campeonato mundial de robótica en la Ciudad de México. No tenía ningún puesto que alguien respetara, ni presupuesto digno de mención, ni autoridad para obligar a ninguna de esas personas a hacer nada.
Y aquí está lo que nadie te cuenta del voluntariado: no tienes ni tantita autoridad. La gente que coordinas tiene trabajos de tiempo completo, carreras y su propia vida. Están ahí porque les importa. No puedes exigir; solo puedes inspirar, organizar y ponerles fácil a las buenas personas para que hagan un buen trabajo.
Esa limitante resultó ser la educación en gestión más útil que he tenido, porque tiene exactamente la misma forma que el problema que hoy enfrenta cualquier organización con la IA. Tienes una capacidad nueva y poderosa, una plantilla ocupada y escéptica, y una fuerte tentación de imponer la adopción desde arriba. Y, a la mala, no funciona. Quiero explicarte por qué y qué sí funciona en su lugar.
(Este texto trata sobre cómo difundir la práctica. Si lo que quieres es la práctica en sí, ya escribí sobre el cambio que representa el paso Del vibe coding a la ingeniería de IA y sobre la disciplina de la revisión en su centro: La revisión es el producto. Aquí respondo a la pregunta más difícil: ¿cómo logras que una organización de verdad adopte algo de eso?)
Los mandatos producen cumplimiento. No producen capacidad.
Asómate a la mayoría de las implementaciones de IA y te vas a encontrar con el mismo manual: comprar licencias, ordenar que se use y poner un número en un tablero que cuenta cuánta gente ha abierto la herramienta. Se siente como un avance. No mide nada que importe.
El resultado previsible es puro teatro del cumplimiento. Los ingenieros abren la herramienta porque se los ordenaron, la usan de manera superficial y, en la práctica, le sacan la vuelta, mientras la organización se echa porras por una métrica de adopción y la capacidad real —saber planear un trabajo que un agente pueda ejecutar y revisar lo que produce— nunca se desarrolla. Consigues la apariencia de transformación, sin la sustancia.
Detrás de esta división hay investigación real y vale la pena detenerse en ella porque es genuinamente contradictoria. El propio estudio de GitHub sobre Copilot encontró que los desarrolladores terminaban una tarea un 55% más rápido y se sentían notoriamente más satisfechos. Pero otro estudio, el de Uplevel, que siguió a unos 800 desarrolladores, encontró que quienes usaban Copilot introducían un 41% más de errores y no obtenían ninguna ganancia real de productividad a cambio. Las dos cosas son ciertas. La variable que las reconcilia nunca fue la herramienta. Fue la práctica en torno a la herramienta. Y la práctica no se difunde por decreto.
Los dos caminos
La investigación organizacional a la que siempre regreso es un estudio de dos empresas que perseguían la misma meta con modelos de liderazgo opuestos. Una hizo bajar el cambio de arriba hacia abajo, a través de la planeación anual, y se fue frenando bajo su propio peso de coordinación. La otra lo dirigió de forma distribuida —los autores lo llaman “cultivar y coordinar”: abrir espacio y brindar apoyo para que las iniciativas crezcan dentro de los equipos que hacen el trabajo— y ese enfoque fue acumulando ventaja más rápido hacia la meta.
La lectura honesta no es que “lo distribuido siempre gane”. Es que una postura distribuida acumula ventaja más rápido, porque va a favor de la idea de cómo la gente ocupada de verdad cambia su comportamiento: no cuando se lo ordenan, sino cuando un colega le muestra algo que le mejora su propia semana.
Eso encaja a la perfección con la adopción de la IA. Mis 700 voluntarios no se movieron porque yo ordenara nada. Se movieron porque les dimos un marco claro, las herramientas para actuar y el espacio para liderar su propio rincón del asunto. Cada ingeniero que agarra el hábito de planear lo prueba en un ticket real y se lo enseña a quien tiene junto a él; está haciendo más por la adopción que cualquier mandato.
Los ingenieros adoptan lo que claramente les mejora la semana
Por debajo del organigrama, la adopción se simplifica y se vuelve más honesta. Los ingenieros son pragmáticos. Agarran una herramienta en el momento en que se cumplen dos cosas: que de verdad sea fácil de usar y que claramente les devuelva algo —tiempo libre, más cosas entregadas, una tarea tediosa vuelta indolora—. No valor prometido. Valor visto.
Y la forma más rápida de matar la adopción es la fricción. Si sacarle valor a la herramienta significa pasarte una semana descifrando cómo funciona, cómo se configura y cómo ajustarla al trabajo real, la mayoría de los ingenieros —ya de por sí enterrados en entregables— van a decidir, sin hacer ruido, que no vale la pena. Y van a tener razón. La vara nunca fue “¿Esto es poderoso?”. Es: “¿Puedo sacarle valor hoy sin montar un proyecto de investigación?”. Entre menos fricción tenga y más metida esté en el flujo de trabajo que ya usan, más rápido se convencen.
Por eso, una victoria demostrada siempre le gana a un mandato. Cuando un ingeniero ve que un compañero terminó en una tarde algo que antes se comía en dos días —y ve que ese compañero no tuvo que volverse experto en IA para lograrlo—, convencerse deja de ser una decisión. Simplemente es obvio. El valor se vende por sí solo y se expande de lado a lado más rápido de lo que cualquier plan de implementación podría empujarlo hacia abajo.
También les dice a los líderes que arquitectan y a los que habilitan cuál es su trabajo justo: no evangelizar, sino eliminar fricción. Haz que el buen patrón sea el camino de menor resistencia. Métele el patrón ahí donde ya se hace el trabajo. Quítale el esfuerzo de entenderlo. Cada pizca de fricción que quitas es una semana de adopción que recuperas, porque en el momento en que los ingenieros ven valor fácil, el convencimiento se da solito.
Ponle nombre a los tres roles, y asegúrate de que existan los tres
Si pudiera entregarle a un manager un solo marco para esto, sería la idea de que una organización ágil necesita tres tipos distintos de liderazgo presentes simultáneamente. No necesita un solo héroe. Necesita que los tres roles estén cubiertos en algún lugar del equipo:
- El liderazgo de arquitectura diseña el sistema que vuelve repetible el trabajo: es quien se sienta a escribir la plantilla de planeación y la lista de verificación de revisión que los próximos cien ingenieros van a usar. Es de alto apalancamiento y poco agradecido, porque al arquitecto casi nunca le reconocen los tickets que se entregan más adelante. Si le inviertes menos, terminas con mil ingenieros resolviendo, cada uno por su cuenta, el mismo problema. (Que es justo lo que está pasando ahora mismo en toda la industria con la IA.)
- El liderazgo de habilitación apoya a la gente que hace el trabajo: le da tiempo, dentro de un sprint saturado, para aprender la nueva práctica y le da respaldo cuando un primer intento no llega a entregarse. Este es el verdadero trabajo del manager en la adopción de la IA, y justo es el que la mayoría de los managers hoy se salta con tal de andar mirando un tablero de uso.
- El liderazgo emprendedor es el ingeniero de primera línea que experimenta en un ticket real y trae de vuelta la lección aprendida. Aquí es donde ocurre la mayor parte del cambio real, le llame a eso liderazgo o no.
Quita cualquiera de los tres y ese cuarto no produce nada. El arquitecto sin quien habilite nunca llega a los ingenieros. Quien habilita sin arquitecto no tiene nada que esparcir. Los emprendedores, sin ninguno de los dos, reinventan la misma rueda cada quien por su lado. Ponerles nombre a los tres roles le da al manager tres conductas concretas que respaldar el lunes por la mañana, en vez de un mandato borroso que hacer cumplir.
La unidad que entrega ya no es el individuo
Debajo de todo esto hay un cambio más sutil y es el que creo que la mayoría de los planes de adopción se pierden.
Cuando decimos “ingeniería asistida por IA”, nos imaginamos a un solo ingeniero y su agente. Pero lo que de verdad entrega un cambio es un equipo pequeño que cruza varias fronteras: quien carga con la intención de negocio, quien conoce la realidad del cliente, el ingeniero que es dueño del sistema y responde por él, el agente que hace la implementación, quien revisa y sostiene la línea de riesgo y cumplimiento, y quien va a dar mantenimiento y heredará cada atajo que se tome hoy.
Una manera útil de sostener esto es pensar en un ritmo de tres tiempos: explorar —reunir el contexto y la intención desde fuera de tu propia frontera antes de generar nada—; explotar —la ejecución interna disciplinada que el agente acelera—; y exportar —regresar el aprendizaje a los equipos vecinos y a la gente río abajo que va a heredar el trabajo—. El ingeniero que trata a la IA como un truco de productividad en solitario está explotando sin explorar ni exportar, y resolviendo rápido el problema equivocado. El límite de rendimiento nunca fue qué tan rápido teclea una persona. Es qué tan bien se coordinan esos roles a través de las fronteras que hay entre ellos.
Por eso también “nada más toma un curso corto de la herramienta” no alcanza. El curso te enseña a gestionar la relación de forma independiente con el agente. La capacidad que mueve a una organización es aprender a trabajar en los tres modos a la vez, y eso es un problema de liderazgo, no de herramientas.
No esperes a que sea perfecto
Un principio más, de una charla que se me quedó grabada: esperar a que la IA sea perfecta antes de adoptarla no es prudencia, es un error de categoría. La tecnología jamás se va a quedar quieta lo suficiente para perfeccionarse. La ventaja se la llevan las organizaciones cuya gente ya está practicando en trabajo real en este sprint, con verificación humana integrada en el flujo de trabajo. Empieza donde el aprendizaje ya está en marcha. Cuando le enseñes a la gente cómo se ve lo “bueno”, prefiere las historias por encima de las métricas. Entrega una primera versión imperfecta y haz que la siguiente sea mejor.
Eso no es imprudencia. Es la misma lección que me enseñaron aquellos 700 voluntarios y la misma que me enseñó, años después, un equipo de robótica de bajos recursos, cuando el equipo que les iba ganando se detuvo a mitad de la competencia para prestarles refacciones y que sus rivales pudieran terminar. Este trabajo nunca se trató del lugar en la tabla. Se trató de construir un entorno en el que la gente se ayudara mutuamente a mejorar. La adopción es cultura y la cultura es humana. La herramienta sigue a las personas; nunca las lidera.
No puedes instalar una capacidad. Solo puedes cultivarla: arquitecta los patrones, habilita a la gente, respalda a quienes ya están experimentando y mide lo que de verdad importa. Esa es toda la diferencia entre una organización que decretó la IA y otra cuyos ingenieros se volvieron buenos con la IA: la primera es una diapositiva; la segunda, un año de ventaja que se va acumulando.
Mide la adopción por el valor de negocio que entrega, no por cuánta gente abrió la herramienta. Lidera el cambio desde donde ya se realiza el trabajo.