Desplegado o desarrollado: El/La ingeniero/a que desarrollas

Se envía un ingeniero desplegado en primera línea. A partir de ese trabajo, se crea uno desarrollado en primera línea. Tercera parte de la serie de Tyson Heaton sobre quién controla la capacidad de IA.

Un ingeniero desplegado en primera línea se incorpora a tu dominio. Un ingeniero desarrollado en primera línea se forma a partir de él. Esta es la parte final de la primera parte de la serie¹ sobre el ingeniero desplegado en primera línea. La primera parte analizó la financiación del puesto y se preguntó quién es el responsable de la inteligencia acumulada. La segunda parte siguió el patrón de Frederick Winslow Taylor y la experiencia práctica que generó en Meta esta primavera. Observé que en Toyota la capacidad de mejorar el trabajo está integrada en las personas que lo realizan; esta última parte trata sobre cómo hacerlo de forma deliberada.

No se trata de un ingeniero desplegado en primera línea, sino de uno desarrollado en primera línea. Un ingeniero formado a partir de un experto en el dominio, en lugar de simplemente incorporarse a él.

La diferencia se manifiesta en la dotación de personal. El enfoque de despliegue consiste en redactar una descripción del puesto, buscar candidatos en el sector del software, contratar personal con un perfil escaso y costoso, y esperar que el conocimiento del dominio se acumule durante el proyecto. El enfoque de desarrollo comienza en el otro extremo: identificar un problema de flujo de trabajo, formar el equipo del proyecto con las personas que lo gestionan y proporcionarles las herramientas, el tiempo y una estructura de apoyo. La capacidad de IA surge como un subproducto de la solución de un problema que ya les preocupaba, y permanece donde surgió.

Alguien objetará que esto solo funciona para cambios incrementales, y que lo que aporta la IA no es incremental. Lean tiene un término para el otro tipo. Kaikaku es el cambio radical, el rediseño deliberado de un proceso en lugar de su mejora gradual, y siempre se ha hecho de forma diferente a kaizen: se le encomienda el desafío a un equipo multifuncional creado para ello, y sigue siendo mejor que subcontratar el rediseño a alguien que llega, realiza entrevistas con las partes interesadas y presenta una nueva forma de trabajar para el equipo. Hay que ser honesto con el equipo sobre lo que sucede al final. Ante un cambio radical, no hay respuestas fáciles, solo respuestas más o menos honorables.

Hay una condición para todo esto, y es la que ya reveló la lógica militar. Las personas revelan sus métodos cuando la divulgación deja de usarse en su contra. Se trata de un compromiso de gestión con contenido: la mejora no supone ningún coste para el empleo, quien encuentra 20 minutos en una tarea de cuatro horas comparte la ganancia, y enseñar el mejor método es trabajo remunerado, no un impuesto a la competencia. La versión de Toyota era la seguridad laboral ligada a la mejora. La versión de Formación dentro de la Industria (TWI) consistía en integrar los programas en la gestión de la empresa, razón por la cual sobrevivió allí y desapareció en todas partes. Si no se mantiene el compromiso, el ingeniero con visión de futuro se convierte en un nombre nuevo para alguien a quien se le ha pedido que se ofrezca voluntario para su propio rediseño. Ellos mismos harán los cálculos. Siempre lo han hecho.

Los proveedores han aceptado la premisa: el director ejecutivo de Varick y el líder tecnológico con las vacantes imposibles de cubrir, ambos de la primera parte de esta serie, llegaron a la misma conclusión desde perspectivas opuestas: que no existe suficiente personal cualificado.

Dos caminos y el obstáculo en ambos

A partir de ahí, se pueden tomar dos caminos. Buscar desesperadamente a los escasos profesionales externos y las herramientas para multiplicarlos. O desarrollar la competencia internamente, donde el contexto que el ingeniero desplegado intenta extraer con tanto esfuerzo ya existe. La mayoría de las organizaciones necesitarán una combinación de ambos.

La dificultad no reside en la estrategia. El problema radica en que las personas mejor preparadas para rediseñar el trabajo suelen ser las de mayor rendimiento, y un gerente al que se le pide que libere a alguien para un proyecto de mejora prescindirá de casi cualquier otra persona antes. Esto no es un obstáculo. Es la misma lógica que impide que se lleven a cabo las mejoras en circunstancias normales. Necesitas una combinación de personas: alguien que domine el trabajo a la perfección, alguien con la paciencia suficiente para trabajar con la herramienta hasta que falle, alguien con la autoridad necesaria para tomar decisiones y, detrás de ellos, un gerente que mantenga el equilibrio entre la demanda y el ritmo, ya que ahí es donde se materializa la mejora. Especificar este requisito antes de preguntar es lo que te permite conseguir a la persona que necesitas, en lugar de a la que simplemente estaba disponible.

Realiza más de un experimento

Con el enfoque de ingeniería de desarrollo prospectivo, necesitarás realizar más de un experimento. Un único experimento piloto cuidadoso te indica lo que sucedió una vez, en un proceso, con un equipo. Varios experimentos simultáneos, en diferentes dominios, te mostrarán dónde residen realmente tus datos, qué ocultaba tu documentación y qué personas se involucran en este trabajo cuando nadie se lo asigna. Este último aspecto es el resultado real, y esas personas generalmente no son las que el organigrama propondría.

