Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación
Lo más bonito de mi trabajo es que los clientes no dejan de sorprenderte nunca. Hace unos días llegue a un cliente, en el que recientemente hemos arrancado un piloto de un equipo. De las primeras cosas que llamaron mi atención fue ver tres líneas diferentes en su burndown chart. Tras preguntar, el jefe de desarrollo y el Scrum Master del equipo, me contaron, no sin cierto pudor, que las líneas representaban diferentes grados de cumplimiento de los objetivos del sprint, ¡cómo si fuese posible cumplir en diferentes medidas el trabajo comprometido para un sprint!.
Me reacción fue de clara contrariedad. Ellos sabían que la cosa no me iba a hacer gracia, pero se veían en la necesidad clara de ¡motivar al equipo!. Yo sabía que no era buena idea intentar ‘motivar’ al equipo prometiéndoles recompensas económicas por cumplir ‘más’ el sprint. Lo sabía porque ya había sufrido estos intentos de ‘motivarme’ durante mi carrera profesional y siempre habían tenido resultados dañinos. Lo sabía empíricamente, pero claro, cuanto te pagan por tu conocimiento, generalmente, no vale solo con decir, ‘tu idea no vale porque yo ya la he visto fallar’. Se espera una respuesta más analítica. Les apunté un artículo de Joel Spolky sobre el tema, titulado, Los pagos de incentivos considerados dañinos, pero me quede con la sensación de no haber respondido a su necesidad. La gente cuanto te paga por responder preguntas y ayudarles no quieren solo saber que puede pasar y como debe actuar sino los porqués…
La siguiente cuestión que se puso sobre la mesa fue: ¿tú qué haces para motivar a tu equipo? Mi respuesta es clara: tratar de no desmotivar. Hace tiempo leí o alguien me conto, que una buena forma de actuar es tratar de no hacer lo que a ti te han hecho y te ha desmotivado. Y a eso me suelo ceñir en lo que ha motivación se refiere.
Automáticamente me di cuenta de una realidad: ¡No sabía gran sobre la motivación! Y la motivación es el factor que más influye en el rendimiento de un equipo de desarrollo, eso sí que lo tengo muy claro, gracias al trabajo de Boehm que Steve McConnell refleja en sus libros que yo he leído con deleite. Si queremos equipos motivados no es para ser nominados a gestores del año, no, es simple egoísmo (léase sin connotaciones negativas) económico. Los desarrolladores motivados producen más.
En esta tesitura, tras dejar al cliente y llegar al aeropuerto, en una de esas casualidades que tiene la vida, mirando libros en el aeropuerto, tras el enésimo retraso del Vueling, encontré ‘La sorprendente verdad sobre qué nos motiva’ de Daniel H. Pink. Y ahora, unos días después de devorar el libro, puedo escribir este post.
¿Por qué mi intuición de que ofrecer dinero a un equipo de desarrollo por completar más historias que las comprometidas para un sprint no funciona es cierta?
Lo que debemos saber es que hay dos tipos de labores que los empleados pueden realizar. Hay tareas que son algorítmicas, que consisten en repetir una determinada receta para lograr un determinado objetivo productivo sin cabida para la creatividad o tareas heurísticas en las que el componente creativo es un factor relevante. ¿Alguien duda de que el desarrollo de software es una tarea de creación? Desarrollar software exige tomar continuamente decisiones de diseño. Cada línea es una decisión de diseño o varias. No es para nada una tarea repetitiva. Un desarrollador está continuamente solucionando problemas.
Hay un experimento esclarecedor descrito en el libro de Pink que demuestra científicamente que para tareas que requieren de creatividad y de dotes de resolución de problemas los incentivos económicos son dañinos. El experimento consistió en proponer a dos grupos de personas la resolución de un problema, el problema de la vela, cuyo planteamiento y solución podéis ver en la siguiente imagen, que exige cierta componente de pensamiento creativo. Se trata de sujetar la vela a la pared sin derramar una sola gota de cera. La solución una vez la conoces parece obvia, pero exige cierto pensamiento lateral para ver que es necesario sacar los clavos de la caja y que no es necesario usar las cerrillas.
A un grupo se le dijo que se le pagaría una cantidad si lograba resolver el problema, y a otro no. Sorprendentemente, el grupo remunerado obtuvo peores resultados a la hora de resolver el problema. El experimento demuestra que el hecho de establecer una recompensa económica automáticamente desvía nuestra atención de resolver el problema a obtener la recompensa.
El libro de Pink describe un motón de experimentos similares que llegan a una conclusión que es contraintutiva: tratar de motivar el trabajo mediante incentivos económicos solo funciona para tareas muy simples. Y desarrollar software no es una tarea simple. Además y de manera sorprendente, los incentivos económicos no solo no mejoran el rendimiento de los equipos de desarrollo, sino que además, a menudo ¡lo empeoran!. Es curioso ver en libro ejemplos de investigaciones que demuestran resultados muy ‘extraños’: incentivar económicamente la donación de sangre se traduce en una menor tasa de donaciones, los artistas realizan obras de peor calidad cuando están trabajando por encargo, los escolares que reciben un diploma por pintar pierden el interés por esta actividad… ¡cuando menos sorprendente!. Esto resultados ponen en evidencia la creencia general en gestión de que las personas respondemos al palo y la zanahoria, a un esquema de incentivos y castigos.
Para conocer el porqué hay que tener en cuenta que existen dos tipos fundamentales de motivación: la motivación extrínseca, es aquella que aparece cuando lo que atrae no es la acción que se realiza en sí, sino lo que se recibe a cambio de la actividad realizada (por ejemplo, dinero, comida o cualquier otra forma de recompensa) y la motivación extrínseca, que aparece cuando el individuo realiza una actividad por el simple placer de realizarla, sin que nadie de manera obvia le de algún incentivo externo. Cuando hablamos de trabajos en los que la creatividad juega un papel, la motivación intrínseca es sumamente importante, muchísimo más que la motivación extrínseca. Y lo que es más relevante, la motivación extrínseca forzada daña el rendimiento en este tipo de actividades.
No hay mejor manera de convertir un trabajo interesante y motivador en una pesada carga que tratar de incentivarlo. Si a un desarrollador le ofreces incentivos por realizar su trabajo, automáticamente le estas lanzando el mensaje de que el trabajo que realiza no debe despertar en él el interés suficiente por si mismo. Todos los desarrolladores odiamos los trabajos que no son interesantes, que no plantean un reto o una oportunidad de aprendizaje. Evidentemente en el desarrollo de software hay muchos trabajos que son repetitivos, pero por suerte, esto son susceptibles de ser automatizados, pedir a un desarrollador que automatice un trabajo repetitivo es mucho más productivo que remunerarle por realizar un trabajo que considera desagradable.
La psicología ha dado la explicación a algo que se sabía hace mucho tiempo. Fijaros en los factores que motivan a los desarrolladores, descubiertos por Barry Bohem hace décadas, tal y como aparecen en recomendable artículo Best Practices to Increase Productivity and Decrease Turnover de Janet Amirault:
El salario, en el caso de los desarrolladores de proyectos y los gestores aparece en el noveno lugar, tres más abajo que para la gente en general. Vamos que intentar motivar a desarrolladores con dinero, no da buenos resultado, hay factores mucho más influyentes y adecuados.
El corolario, expresado por Pink en su libro es que debemos recordar siempre que los incentivos basados en ‘si haces esto obtendrás aquello’ pueden eliminar la poderosa motivación intrínseca, reducir el rendimiento, dañar la creatividad, apartarnos de una conducta adecuada para lograr los objetivos volverse adictivos (necesitándose mayores y mayores incentivos cada vez) y potenciar el pensamiento cortoplacista.
Veamos qué escenario nos encontraríamos si cogemos un equipo y le ofrecemos dinero por terminar más historias de las comprometidas para un sprint. Para empezar, algo que es una meta loable, conseguir los objetivos marcados, algo a lo que nuestro ‘buenismo’ natural nos empuja, se convertiría en algo por lo que debemos ser sobre compensados. Implícitamente es admitir que el trabajo no es interesante, o no es motivador por si mismo o que los objetivos solo son factibles con una sobre motivación. Además la gente, como demuestra el experimento de la vela la gente se concentraría en fin, y olvidaría los medios. El fin de obtener el objetivo haría que fuésemos menos eficientes en el proceso de obtenerlo. Además seguro que algunos desarrolladores, sino todos, tomarían atajos de calidad, o no escribirían test unitarios o actualizarían la documentación solo para cerrar un historia más y obtener la recompensa, sutilmente estaríamos recompensando comportamientos anómalos. En el hipotético caso de que los incentivos funcionasen a corto, nunca funcionarían a largo plazo, pues cada vez serían necesarias mayores dosis para lograr los mismos resultados, algo insostenible económicamente.
Lo que si funciona, siempre administrándolo con juicio, son las recompensas no esperadas. Y sobre todo, aunque parezca mentira, lo que más funciona, es el reconocimiento al trabajo bien hecho. Un simple reconocimiento explícito es lo que mejor resultado da según muestran los estudios que Pink muestra en su libro.
Creo que después de todo, mi táctica de simplemente tratar de no desmotivar, es más que acertada. Y creo que la táctica de las metodologías ágiles de establecer metas claras, dar voz a los desarrolladores y permitir la excelencia son poderosos catalizadores de la motivación intrínseca.
Por si este post no ha despertado suficiente interés en vosotros sobre este tema, os dejo un video (en inglés) resumen brutal del libro de Pink, espero que lo disfrutéis:
¿A vosotros que os motiva?.
P.D.: Los videos con subtítulos en español (La soprendente verdad sobre los que nos motiva 1/2 y La sorprendente verdad sobre lo que nos motiva 2/2).