Cómo liderar un equipo improductivo

Parece que te has enfrentado a un equipo que tiene poca o ninguna motivación y algunos malos hábitos. Como líder, debe comprender que tiene la responsabilidad de 1) establecer expectativas claras y alcanzables y 2) obligar a los miembros de su equipo a cumplirlas.

Su equipo ha tenido mucho tiempo para desarrollar sus malos hábitos, por lo que debe aclarar qué espera, por qué establece estas expectativas y cuándo deben demostrar que pueden cumplir con estas expectativas.

También debe documentar lo que su equipo está cumpliendo o no está haciendo. Hable con ellos 1-2-1 y tómese el tiempo para entender por qué también. Si un gerente anterior ha creado un ambiente de trabajo en el que hacer las cosas a tiempo no se celebra sino que se castiga con trabajo extra, o si un exlíder de tecnología dio un montón de malos consejos sobre aprender cosas nuevas, etc., intente comprenderlo y abordarlo de manera justa. Crear un ambiente de confianza y seguridad. A veces, un equipo fracasa porque la mala gestión o los compañeros tóxicos han creado un entorno en el que su comportamiento es la única forma de sobrevivir. Si ese es el caso, entonces puede cambiar las cosas ganándose su confianza, mostrando que cumplir con las promesas de entrega trae cosas buenas y que los escuchará y los ayudará, incluso cuando fracasen.

Si su equipo realmente se está demorando, no tiene una buena excusa y no cambiará, entonces sí, asegúrese de reunir suficiente evidencia de esto y no tenga miedo de despedir a la gente. Los malos empleados pueden tener un efecto no solo en el equipo inmediato, por lo que eliminarlos no solo le ahorrará dinero a la empresa, sino que también dejará espacio para otros que pueden aportar algo de valor.

Esta es una respuesta anecdótica, ya que he estado en su posición exacta. Perdón por la lectura larga, pero te da una idea de la situación en la que te encuentras, cómo puedes resolverla a veces y cómo a veces puede ser irresoluble.

Como consultor, fui contratado por una empresa para arreglar sus procesos de desarrollo. Rápidamente identifiqué una cultura de trabajo problemática con poca o ninguna orientación del desarrollador y un trasfondo tóxico. La solución a este problema se divide en dos categorías: los desarrolladores que tienen buenas intenciones y los que no.

la respuesta corta

¿Hay alguna forma de lidiar con equipos tan problemáticos?

Mientras los desarrolladores quieran mejorar y simplemente les falte orientación, entonces sí. Si activamente no quieren mejorar, entonces no.

Desarrolladores con buenas intenciones

Inicialmente, asumí que era ignorancia inocente. La empresa puso demasiado trabajo a todos los desarrolladores y sus malas prácticas (tomar atajos, escribir código descuidado, no realizar pruebas, ...) podría ser una forma de hacer frente a la carga de trabajo. Sin orientación, los desarrolladores junior desarrollarán malas prácticas sin darse cuenta de que hay una mejor manera, y si la presión es demasiado alta constantemente, no tienen tiempo ni esfuerzo para dedicarse a investigar si pueden mejorar sus (malas) prácticas.

Entonces, lo que hice fue profundizar en el trabajo real que hicieron. No solo observé la tarea en sí, sino también el código que cometieron, cuánto tiempo les llevó confirmar el código e investigué las correcciones de errores (después de que se implementó la corrección) para rastrear dónde ocurrió el error y cómo podría haberlo hecho. sido prevenido desde el principio.

Usando esa información, comencé a adaptar mis comentarios a los desarrolladores. En lugar de darles una regla teórica ("deberías hacer [cosa]"), usé su experiencia concreta ("Si hubieras hecho [esto], entonces [este último error] no habría ocurrido").

Todos los desarrolladores (excepto uno, al que me referiré) mejoraron de inmediato sus prácticas , los plazos se cumplieron con más frecuencia y los informes de errores disminuyeron significativamente. Esto me demostró que el problema aquí no era de ética laboral, sino de falta de orientación y gastos generales. Todos los desarrolladores han sido contratados por la empresa como junior, y todos aprendieron sus malas prácticas de desarrollo en esta empresa. Los que se quedaron se habían convertido en desarrolladores sénior, que a su vez capacitaban a los jóvenes recién contratados, lo que provocaba un ciclo recursivo de malas prácticas.

