Article (tiempo de lectura: 7 minuto)

Es momento de llamar al desgaste de los programadores por su nombre: un fracaso del equipo directivo

Cuando un programador sufre el desgaste laboral, ha fracasado su líder.

Chris O’Malley / Onica, a Rackspace company

Al parecer, los programadores lo tienen todo. Al trabajar en la vanguardia de la transformación, son valorados y venerados, pero también son un sector particularmente vulnerable.

Los programadores desempeñan un papel exigente en la industria de la TI y el desgaste laboral es frecuente. Son maestros de la tecnología y, a la vez, aprendices eternos, siempre están al límite de trabajar en exceso y están expuestos a demandas no razonables y a objetivos que suelen ser inalcanzables. Delegar les resulta difícil por ser expertos en esencia y, como colaboran de forma estrecha, por ejemplo, con los equipos que desarrollan hardware, se los trata como un recurso altamente disponible y flexible. Como consecuencia, si lo comparamos, el tiempo y el esfuerzo de un programador pueden parecer prescindibles.

Como líder de programadores, y al ser yo mismo programador, he experimentado el desgaste en primera persona. Y como líder, quiero aclarar que el desgaste que sufren los programadores es un problema de los directivos.

Sin el soporte y la protección del equipo directivo, estos problemas se acumulan rápido, y los programadores se encuentran en un callejón sin salida en proyectos que los pueden llevar a su límite. Cuando ese talento que tanto le costó encontrar abandona la empresa (y quizás, incluso, la industria), los costos son altos para las empresas involucradas.

Los gerentes son quienes controlan los elementos que pueden provocar el desgaste de los programadores. Asignan el trabajo que hace la gente y establecen los incentivos que tienen para hacerlo; los gerentes influyen en la cultura en la que trabajan los programadores y le dan forma. Por lo tanto, cuando un programador sufre por el desgaste laboral, el líder le ha fallado. Es responsabilidad de los directivos reconocer los signos del desgaste desde el principio para poder intervenir e impedirlo a cualquier precio.

Si usted es líder en tecnología, es posible que estos comentarios contundentes le generen preocupación o, incluso, que lo pongan incómodo. Pero, en lugar de poner la atención en su persona, piense en su equipo. Aquí le explicamos cómo puede reconocer el desgaste de los programadores y evitar que se propague a todo su equipo.

Si es líder en tecnología, es posible que estos comentarios contundentes le generen preocupación o, incluso, que lo hagan sentir incómodo. Pero en vez de poner la atención en su persona, piense en su equipo.

Combating Developer Burnout

¿Qué provoca el desgaste de los programadores?

No siempre las largas horas de trabajo son las culpables del desgaste de los programadores. Seguro no ayudan, pero es la lenta acumulación de múltiples molestias, de magnitud o no, lo que crea el resentimiento asociado con el clásico desgaste.

Estas molestias tienden a tener su origen en una falta de control propietario, una falta de dominio o poder, o una falta de reconocimiento del aporte de un individuo.

Los escenarios de alto riesgo para el desgaste pueden incluir períodos prolongados de trabajo de alta intensidad donde los logros, es decir, el envío de códigos, son escasos y espaciados. Mantener el código heredado es otro ejemplo típico. El programador que trabaja en el código heredado no es casi nunca la persona que lo desarrolló en primer lugar, por lo que no le pertenece. Ahora está atascado sin parar arreglando errores y sabe que lo que realmente necesita es una recodificación, una decisión que no puede tomar y que no puede influir para que alguien la tome. Además, el trabajo tiene un valor bastante bajo, lo que hace poco probable el reconocimiento en este campo.

El desgaste de los programadores también puede deberse a la falta de confianza en la compresión por parte del equipo de productos de los requisitos de los clientes, la falta de control que un programador puede tener sobre su cronograma o la falta de participación en las decisiones que afectan al programador. Estos son todos campos fértiles para que crezca el resentimiento.

Antes mencioné que el envío de código es un logro que mantiene contentos a los programadores. Sin embargo, es importante recordar que hay excepciones a esta idea. Si los programadores dedican tiempo a programar y enviar código a la función incorrecta o a una función que nadie usa, es probable que se sientan tan poco inspirados como si no hubieran enviado ningún código.

Otro escenario para tener en cuenta es el siguiente: resulta estresante si los líderes ejecutivos, de ventas y de marketing tienen la libertad de pasar por alto el tiempo del programador. De manera similar, si no pueden hacer recomendaciones relacionadas con la arquitectura o no participan en la toma de decisiones de alto nivel, es probable que sus programadores comiencen a mostrar síntomas de desgaste.

Los tres tipos de programadores con síntomas de desgaste y los tipos de personalidad a los que debe prestar atención

Es importante hacer hincapié en que el desgaste puede manifestarse en cualquier persona y, de hecho, es lo que ocurre. Sin embargo, he descubierto que los tipos de personalidades adictas al trabajo con carácter exhaustivo son más propensas al desgaste que otras. Estas personas son muy curiosas y siempre quieren dar más de la cuenta. Cuando están en un buen momento, representan un activo para todo equipo.

