008. No falla tu equipo: falla el sistema

Vamos a empezar imaginando una escena que estoy segura de que a muchísimas de las personas que nos escuchan hoy les va a resultar dolorosamente familiar. A ver, ¿de qué se trata? Fíjate, contratamos a un equipo brillante. Buscamos a los mejores profesionales del sector, gente con un talento indudable, una motivación altísima y un compromiso a prueba de balas. Claro, el famoso equipo estrella, ¿no? Exacto. Los ponemos a trabajar juntos en un departamento de servicios que es clave para la empresa y de repente el desastre absoluto.

Los plazos empiezan a saltar por los aires. Eso es, los plazos vuelan, las quejas de los clientes se acumulan en la bandeja de entrada y ves cómo el agotamiento, ese famoso burnout, se dispara de forma brutal entre esa gente tan brillante. Y claro, la reacción casi automática desde la dirección suele ser pensar, bueno, pues que esta gente ha perdido la motivación. O lo que es peor, que hay que exigirles que hagan un esfuerzo extra, que se queden más horas. Que es el diagnóstico clásico.

Sí, sí, el clásico y a la vez el más destructivo, porque inmediatamente se asume que el fallo es una cuestión de actitud o, digamos, de falta de voluntad del individuo. Pero a ver, si analizamos la realidad operativa de las empresas, los datos nos demuestran una y otra vez que el problema casi nunca está en las personas.

O sea que el verdadero culpable es otro. Totalmente. El culpable suele ser un sistema de trabajo terriblemente mal diseñado que básicamente ahoga cualquier intento de hacer las cosas bien. Y precisamente esa es la misión de nuestra inmersión a fondo de hoy. Vamos a desgranar los conceptos centrales del libro Cómo transformar empresas de servicios con Agile, Scrum y Talk.

Y también sus bonus tracks, del autor José Manuel Hernández Agudo. Un material súper revelador, la verdad. Sí, sí. Y el objetivo es analizar con total objetividad y basándonos estrictamente en este material.

¿Por qué la gestión de personas necesita abandonar ya esa visión industrial de tratar a los profesionales como si fueran simples recursos humanos intercambiables? Como si fueran piezas de un engranaje, claro. Exactamente. Queremos ver qué funciona y qué no a nivel de sistemas operativos y cómo crear un contexto donde la gente pueda dar lo mejor de sí misma.

Porque, en el fondo, gestionar no es repartir tareas en una hoja de Excel y esperar que el trabajo salga, por arte de magia. Se trata de entender la mecánica del trabajo diario en empresas que no fabrican tornillos, sino que ofrecen conocimiento. Fíjate, para visualizar este cambio de mentalidad, me encanta usar la analogía del jardín. Ah, me gusta. A ver, cuéntame.

Pues que si tienes un huerto y ves que los tomates no están creciendo, tu primera reacción no es ponerte a gritarles a las plantas para que crezcan más rápido. Ya, ni les pides que hagan horas extra, ¿no? Claro, no les exiges un esfuerzo extra ni las castigas. Lo que haces es mirar el entorno. Compruebas si la tierra tiene los nutrientes adecuados, si les llega agua, si hay demasiada sombra.

O sea, te dedicas a diseñar el contexto. Eso es. Y sin embargo, en el mundo corporativo parece que seguimos gestionando a los equipos como si fueran máquinas tragaperras. Les metes tareas por una ranura y esperas el premio. Es una locura, sí. Entonces, si el entorno lo es todo, ¿por qué crees que seguimos cayendo en ese espejismo de gestionar, entre comillas, recursos? Pues, a ver, fundamentalmente porque es una herencia directa de las fábricas de principios del siglo XX.

En una línea de montaje tradicional, si quieres producir el doble de coches, simplemente aceleras la cinta o añades más operarios. La lógica puramente lineal. Exacto. Maximizar la capacidad exprimiendo al recurso. Pero el problema monumental llega cuando trasladamos ese modelo mental a entornos de servicios, a desarrollo de software.

Atención al cliente. Ahí esa lógica lineal salta por los aires. Claro, no es lo mismo apretar tuercas que resolver un problema técnico complejo. Para nada. De hecho, el libro se apoya fuertemente en la teoría de las restricciones, conocida como TOC por sus siglas en inglés, que fue creada por Eliyahu M. Goldratt.

Y lo que nos enseña TOC aquí es fastidante. ¿El qué exactamente? Pues que el mayor cuello de botella en una organización de servicios rara vez es un servidor antiguo o un programa informático lento. La verdadera restricción suele ser, fíjate, el propio diseño humano del trabajo. A ver, me voy a poner en el papel del abogado del diablo por un momento, ¿vale? Venga, dispara. Porque si yo le digo a alguien que trabaja en soporte informático o, no sé, en atención al cliente...

Que su gran problema es el diseño del trabajo, pues igual me mira mal. Ya, te dirá que no tienes ni idea de su día a día. Claro. Me dirá, oye, mi realidad es que las urgencias son el pan de cada día. Si un servidor...