Si los desarrolladores tienen buenas intenciones, se trata de hacerles comprender los beneficios de una mejor práctica. Esto requiere ejemplos concretos y mejoras claramente perceptibles en la calidad de vida (tanto del código como de las tareas diarias del desarrollador), pero una vez que se muestran, los desarrolladores los aceptarán.

Pero, ¿y si tus desarrolladores son tóxicos o tienen malas intenciones? Aquí es donde llegamos al único desarrollador que no mejoró con la orientación.

Desarrolladores que no tienen buenas intenciones

El comportamiento de este desarrollador fue muy problemático. No realizar pruebas, escribir código en un idioma (francés) que la mitad del personal no habla, negarse a aprender nuevas tecnologías o enfoques, reclamar la propiedad exclusiva de su código y revertir activamente cualquier confirmación que haya tocado "su" código sin su permiso explícito. ridiculizando activamente a cualquiera que señalara una mejora en su código, depurando la base de datos de producción porque hacer una copia de seguridad lleva demasiado tiempo, ... la lista es interminable.

Sin embargo, este desarrollador fue calificado como el más alto por la compañía. No por sus prácticas, sino porque pudieron realizar proyectos en solitario. La empresa no entendía las prácticas de desarrollo, pero sí entiende el dinero, y un desarrollador que realiza proyectos en la mitad del tiempo parece muy rentable y debería ser recompensado, ¿verdad?
Lo que la empresa no se dio cuenta es que estos proyectos superaron con creces su fecha límite, ya que pasaríamos tres veces más tiempo reparando errores. A pesar de que la compañía pensó que estaban siendo más rápidos, no tuvieron en cuenta las correcciones de errores, ya que los informes de errores solo aparecían después de que el software tuviera su primer lanzamiento.

El problema era que el código de este desarrollador era tan de mala calidad e ilegible que nadie más que ellos podía trabajar con él, y había siete paquetes de software que solo podían ser compatibles con este desarrollador porque cualquier otra persona abogó de inmediato por una reescritura completa para evitar el festival de errores que fue. Esto llevó a la empresa a confiar en este desarrollador, lo que les dio una falsa sensación de superioridad y de que estaban haciendo lo correcto.

Cuando brindé orientación (bajo el supuesto de que era un desarrollador bien intencionado), me encontré con una negativa absoluta a seguir cualquier consejo. Ridiculizarían cualquier sugerencia de que su código podría mejorarse, discutirían sin fin sobre asuntos triviales como la sangría, y se negarían a escribir cualquier prueba como "pérdida de tiempo que deberían dedicar a corregir errores".
Después de semanas de no comunicarme, decidí arreglar su código para ellos (que no es mi trabajo) y luego discutir las mejoras con ellos con la esperanza de que ver las mejoras les mostraría que se podía hacer. Pero revirtieron activamente mis cambios y me gritaron en público por tocar su código.

En este punto, me dirigí al gerente. Los gritos eran inaceptables, pero lo que es más importante, estaba en un punto en el que no podría mejorar el rendimiento de este desarrollador a menos que "forzara físicamente sus dedos en el teclado para escribir un código diferente" (hiperbólicamente) y obligar a otros a hacerlo. cosas que no quieren hacer es obviamente inaceptable.
La pelota estaba en la cancha de la gerencia, necesitaban reprender (o amenazar con reprender) a este desarrollador porque se negaron por completo a siquiera considerar mejorar su trabajo. Ese es un problema de recursos humanos, no técnico.

Y la empresa nunca lo hizo . Me fui después de unos meses porque simplemente no quería lidiar más con la toxicidad. Más tarde descubrí que este desarrollador había estado chantajeando activamente a su empleador, amenazando con negarse a trabajar en los siete proyectos que solo ellos podían mantener, lo que le costaría a la empresa más de lo que estaba gastando en el salario del desarrollador. Y, por lo tanto, la empresa siempre cedía. Esto llevó a que los otros desarrolladores, que en realidad habían mejorado significativamente su proceso de desarrollo, también se rindieran, ya que estaban recibiendo una calificación más baja que este desarrollador de malas prácticas (y, por lo tanto, no se les dio ningún aumento o promociones). Lo último que supe es que, después de un éxodo masivo de desarrolladores, el desarrollador de malas prácticas ahora está capacitando a todos los nuevos empleados.

Este es un final un poco deprimente, pero cuando se trata de desarrolladores tóxicos o mal intencionados, el único recurso es hacer que la empresa corrija el problema, ya sea corrigiendo al desarrollador o despidiéndolo. Todo lo que puede hacer es evaluar la situación y proporcionar evidencia concreta de que este desarrollador tiene un desempeño deficiente y se niega activamente a cooperar con sus colegas.

