La tuerca

En Modern Times (1936) el personaje de Chaplin aprieta tuercas en una cadena de montaje. A su lado, un capataz le observa. No hace nada más: vigila que la tuerca se apriete bien, al ritmo correcto, en el orden correcto. Más arriba, el dueño de la fábrica mira a todos desde una pantalla gigante. La cadena se acelera. El personaje enloquece.

La escena es una parodia, pero la lógica que parodia sigue viva. Las organizaciones quieren hacer tuercas. Quieren que el trabajo sea predecible, medible, replicable. Quieren saber cuánto tarda, cuánto cuesta y que el resultado sea prácticamente idéntico al plan. Con las tuercas funciona. Con el software, no.

El software no es una tuerca. No es un material que se comporte de forma determinista. No lo era ya antes de la llegada de la IA. Lo que no ves del software es más que lo que ves: un cambio aparentemente simple puede desencadenar efectos inesperados en partes del sistema que nadie estaba mirando. Las organizaciones de producto digital viven en una tensión que no pueden resolver: entre el foco que exige la complejidad fractal del software y la urgencia constante que genera su opacidad. Nuestro cerebro, entrenado en bellas cadenas de montaje donde el encaje de elementos en la entrada acaba dando la salida prevista — desde un automóvil a una hamburguesa —, vive aquí su primera crisis.

Bueyes

Frederick Winslow Taylor publicó The Principles of Scientific Management en 1911. Su método se convirtió en el evangelio de la producción industrial: medir cada movimiento, eliminar los inútiles, estandarizar el resto. Lo llamaba "the one best way" — la única forma correcta de hacer cada tarea.

Para demostrar su método, Taylor eligió a un obrero de Bethlehem Steel al que llamó Schmidt. Su trabajo consistía en cargar lingotes de hierro en un vagón. La media era de 12,5 toneladas al día. Taylor calculó que debía ser 47. Es una historia que todavía se puede encontrar hoy en las formaciones de gestión empresarial.

— "Schmidt, ¿eres un hombre que quiere ganar bien?" — "No sé qué quiere decir."

— "Un hombre que quiere ganar bien hace exactamente lo que le dicen, de la mañana a la noche. Cuando te digan que camines, caminas. Cuando te digan que te sientes, te sientas. Y no replicas."

Schmidt cargó 47,5 toneladas. Ganó 1,85 dólares en vez de 1,15. Taylor lo consideró un éxito. Pero lo más revelador no es el experimento. Es lo que Taylor pensaba de Schmidt:

— "Uno de los primeros requisitos para un hombre apto para cargar lingotes como ocupación regular es que sea tan estúpido y tan flemático que en su constitución mental se asemeje más al buey que a cualquier otro tipo."

Esa frase contiene en miniatura todo lo que vino después. Si asumes que las personas son bueyes, diseñas sistemas para bueyes. Cadenas de montaje, capataces, cronómetros. La tuerca que aprieta Chaplin es eso: un trabajo reducido a un gesto repetitivo que no requiere — ni permite — pensar.

El trabajador del conocimiento

En 1959, Peter Drucker acuñó un término que debería haber cambiado todo: knowledge worker. Su argumento era que el tipo de trabajo que estaba emergiendo no podía gestionarse como una cadena de montaje. No se podía medir en unidades por hora. No se podía estandarizar. No se podía supervisar mirando por encima del hombro.

"Nadie puede motivarle. Tiene que motivarse a sí mismo. Nadie puede dirigirle. Sobre todo, nadie puede supervisarle."

"Los trabajadores del conocimiento deben saber más sobre su trabajo que su jefe — o no sirven para nada."

— Peter Drucker

Drucker llamó al aumento de productividad del trabajador manual "la gran contribución de gestión del siglo XX — un incremento de cincuenta veces". Y dijo que el reto del siglo XXI sería hacer lo mismo con el trabajador del conocimiento. Pero advirtió que los métodos serían completamente distintos. Lo que motiva al trabajador del conocimiento, escribió, "es lo que motiva a los voluntarios: necesitan desafío, necesitan conocer la misión de la organización y creer en ella, necesitan ver resultados".

La mayoría de las organizaciones escucharon a Drucker, asintieron, y siguieron gestionando como Taylor.

El contramodelo japonés

Mientras Occidente perfeccionaba la cadena de montaje, en Japón estaba ocurriendo algo distinto. Toyota desarrolló un sistema de producción basado en premisas opuestas a las de Taylor. En vez de un "one best way" diseñado desde arriba, el kaizen proponía que la mejora continua viniera de todos los niveles de la organización. En vez de eliminar la variabilidad humana, el sistema la aprovechaba. Los operarios podían detener la línea de producción si detectaban un problema — algo impensable en una fábrica taylorista.

