Cómo plantear tácticamente al Gerente del Programa que el Líder del Equipo es parte de los problemas en el trabajo

Antes de responder, te advierto que comencé mi carrera en un contratista de defensa para el Departamento de Defensa (DoD) en los EE. UU., y estoy de acuerdo contigo, la cultura en estos lugares es bastante tradicional, formal y resistente a los cambios modernos. Tuve un líder de equipo que es más o menos igual que el suyo: falta de capacidad de respuesta, falta de voluntad para guiar al equipo, vacilación para usar nuevos métodos, etc.

No me veía prosperando en un entorno tan sofocante, así que me fui y mi carrera ha progresado muy bien. Ahora, donde trabajo, hay una cultura de apertura sin una jerarquía rígida. De hecho, se alienta a los empleados a sugerir nuevos métodos de trabajo siempre que sean razonables. Los miembros superiores y la gerencia son vistos como mentores, sin mandar desde arriba para ser obedecidos. Dejar a su empleador puede no ser la mejor opción para usted, pero debe considerar hacerlo si la cultura no encaja.

Dicho esto, me centraría en indicar los problemas que ve directamente. No mencione nombres, pero diga claramente lo que ve como problemas y cómo están perjudicando su productividad y al cliente, como los plazos incumplidos. Deje claro que desea trabajar con el administrador del programa y aprender de su riqueza de conocimientos. Sé que esto puede alterar las plumas del líder de su equipo que estará presente en dicha reunión, pero creo que vale la pena, ya que, en mi opinión, actualmente el líder de su equipo no está haciendo su trabajo. No está sirviendo como maestro para el equipo, brindando orientación sobre las mejores prácticas o asumiendo los problemas del equipo. Según tu descripción, parece bastante desprotegido.

Los felicito por ser proactivos y tener el coraje de hablar. Está claro que te importa, y eso es bueno. Según cómo transcurra la reunión con el director del programa, puede convertirse en su aliado para impulsar el cambio. Cuando vaya a la reunión, sea optimista, él será receptivo a sus sugerencias, pero espere que no haya cambios, ya que dijo que también proviene de un fondo de contratos de defensa.

Claramente, escalar los problemas a la gerencia y ofrecer soluciones no es poco profesional en mi opinión. Sin embargo, saber que su productividad y los clientes están sufriendo y no escalando es, al menos, no mostrar iniciativa en su rol.

tl;dr Aprovechar la primera oportunidad con alguien muy senior que acaba de unirse a la empresa para quejarse de su (también muy senior) líder es una forma muy rápida de encontrarse etiquetado como tóxico y ya no estar empleado.

Veamos algunos puntos aquí. Llevas un año, el lead lleva 15. No hablas de cuánto tiempo llevas en la industria, pero el post me parece "poco". Entonces, sugiero tomarse un tiempo después de que llegue el chico nuevo para leer un poco la habitación antes de comenzar a disparar desde la cadera.

La falta de formación formal...

Muchos lugares no hacen ningún entrenamiento formal en absoluto. ¿Qué esperas aquí? ¿Está esperando que lo envíen a un curso de Cloud Foundry de 8 semanas porque está buscando un PoC para ello?

varios líderes de equipo no "se toman en serio" la búsqueda de mejores formas de hacer las cosas mediante la implementación de varias herramientas de DevOps. La actitud que se observa una y otra vez es seguir haciendo lo que estamos haciendo. No cambies nada.

¿Qué cuenta como "ser serio" aquí? ¿Simplemente implementando las herramientas que desea utilizar? Esto dice "varias" herramientas también. ¿Qué quieres decir con eso? Sugiera algunas cosas y obtendrá muchas opiniones diferentes de los profesionales de DevOps. Cambiar por el simple hecho de cambiar, o ser "vanguardista" no es una gran idea. La mitad del sistema financiero se ejecuta en COBOL porque es sólido y tiene décadas de errores corregidos.

Falta de planificación para pasar de Máquinas Virtuales a Contenedores y una Orquestación en este producto de software, lo que ha causado retrasos en las fechas de entrega al cliente.

