En decenas de empresas grandes y medianas de casi toda Latinoamérica he visto el mismo paradigma de gestión: comando y control. Jerarquías claras, especialistas en cada área, decisiones que bajan desde arriba.
Y casi siempre, la conclusión de la gerencia es la misma: ni la jerarquía ni la especialización van a cambiar.
¿Y por qué deberían? Ese paradigma les ha traído ganancias durante décadas. Les ha permitido crecer hasta tener miles de trabajadores y generar resultados sostenibles. Sería ingenuo pedirle a una empresa que abandone lo que la hizo exitosa.
Pero hay un problema: ese paradigma nació para resolver otro tipo de desafíos. Para entender por qué, vale la pena hacer un viaje rápido por la historia del management.
Una breve historia del management
Adam Smith: la especialización
En 1776, Adam Smith describió en La riqueza de las naciones cómo una fábrica de alfileres multiplicaba su producción dividiendo el trabajo en tareas especializadas. Cada persona hacía una sola parte del proceso, y la hacía cada vez mejor.
La idea cambió el mundo: trabajar con especialistas se volvió sinónimo de eficiencia.
Napoleón: el comando y control
Los ejércitos de la era napoleónica perfeccionaron otra idea: una cadena de mando clara, donde las órdenes bajan desde arriba y se ejecutan sin discusión. Permitía coordinar a miles de personas con rapidez y disciplina.
Las organizaciones adoptaron el modelo. Comando y control se convirtió en la forma natural de dirigir una empresa grande.
Frederick Taylor: el procedimiento
En 1911, Frederick Taylor publicó Los principios de la administración científica. Su propuesta: estudiar cada tarea, encontrar la mejor forma de hacerla y convertirla en un procedimiento que todos deben seguir.
Separó a quienes piensan de quienes ejecutan. Y funcionó: la productividad industrial se disparó.
Taiichi Ohno: primero la gente
Después de la Segunda Guerra Mundial, Taiichi Ohno desarrolló en Toyota un sistema de producción que dio un giro importante: primero la gente. Los trabajadores dejaron de ser ejecutores de procedimientos y pasaron a ser quienes detectan problemas y mejoran el proceso. Cualquier persona podía detener la línea si veía un defecto.
Fue el inicio de una forma distinta de pensar la gestión, que muchas empresas de occidente tardaron décadas en entender.
El Manifiesto Ágil: equipos, clientes y adaptación
En 2001, un grupo de profesionales del software firmó el Manifiesto Ágil. Lo que muchos ven como un documento técnico, yo lo considero algo más grande: una innovación en management nacida del software.
Puso en el centro a los equipos, la colaboración con el cliente y la capacidad de adaptarse al cambio. Steve Denning lo resume en lo que llama las tres leyes de la agilidad: la ley del equipo pequeño, la ley del cliente (estar cerca del mercado) y la ley de la red (la comunicación fluye entre equipos, no solo hacia arriba y hacia abajo).
Cada paradigma resolvió un problema distinto
Mirando esta historia, hay algo importante: ninguno de estos paradigmas está “equivocado”. Cada uno nació para resolver un problema de su época, y lo resolvió bien.
La especialización y el comando y control funcionan muy bien cuando el trabajo es predecible, repetible y se conoce de antemano: producir en masa, operar procesos estables, ejecutar lo que ya se sabe hacer.
Pero el desarrollo de nuevos productos y la innovación son otra cosa. Ahí nadie sabe con certeza qué va a funcionar. Hay que descubrir, probar, equivocarse y adaptarse. Y para ese tipo de trabajo, los paradigmas del siglo XIX y XX no alcanzan.
El error: mezclar paradigmas
Aquí es donde las cosas salen mal en muchas empresas.
La gerencia aborda todos los desafíos con lo que conoce y con lo que le funcionó en el pasado. Entonces, cuando decide “hacer Scrum”, lo hace con las herramientas del paradigma anterior. Y se mezclan los paradigmas.
El ejemplo más común: se forman equipos Scrum con especialistas (el analista, el diseñador, el backend, el frontend, el tester) y se les pide avanzar rápido.
Lo que no se ve es que trabajar con especialistas equivale a trabajar en cascada. Cada especialista espera a que el anterior termine su parte. El trabajo pasa de mano en mano. Se forman cuellos de botella: el tester está saturado al final del Sprint mientras el analista no tiene nada que hacer. Unos esperan, otros se ahogan.
El equipo tiene nombre de Scrum, eventos de Scrum y tablero de Scrum. Pero por dentro sigue funcionando como una línea de producción de Adam Smith.
La salida no es eliminar la especialización, sino complementarla. Cuando las personas desarrollan una segunda o tercera especialidad, pueden ayudar en más de un tipo de trabajo y el equipo se balancea solo. La idea es optimizar el equipo para el bien del equipo, no para la comodidad de cada individuo.
Lo mejor de ambos mundos
Entonces, ¿hay que desmantelar la jerarquía y la especialización para ser ágiles?
No. Y no es lo que yo enseño.
Lo que enseño es a sacar partido de ambos mundos. Mantener el enfoque tradicional que le ha dado resultados a la empresa, donde sigue funcionando, y a la vez habilitar estructuras paralelas, solo cuando convenga.
Dentro de esas estructuras paralelas es donde pueden existir equipos Scrum enfocados en lo que el paradigma tradicional no resuelve bien:
- La innovación.
- El desarrollo de nuevos productos.
- La resolución de problemas complejos.
La operación estable sigue funcionando con la estructura que la hizo exitosa. La innovación funciona con una estructura pensada para descubrir y adaptarse. Cada paradigma, donde mejor funciona. Es una idea cercana a lo que John Kotter llama un sistema operativo dual: la jerarquía y una red ágil conviviendo dentro de la misma organización.
¿Y la IA?
La historia del management no terminó en 2001. Hoy estamos viviendo otro cambio: la inteligencia artificial está absorbiendo una parte creciente del trabajo técnico y especializado.
Si buena parte de lo que hacían los especialistas puede hacerlo la IA, la especialización deja de ser la gran ventaja que fue desde Adam Smith. Lo que se vuelve escaso es otra cosa: la capacidad de las personas de colaborar, decidir juntas, entender al cliente y adaptarse.
Es decir, exactamente lo que la agilidad vino a poner en el centro. Por eso creo que la IA no reemplaza a la agilidad: la vuelve más necesaria que nunca.
Diseña la estructura que tu empresa necesita
Acompaño a empresas a diseñar estructuras paralelas donde la agilidad pueda funcionar, sin desmantelar lo que les ha dado resultados. Y en mis cursos de Certified Scrum Product Owner trabajamos cómo pasar de la mentalidad del paradigma tradicional a la del desarrollo de productos.
👉 Conoce nuestra consultoría en cambio organizacional · Próximos cursos