Pero esa curiosidad puede fácilmente desviar el enfoque del programador adicto al trabajo de lo que es importante en este momento. Cuando eso sucede, los verá haciendo malabares con cuatro o cinco cosas a la vez, hasta que llegan a dedicar 60 horas semanales para poder mantener el ritmo. Estos programadores no necesitan de la microadministración, sino de gerentes que estén atentos a este escenario y que puedan ayudarlos a poner prioridades y mantenerse enfocados.

Cuando se manifiesta el desgaste, en general, he visto surgir como consecuencia a uno de estos tres tipos de programadores con síntomas de desgaste: el programador enojado, el programador retraído o el programador sin rumbo.

El programador enojado es distante, no acepta bien el feedback y se convierte en una persona que discute y no colabora. El programador retraído deja de participar en reuniones o no hace contribuciones en aquellas a las que asiste. De pronto, ya no es fácil de contactar por correo electrónico ni por Slack, y sus publicaciones de código se vuelven menos frecuentes, superpequeñas o carecen de detalles. Luego está el programador sin rumbo, que tiende a investigar de manera exhaustiva cuando las tareas son simples y tarda mucho más de lo necesario en hacer las cosas mientras rechaza ayuda, incluso, cuando las tareas sin terminar se acumulan.

Evitar el desgaste laboral es mejor, más sencillo y más económico que abordarlo

El desgaste puede parecer repentino, pero nunca surge de la nada. Siempre hay cambios en el comportamiento que indican que alguien corre el riesgo de enojarse, retraerse o perder el rumbo. El desafío del equipo directivo es crear tanto oportunidades para que ellos mismos detecten estas señales, como el espacio para que los programadores transmitan sus preocupaciones o expresen sus opiniones mucho antes de que se conviertan en quejas.

Las reuniones personales regulares e intencionadas son una herramienta vital para evitar el desgaste. Más que un simple encuentro con el jefe, estas sesiones deben centrarse en entender lo que los programadores quieren de su carrera profesional, a fin de que usted pueda diseñar proactivamente eso que buscan. Los líderes deben desarrollar confianza poniendo en práctica los resultados de esas reuniones, orientando a los programadores al trabajo que desean y alentándolos a realizar la capacitación que les interesa.

En segundo plano, los líderes deben monitorear de cerca las cargas de trabajo. También necesitan aportar variedad al equipo de programadores al mantener a la gente activa. Y los líderes no deben olvidarse de brindar support a los intereses personales y profesionales de los individuos tanto como sea posible. Cualesquiera que sean los desafíos a corto plazo que puedan causar, no son tan importantes en comparación con las consecuencias que debilitan la moral y la productividad, y que trae aparejado el hecho de tener un equipo con síntomas de desgaste.

Cuando se produce el desgaste y uno se ve obligado a intervenir, es importante estar preparado y tener opciones. Si nota un cambio de comportamiento, probablemente sea muy tarde para decir: "Parece que está atravesando alguna dificultad. Hablemos de ello". Piense en las acciones que podría hacer en su lugar: ¿puede excluirlo de un proyecto problemático? ¿Puede reducir su carga de trabajo, hacer que se tome tiempo libre y limitar sus horas cuando regrese?

El equipo directivo es responsable del desgaste

Los beneficios de mantener la motivación del programador son tan obvios que dudo en mencionarlos. Si tiene un equipo experimentado que conoce su pila y conoce sus sistemas, un equipo que está contento, es competente y está dispuesto a hacer el trabajo, entonces, enviará el producto más rápido. Tendrá más éxito.

Por otra parte, los riesgos del desgaste son graves para las organizaciones y sus líderes. La insatisfacción de los clientes y de los usuarios se producirá con bastante rapidez, a medida que la calidad disminuya y las pérdidas empiecen a aumentar. Si los recursos importantes para el desarrollo no abordan los problemas de manera metódica, el rendimiento se verá afectado, y ello repercutirá más en la moral. La mala energía de una persona puede propagarse rápidamente a través de una organización o de un equipo, y puede arruinar la cultura y afectar la contratación y la retención de personal.

Es posible que, a veces, los programadores no se ayuden a sí mismos, ya que asumen demasiado por la gran confianza en sus habilidades y el impulso natural para resolver problemas. Pero la función de la gerencia es aprovechar los aspectos buenos de este instinto y filtrar los malos. Pueden hacerlo incorporando las medidas culturales que dan prioridad a la variedad, proporcionan un feedback significativo y permiten que las personas hagan su aporte todos los días.

Y deberían hacerlo porque el equipo directivo es responsable del desgaste.

Únase a la conversación: encuentre Solve en Twitter and LinkedIn, o síganos en RSS.

Acerca del autor

Gerente sénior, Práctica de Desarrollo Nativo de la Nube Chris O’Malley

Chris O’Malley es gerente sénior en la práctica de Desarrollo Nativo de la Nube (CND) en Onica, una empresa de Rackspace. Chris trabajó en varias empresas emergentes y ocupó muchos puestos, entre ellos, diseñador de PCB/hardware y programador...

Más


Serie Solve Strategy

Inscríbase en uno de estos eventos mundiales, o en todos, en los que participarán personas influyentes, expertos, técnicos y líderes de la industria

Inscribirse