Los contenedores y la orquestación de contenedores no son un requisito. Las máquinas virtuales siguen siendo excelentes para una gran parte del software en ejecución y en desarrollo en este momento. ¿Este cambio ya forma parte del plan? ¿El cliente quiere esto?

Resistencia a Agile y Scrum, que solo se ha implementado en los últimos 6 meses, junto con abrir tickets en Jira y documentar problemas en esos tickets y cerrar tickets cuando el trabajo esté completo.

El cambio de proceso requiere tiempo, compromiso y aceptación de que habrá algunas fallas durante el cambio. "Agile/Scrum" no es una bala de plata, y si al nivel superior no le importa, tampoco lo hará el líder.

Falta de compromiso de los líderes de equipo con los compañeros de trabajo.

Quiero decir, es posible, pero podría ser tu percepción. Puede ser que no interactúen contigo. Este tipo de queja es común, pero es extremadamente personal, y muchas veces se reduce a "quiero que me consulten constantemente por cosas".

Rotación constante de empleados debido a varias razones (yo mismo he anunciado a otros reclutadores de TI que me gustaría seguir adelante, junto con muchos otros empleados nuevos).

Se espera una rotación constante. La permanencia promedio en las empresas de desarrollo puede ser de ~2 años. La gente salta de trabajo por ese aumento salarial mágico del 20% que siempre parecen obtener. Si quieres seguir adelante, entonces debes seguir adelante. El mercado está caliente, especialmente para los profesionales de DevOps. Si no encuentra a mucha gente mordiendo el anzuelo, es probable que sea hora de hacer algo de introspección.

En cuanto al líder del equipo

Actuar al margen cuando se supone que debemos crear cuentas de usuario para varias tecnologías que se supone que debemos adoptar, abrazar y usar a diario.

¿Qué quieres decir con "actuar distante"? Si necesita una cuenta de Jira y esa persona es la que debe crearla, entonces no está haciendo el trabajo. Si es algo más, tendrías que describirlo. El "se supone que debemos adoptar, abrazar y usar a diario" me desconcierta y me hace pensar que hay algo más en juego.

Hacerme el tonto cuando se supone que mi equipo debe adoptar nuevas tecnologías DevOps que mejorarían muchos procesos comerciales manuales.

Su mandato lo determina su supervisor. No creo que "usar nuevas tecnologías DevOps" sea una de ellas. Si desea implementarlos, especialmente como contratista de defensa , es posible que deba seguir un proceso de gestión de cambios y un flujo de trabajo de propuestas. Además, "hacerse el estúpido" hace que suene como si simplemente no quisieran hacer lo que tú quieres hacer, lo cual no se refleja bien en ti.

No seguir las mejores prácticas de los proveedores al implementar nuevas tecnologías, lo que provoca problemas en las actualizaciones y, a menudo, reelaboración. Le mencioné esto al líder del equipo antes y no ha ido a ninguna parte.

Dulce. Documéntalo en el sistema de ticketing del que te hablaba anteriormente. El incumplimiento de los plazos es una excelente manera para que un supervisor obtenga una inspección más detallada de su supervisor.

Instalar software más antiguo porque "siempre lo hemos hecho de esta manera" o "funcionaba en el pasado" actitud del tipo, lo que termina causando más problemas.

¿Cómo? ¿Cómo "causa más problemas" para las personas y no solo para sus ambiciones?

Mantener un control total sobre el conocimiento del trabajo y la falta de entrenamiento o compartir ese conocimiento cuando se trata de problemas o no documentar estos problemas de esa manera si volvemos a encontrar el mismo problema, sabemos cómo lo solucionamos.

Creo que esta es probablemente una de las quejas más legítimas que tiene aquí. También es uno de los problemas más comunes en las empresas de software. Las retros, la documentación, el intercambio de conocimientos, etc. requieren una cantidad significativa de tiempo, y el valor comercial de ellos es difícil de explicar a las personas que impulsan los plazos.

Falta de comunicación del líder del equipo conmigo mismo y con la otra persona de mi equipo. Básicamente, se vuelve "pícaro" cuando implementa cambios y luego nos preguntamos qué sucedió o por qué se hizo algo de la manera en que se hizo.

¿Falta de comunicación cómo? ¿Estás usando VSC? ¿Hay compromisos? relaciones públicas?