Teniendo en cuenta la descripción que proporciona, especialmente el hecho de que todo el equipo tiene un bajo rendimiento y no solo un individuo, parece que este es un problema con el proceso y no con los desarrolladores individuales. Mi forma de abordar un equipo de bajo rendimiento:
1. Observar cómo está trabajando el equipo y cuáles son los problemas subyacentes
2. Hacer saber al equipo lo que se espera de ellos
3. Solucionar un problema tras otro

1. Observa

• Los plazos siempre se pierden entre dos y cuatro semanas.
• Las tareas de nivel junior pueden tomar una semana en lugar de un día o pueden no realizarse en absoluto.
• Incluso el código más simple comprometido para la revisión por pares puede quedar totalmente sin probar y romperse.

Estos son síntomas de que el proceso va mal, pero aún no conoce la causa raíz. No entraré en detalles para cada uno de estos puntos, ya que podrían ser preguntas individuales, pero tomando como ejemplo los plazos incumplidos, esto podría suceder debido a expectativas poco realistas, malas estimaciones, distracciones no planificadas, priorización incorrecta o cambio de enfoque.
Una de las primeras cosas que debes hacer es observar al equipo en su forma normal de trabajo y ver cómo van las cosas mal. Trate de identificar las causas fundamentales de los síntomas por los que está molesto el manejo. Hable con los miembros del equipo todos los días y póngase al día con la frecuencia que sea necesaria (por lo general, empiezo con encuentros individuales semanales con equipos que tienen un bajo rendimiento y luego paso a quincenales, cuando tengo más confianza en el equipo específico). miembro). Si hay muchas cosas que van mal, debes priorizar; trate de concentrarse en los que más molestan a la gerencia y que tienen el mayor impacto.

2. Establecer expectativas

Un intento de discutir el problema mostró la siguiente motivación:

• Fuerte prejuicio sobre el aprendizaje de cualquier nueva tecnología.
• No hay motivación hacia la responsabilidad por la calidad del código. Incluso tengo que discutir con ellos durante días solo para que arreglen su propio código después de los comentarios de revisión por pares.

Esto suele suceder cuando los miembros del equipo no ven una razón para cambiar. Podrían pensar "Así es como siempre trabajamos, y nos sirvió bien durante mucho tiempo". Tienes que matar esa actitud y hacerles saber que sus gerentes no están contentos con el desempeño del equipo y que están en juego. Sea consistente y claro en su mensaje, en lugar de comunicar demasiado que comunicar insuficientemente: si los plazos incumplidos y la mala calidad del código son los principales problemas, hable sobre los plazos y la calidad del código todos los días y durante las reuniones 1 a 1. "No podemos perder la fecha límite del 30 de abril". y "No puede haber forma de que presionemos una confirmación que no pase las pruebas unitarias en CI/CD"

3. Solucionar problemas Ahora que ha identificado los problemas y dejado claro el mensaje, puede solucionar los problemas. Tenga en cuenta que cambiar el comportamiento de un grupo es un proceso difícil y lento. Es posible que sienta la tentación de tratar de arreglar todo al mismo tiempo, ya que muchas cosas salen mal. Pero por cada cambio que haga, tendrá que hacer un seguimiento y repetir el cambio varias veces antes de que pueda convertirlo en un hábito. Solo introduzca tantos cambios que pueda hacer un seguimiento y que el equipo pueda adoptarlos. Prioriza las cosas según el resultado esperado y el tamaño del cambio. A menudo, el pequeño cambio correcto ya puede tener un gran impacto.
Por ejemplo, si el mayor problema del equipo son los plazos incumplidos y la causa principal de esto es que se eligen historias de baja prioridad que no contribuyen al proyecto principal, podría establecer como regla no seleccionar historias de baja prioridad si hay queda alguna noticia de alta prioridad. Luego, durante las próximas semanas, asegúrese de seguir esta regla en cada stand-up.
Habrá momentos en los que no se puedan seguir las reglas, esto a menudo puede conducir a problemas subyacentes aún más profundos con el proyecto y debe hacer un seguimiento de eso, hasta que el equipo pueda seguir el nuevo proceso y, con suerte, comience a ver algunos resultados. Después de ver que se implementan los primeros cambios, puede volver a evaluar la situación. Es posible que algunos problemas ya hayan desaparecido, otros aún pueden estar allí. Sigue cambiando una cosa tras otra y nunca dejes de mejorar...