Takeuchi y Nonaka describieron en 1986 cómo los equipos japoneses más innovadores trabajaban de forma integrada, solapando fases y aprendiendo en ciclos cortos. Lo llamaron "el nuevo juego del desarrollo de producto". No lo sabían, pero estaban describiendo el antecedente directo de lo que quince años después se llamaría Scrum.

J.K. Liker sistematizó estos principios en The Toyota Way (2004): la ventaja competitiva de Toyota no venía de tecnología ni de capital, sino de cultura y método. Respeto por las personas. Eliminación del desperdicio. Decisiones tomadas lo más cerca posible de donde ocurre el trabajo.

"The Toyota style is not to create results by working hard. It is a system that says there is no limit to people's creativity. People don't go to Toyota to 'work' they go there to 'think'."

— Taiichi Ohno

Era, en esencia, la antítesis de Taylor. Pero traducir eso a organizaciones occidentales de software resultó ser mucho más difícil de lo que parecía.

Diecisiete personas en la nieve

En febrero de 2001, diecisiete desarrolladores se reunieron en una estación de esquí en las montañas Wasatch de Utah. Venían de corrientes distintas — Extreme Programming, Scrum, Crystal, Adaptive Software Development — pero compartían una frustración: los procesos pesados, la documentación interminable, los planes que no sobrevivían al contacto con la realidad.

Rechazaron llamarse "métodos ligeros". Alistair Cockburn explicó: "No me importa que la metodología se llame ligera, pero no estoy seguro de querer que me llamen un peso ligero que asiste a una reunión de metodólogos peso ligero. Suena como un grupo de gente flacucha y débil intentando recordar qué día es".

Lo que produjeron en dos días — cuatro valores y, semanas después por email, doce principios — se convirtió en el Manifiesto Ágil. Personas sobre procesos. Software funcionando antes que documentación exhaustiva. Respuesta al cambio sobre seguir un plan. Las corrientes open source les llevaban cierta ventaja en este tipo de intuiciones.

Andrew Grove, que en 1983 estaba pilotando el pivote estratégico de Intel desde la memoria hacia los microprocesadores, lo formuló con una metáfora que los firmantes habrían suscrito:

"We must recognize that no amount of formal planning can anticipate changes such as globalization and the information revolution. Does that mean that you shouldn't plan? Not at all. You need to plan the way a fire department plans. It cannot anticipate where the next fire will be, so it has to shape an energetic and efficient team that is capable of responding to the unanticipated as well as to any ordinary event."

— Andrew Grove, High Output Management

La ironía es que Agile se convirtió en exactamente lo que pretendía reemplazar. Martin Fowler, uno de los firmantes, lo dijo con amargura en 2018: "El Complejo Industrial Ágil imponiendo métodos a la gente es una absoluta aberración". Y añadió algo que parece un eco involuntario de Taylor: "Debemos luchar contra la imposición de una única forma correcta de hacer las cosas".

Dave Thomas, otro firmante: "La palabra 'ágil' ha sido subvertida hasta el punto de no significar nada. Lo que pasa por comunidad ágil parece ser en gran medida una arena para consultores y vendedores".

Una filosofía nacida para liberar a los equipos de la burocracia fue industrializada a través de frameworks rígidos, certificaciones comerciales y checklists de cumplimiento.

Taylor habría reconocido el patrón.

La profecía autocumplida

En 1960, Douglas McGregor publicó The Human Side of Enterprise y describió dos lentes para mirar a las personas. La Teoría X asume que la gente evita el trabajo, necesita supervisión constante y solo responde a incentivos y castigos. La Teoría Y asume que la gente busca responsabilidad, se motiva intrínsecamente y trabaja mejor cuando se le da autonomía.

McGregor nunca dijo que la Y fuera "la buena". Lo que sí dijo es algo más potente:

"Los límites de la colaboración humana no son límites de la naturaleza humana, sino de la capacidad del management para descubrir cómo realizar el potencial de sus recursos humanos."

— Douglas McGregor, The Human Side of Enterprise

Frederick Herzberg añadió un matiz crucial: los factores que previenen la desmotivación no son los mismos que generan motivación. El salario, las condiciones de trabajo, la estabilidad — funcionan como el oxígeno. Si faltan, todo se para. Pero más oxígeno no te hace correr más rápido. Lo que realmente motiva es la autonomía, el dominio del oficio, el propósito, el reconocimiento del trabajo bien hecho.