Un hackathon sobre un problema real funciona, con dos reglas más importantes que la agenda. Sé lo más perezoso posible: sigue devolviendo el trabajo a la herramienta hasta que falle, porque la falla es la información. Y comience cuanto antes: incorpore la herramienta al proceso de pensamiento y al planteamiento del problema, no solo al final del producto. La mayoría recurre a ella demasiado tarde, cuando las decisiones difíciles ya se han tomado sin ella.

En un hackathon de Claude Code organizado por Anthropic el pasado febrero, 500 participantes seleccionados tuvieron una semana para desarrollar. Cuatro de los cinco ganadores no eran desarrolladores profesionales: un abogado especializado en lesiones personales, un cardiólogo, un especialista en carreteras e infraestructura y un músico electrónico. El primer premio fue para el abogado, quien creó una herramienta para solucionar el cuello de botella en la obtención de permisos en California sin escribir el código él mismo.²

Hemos estado observando lo mismo de cerca. Andy Buczewski, director de operaciones de Viwinco, y Chinua Akaosa, gerente de distribución y almacén de O.C. Tanner, ambos provenían del sector, no de la tecnología, y ahora ambos desarrollan cosas que sus organizaciones tecnológicas no esperaban que fueran capaces de crear. La reacción de estos líderes es la misma: sorpresa por la velocidad, seguida de una reclasificación. El experto en la materia deja de ser un simple interesado y se convierte en un recurso. Art Smalley dirige sesiones prácticas semanales con tareas para un grupo de compras, donde desarrollan progresivamente sus capacidades mientras resuelven un problema real dentro de su propia función. De esta manera, cuando llegue el rediseño integral, participarán activamente en lugar de ser meros sujetos de entrevista.

Luego, observe quién detecta el error. En cualquier grupo de 30 personas, tres o cuatro permanecerán involucradas incluso después de que finalice el ejercicio. Esos son los candidatos, y la intervención es mínima: acceso real a herramientas, un flujo de trabajo propio y tiempo reservado. Pero identificarlos es solo uno de los objetivos del ejercicio. Informa a todos los demás que el trabajo está cambiando, y dedicar tiempo al equipo para que participe de forma estructurada y no estructurada demuestra el compromiso de la organización con el desarrollo de las personas, no solo de las máquinas.

Lo que aprendemos de esto no es que estas personas sean raras, sino que la mayoría de las organizaciones cuentan con varias, y que existen fuerzas que trabajan para mantenerlas ocultas. Nada en la estructura los selecciona, y los incentivos hacen que su desarrollo sea costoso para quienes tienen la influencia para hacerlo. Esa es la limitación, y es un problema de gestión más que de talento. Entonces, hay que centrarse en lo que funcionó, en un rediseño real de los procesos en lugar de otro proyecto piloto, porque los proyectos piloto que se quedan en pilotos generan un aprendizaje que nunca se acumula. TWI tuvo éxito en casi todos los lugares donde se implementó. Solo se acumuló en Toyota, donde se integró en la forma en que se gestionaba la empresa en lugar de ejecutarse como un programa.

Y una última reflexión sobre si esta capacidad se puede comprar. Sí, se puede. Lo que no se puede comprar es dejar de comprar. La optimización no es estática. Los modelos cambian cada pocas semanas, así que lo que funcionó el trimestre pasado necesita adaptarse este, y la adaptación es la parte que requiere conocer el trabajo. Nadie va a volver a contratar a un proveedor cada vez que haya cambios, y los proveedores lo saben, por eso las nuevas ofertas se parecen más a residencias que a proyectos. Si se contrata la adaptación, se incurre en un coste fijo que aumenta al ritmo de la tecnología, y cada adaptación implica que el conocimiento del proceso pase por el ciclo del proveedor una vez más. Si se desarrolla internamente, la misma volatilidad juega a su favor: cada lanzamiento de modelo es una práctica para quienes ya conocen el trabajo. Cuanto más rápido mejora la tecnología, mayor es esa diferencia.

A falta de la persona altamente especializada que no puede encontrar, se cuenta con un buen liderazgo y experimentos bien ejecutados. Esto es un elemento menos impresionante que un ingeniero desplegado en el terreno. Además, es lo único de la lista que ya posee.

La preposición

Las herramientas son nuevas. La elección no lo es.

Las organizaciones que puedan, comprarán la versión implementada, porque tiene un nombre, un número y un proveedor, y porque se puede justificar antes de que finalice el trimestre. Algunas la internalizarán y reconstruirán el departamento de planificación dentro de su propio perímetro. Unas pocas optarán por lo más difícil.

Van a tener ingenieros de vanguardia. La tecnología no es opcional y el mandato ya está escrito. La única pregunta que queda es la preposición: si se implementarán dentro de su organización o se desarrollarán fuera de ella.

El juicio y la responsabilidad siguen siendo humanos. La pregunta es de quién.

1. Esta serie fue investigada y redactada con la ayuda de inteligencia artificial.
2. “Meet the winners of our Built with Opus 4.6 Claude Code hackathon,” Anthropic, April 20, 2026.

Tyson Heaton. Director Sénior de Co-Learning y Estrategia Empresarial y Coach Sénior del Lean Enterprise Institute

Extraído de: The Lean Post