Si todo va bien, no olvides seguir informando sobre el progreso a los superiores. La reputación de los equipos puede ser mala y los frutos de los cambios tardan en manifestarse. Asegúrese de mostrar que hay progreso y que la gerencia puede ser optimista de que el equipo se desempeñará a su satisfacción pronto. No desea esforzarse mucho, solo para ver que los desarrolladores se despiden de todos modos, porque no promocionó la mejora de los equipos lo suficiente.

Las otras respuestas ya son muy buenas. Pero para mí falta una cosa muy importante: primero debe averiguar por qué tienen un rendimiento tan bajo. Si asumes que lo hacen a propósito y simplemente no QUIEREN tener un mejor desempeño, entonces puedes dejar de leer aquí, entonces el único consejo puede ser: haz que los despidan... Pero más: trata de encontrar las verdaderas razones.

FALTA DE PLAZOS / TAREAS DE NIVEL JUNIOR

El incumplimiento de los plazos y la realización de tareas de "nivel junior" en mucho más tiempo del asumido pueden tener la misma razón:

¿Quién fija exactamente los plazos y clasifica las tareas como de "nivel junior"?

He recorrido este camino muchas veces con diferentes colegas: las tareas que considero fáciles y "se pueden hacer en un día", ya que soy un desarrollador experimentado en un campo especial, parecían imposibles de resolver o necesitaban un tiempo mucho más largo. para otros.
Había dos razones diferentes para esto:

1. Simplemente eran desarrolladores junior y no sabían cómo hacer esas cosas.
2. Eran desarrolladores experimentados pero en diferentes campos y simplemente no sabían lo suficiente en ese campo especial de experiencia.

Tener plazos que otra persona definió por su conocimiento y estimación puede ser muy frustrante, si no se ajustan a tus capacidades/estimaciones propias.
La solución para esto es incluir a los desarrolladores en el proceso de planificación: dejar que estén de acuerdo con los plazos y responsabilizarlos por su propia palabra.

CÓDIGO CALIDAD

La mala calidad del código puede ser un resultado directo de las líneas de tiempo tensas: si no puedo hacer mis tareas dentro del marco de tiempo asignado, entonces hago todo lo que puedo y dejo de lado todas las cosas "innecesarias" como probar o incluso intentar ejecutar mis programas

Entonces: déles la responsabilidad de establecer sus propios plazos y luego hágalos responsables de cumplirlos. Si aún no cumple con los plazos a pesar de que lo acordaron, entonces podría estar en la situación de dejarlos ir, ya que no pueden cumplir con expectativas muy importantes.

APRENDIENDO NUEVAS COSAS

Nuevamente: no querer aprender cosas nuevas PUEDE tener la misma razón: si uno ya tiene mucho que hacer para lograr sus objetivos, entonces podría rechazar aprender algo nuevo, ya que esto, al principio, ralentizará aún más el progreso y aumentará la presión porque de líneas de tiempo tensas...

TL; DR: Trate de quitar la presión de sus desarrolladores dándoles la oportunidad de influir en su propio trabajo / plazos / etc. Hable con ellos. Pida sus opiniones. Averigua porque. Luego decida cómo proceder.

Para producir resultados, se necesita habilidad y ética de trabajo. A tu equipo le falta uno o ambos.

La siguiente tarea para cada miembro del equipo es la revisión del código. Primero prueba si funciona (eso no es lo mismo que probar, eso es lo que hace el control de calidad, sino una comprobación básica). Si eso falla, la revisión falla y usted les dice que lo arreglen y que no pongan las cosas que no funcionan para su revisión. “Trabajar” es el primer requisito para el código. La próxima vez si no pasa aquí les preguntas qué probaron. Y lo que no probaron y manera. Deje en claro que el código que ni siquiera funciona no es aceptable. E insinúa que podría haber consecuencias. Como "Mi jefe no está contento con el desempeño de este equipo y me pregunta a quién sugeriría reemplazar".

Escribir un código que funcione no toma más tiempo que un código roto. Obviamente, como líder del equipo, dígales que usted está allí para ayudarlos si no pueden hacer que algo funcione. Todo esto debe ser un primer paso hacia la mejora.

pero todavía quiero tratar de superar el problema.

Es tu culpa, no estás dispuesto a tomar medidas disciplinarias cuando todo lo razonable ya ha fallado repetidamente. No estás haciendo bien tu trabajo. Con la responsabilidad vienen decisiones difíciles. O los haces o eres un problema como cualquier otra persona.