La conexión es directa: una cultura Teoría X tiende a gestionar solo los factores higiénicos — más palo o más zanahoria. Una cultura Teoría Y se enfoca en los motivadores intrínsecos. Y la mayoría de organizaciones invierten enorme energía en optimizar factores higiénicos pensando que eso genera motivación, cuando lo único que hace es prevenir la desmotivación.

La inercia

Con más de un siglo de evidencia acumulada, uno esperaría que las organizaciones hubieran aprendido.

No lo han hecho.

Startups que escriben públicamente que apuestan por la autonomía, que el permiso ya lo tienes, que el sesgo es hacia la acción — y luego diseñan sistemas de evaluación trimestral con traffic lights, cuatro secciones cronometradas en cada reunión uno-a-uno, y calibraciones entre managers. El diagnóstico ocupa un párrafo y la receta ocupa diez páginas. Organizaciones intencionadamente planas que importan procesos diseñados para empresas con tres capas de management, sin preguntarse si el problema que esos procesos resuelven es un problema que ellas tienen.

No es un error de ejecución. Es un patrón. Las organizaciones tienden a imitar prácticas sin entender el contexto que las hizo funcionar — exactamente la misma tendencia que llevó a adoptar el waterfall como prescripción cuando Royce lo había descrito como un anti-patrón, o a convertir Agile en un sistema de certificaciones cuando sus creadores lo concibieron como un conjunto de valores.

Modern Times, Charlie Chaplin (1936)

Las empresas que sí han encontrado alternativas comparten un rasgo: invierten su energía en contratar bien y crear contexto, no en medir el rendimiento después. 37signals eliminó las review-360 después de probarlas durante 2 años — en cientos de evaluaciones, solo una vez hubo un seguimiento significativo. Netflix descartó las evaluaciones anuales formales por considerarlas ritualistas y burocráticas — Reed Hastings acabó titulando el libro sobre su cultura No Rules Rules. Shopify prohibió los KPIs en el sentido clásico de Silicon Valley; su CEO invoca la ley de Goodhart: en el momento en que una métrica se convierte en objetivo, deja de ser una métrica útil. Haier, con 80.000 empleados, eliminó 12.000 mandos intermedios y se reorganizó en 4.000 micro-empresas autónomas de 10-15 personas.

El denominador común no es la ausencia de estructura. Es que la estructura está al servicio del trabajo, no al revés.

Hay un hilo que conecta todas estas experiencias con una transformación más profunda en la forma de entender el liderazgo. David Marquet, comandante de un submarino nuclear estadounidense, lo articuló con una distinción simple: pasar de un modelo leader-follower a un modelo leader-leader. En vez de un capitán que da órdenes a una tripulación que obedece, un sistema donde cada persona tiene autoridad y contexto suficientes para tomar decisiones. Marquet no lo hizo por filosofía. Lo hizo porque en un submarino, si el capitán es el único que piensa, la gente muere.

Esa misma lógica recorre hoy las organizaciones de producto digital que funcionan. Marty Cagan lleva años insistiendo en la diferencia entre equipos que reciben funcionalidades que construir — feature teams — y equipos empoderados que reciben problemas que resolver. La diferencia no es semántica. Un equipo que recibe un encargo ejecuta. Un equipo que recibe un problema piensa. Es la distancia entre Schmidt cargando lingotes y el operario de Toyota que puede detener la línea.

No es casualidad que las organizaciones que mejor trabajan con software sean también las que más han invertido en distribuir la autoridad. El software es un material que exige pensar en cada capa — y si la capacidad de pensar está concentrada arriba, las decisiones llegan tarde, llegan mal, o no llegan.

Romper la cadena

Taylor quería encontrar "the one best way". Chaplin mostró adónde llevaba eso. Drucker dijo que con los trabajadores del conocimiento no funcionaría. Los firmantes del Manifiesto Ágil intentaron construir algo distinto y vieron cómo se convertía en una nueva versión de lo mismo. McGregor explicó por qué: los sistemas que diseñas revelan lo que piensas de tu gente, y lo que piensas de tu gente determina cómo se comporta.

El software desvanece nuestras aspiraciones de control integral sobre el resultado final. No es madera, ni metal, ni ningún material cuyo comportamiento podamos anticipar con precisión. Y las organizaciones que trabajan con él necesitan aceptar esa naturaleza en vez de combatirla. Las que lo consiguen no lo hacen encontrando el método correcto — lo hacen dejando de buscar uno.

La tuerca de Chaplin sigue ahí. La pregunta es si seguimos apretándola o empezamos a entender que el material que tenemos entre manos pide otra cosa.