Gerente culpando al equipo por el fracaso, cómo contrarrestar

Formo parte de un equipo de desarrollo de software interno en una empresa minorista. Actualmente estamos trabajando en un proyecto importante y con toda probabilidad fracasará. Ya casi ha terminado en este punto.

En los últimos dos años, esta será la segunda falla de alto perfil que ha tenido el equipo, no solo en términos de fallar en la entrega de lo que se pidió, sino en términos de entregar cualquier cosa de valor. No hemos hecho nada más en ese tiempo.

Varios miembros del equipo de desarrollo se han enterado por varias personas de la empresa que el gerente del equipo, que solo ha sido gerente de desarrollo durante los últimos dos años, ahora está culpando de esta falla al equipo de desarrollo al resto de la gerencia, incluido el director gerente.

Esta es una caracterización completamente errónea de por qué este y los proyectos anteriores han fracasado. Todas las razones del fracaso se han debido a la administración. Estas son una lista de razones que creo causaron el fracaso de los proyectos.

  1. Los sistemas comerciales han sido elegidos por la gerencia sin pensar en cómo/si podemos integrarnos con ellos. No se adaptan a la forma en que opera el negocio y no se ajustan a nuestros flujos de trabajo actuales. El resto de la empresa no está dispuesta a cambiar el flujo de trabajo para adaptarse a los nuevos sistemas.

  2. El gerente de desarrollo ignora todos los consejos del equipo. Todos los miembros sénior del equipo han dicho desde el momento en que comenzó el proyecto que era completamente inviable, simplemente no había una solución técnica que pudiéramos haber implementado que hubiera resuelto las limitaciones de la plataforma elegida y permitido que el negocio operara como quería No solo se ignoraron los consejos y las advertencias, sino que se los persiguió activamente; las personas que hicieron advertencias fueron castigadas.

  3. Todas las advertencias nunca surgieron más allá de nuestro equipo. Ningún otro miembro del equipo directivo conoce las graves deficiencias del proyecto. No hay transparencia en nuestro equipo. Se informa externamente que las cosas están bien y a tiempo a pesar de que internamente sabemos durante semanas que las cosas nunca van a funcionar. Los departamentos externos solo conocen con unos días de anticipación los plazos incumplidos a pesar de que podemos advertirles con suficiente antelación.

  4. La gestión de proyectos y equipos es disfuncional y absolutamente incompetente. Las tareas son vagas y no especificadas. Las decisiones críticas que se necesitan no se toman hasta el último minuto, lo que genera trabajo adicional y serios problemas con las soluciones asumidas existentes. Los casos extremos se ignoran cuando son inconvenientes. Todo el trabajo lo realizan unos pocos miembros del equipo central, por lo que, si bien se supone que todos debemos estar ocupados, es una situación en la que algunos están ocupados y otros tienen que seguir pidiendo cosas que hacer. La comunicación es terrible; las personas que han planteado problemas se excluyen de las llamadas y reuniones, por lo que no saben lo que está pasando y no pueden contribuir de manera productiva. El conocimiento de los problemas y las soluciones propuestas se ha tratado como un secreto y se ha ocultado a la mayoría de la gente.

  5. Plazos arbitrarios que están completamente desvinculados del trabajo a realizar.

El equipo de desarrollo ha estado trabajando hasta el límite, trabajando extra, incluidos algunos fines de semana, para intentar crear una solución. El fracaso no se debe a nuestra falta de compromiso o capacidad técnica.

¿Cómo podemos contrarrestar que nos culpen por este fracaso? Estamos pensando en solicitar colectivamente una reunión con el director gerente para exponer nuestras preocupaciones. ¿Es esta una buena idea? ¿Cuál sería la mejor manera de abordar una reunión como esa?

¿Por qué necesitas contraatacar? Un gerente es mucho más fácil de despedir y reemplazar que todo el equipo de desarrollo.

Respuestas (3)

Los buenos gerentes saben que la culpa siempre pertenece al liderazgo: los malos gerentes intentan quitarse la culpa de sí mismos. Lo hace muy fácil de ver porque los únicos gerentes que culpan a alguien son los malos gerentes.

Así que hay dos escenarios entonces:

  1. Su alta gerencia es buena: verán esto fácilmente y sabrán que su gerente no es bueno. Le harán algo o nada, y usted y su equipo se quedarán solos y no se les hará responsables.
  2. Su alta gerencia es mala: culparán a su jefe o a su equipo, o a ambos, y se habrían atribuido el mérito de su éxito si hubiera logrado cumplir a pesar de ellos.

En el escenario 1, eres bueno. En el escenario 2, nunca fuiste bueno y deberías irte si es posible.

El comportamiento de sus gerentes no es importante, la reacción de su alta gerencia a su comportamiento es lo que importa.

Solicite una reunión retrospectiva del proyecto para que pueda analizar el fracaso del proyecto con su gerente y la alta gerencia, para que pueda aprender lecciones de sus fracasos colectivos para determinar qué debe cambiar para que no todos fracasen. tercera vez. Lleve consigo cualquier evidencia que tenga de los puntos que hizo en el OP, para que pueda respaldar los puntos que está haciendo.

Además, es posible que desee investigar un poco sobre la gestión de proyectos ágiles y tal vez aprovechar esta oportunidad para presionar para que su empresa se vuelva ágil. Se han realizado investigaciones que han demostrado que existe una probabilidad significativamente mayor de que el proyecto fracase en las estructuras de gestión de proyectos "tradicionales" que en las estructuras ágiles, y el proceso ágil se diseñó para ayudar a abordar muchos de los problemas que tenía.

Respuestas directas seguidas de algunos consejos más generales:

¿Cómo podemos contrarrestar que nos culpen por este fracaso? Estamos pensando en solicitar colectivamente una reunión con el director gerente para exponer nuestras preocupaciones. ¿Es esta una buena idea? ¿Cuál sería la mejor manera de abordar una reunión como esa?

  • Contrarrestarlo es documentación, ver #4
  • Puedes hacer eso, será poderoso. Tenga muy en cuenta que es un hábito bien conocido de los compañeros de trabajo retroceder cuando discuten con la gerencia que "Bueno, no son tan malos. Pregúntele a cualquiera que haya ido a pelear por un compañero de trabajo que se queja. A la gente le gusta quejarse.
  • No, no es una buena idea a menos que obtenga las quejas de todos por escrito y firmadas por ellos. El "líder" del grupo será dado de baja como muestra de lo que sucede cuando intenta tomar medidas. Nadie debe ser visto como el líder.
  • Debe solicitar la reunión por escrito con el documento de queja firmado. No lo presente usted mismo como el líder. Esencialmente, estás actuando como un sindicato sin estar en un sindicato. Cualquier acto que no sea solidario será capitalizado.

Consejos generales

  1. En primer lugar, no trabajes gratis. Esos fines de semana? Reducción del 20% en el pago de esa semana. ¿12 horas al día cuando te pagan por 8? Reducción del 50% en el pago de ese día. Las recompensas no llegarán a usted a menos que tenga un capital significativo, y si las recompensas llegan , lo más probable es que reciba una fracción de lo que habría recibido si le hubieran pagado por todo ese tiempo extra. Su contrato puede decir "incluye horas extra" con su salario, pero eso generalmente se considera "dentro de lo razonable" y generalmente está sujeto a reglas de promedio (Canadá, pero muchas provincias han eliminado a los trabajadores de tecnología debido al cabildeo de asociaciones comerciales para abusar de los trabajadores ). Si abusan de estas cláusulas, busca otro trabajo. Los desarrolladores senior están en demanda.
  2. El gerente es malo, pero nada de lo que hizo parece que hizo algo que no fuera su responsabilidad. ¿Van en contra de tu consejo sobre tecnología? Tratar con él. No fue tu decisión tomarla. ¿Líneas de tiempo? No es tu problema hacerlos. Haces lo mejor que puedes frente a las tareas asignadas. Fijación de plazos razonables a su cargo. Lo que no haces es cubrirlos. No haga trabajo adicional que cumpla con sus plazos insanos, solo los hace parecer motivadores increíbles que pueden cumplir cuando nadie más podría hacerlo. Que se retuerzan con el viento. A la mayoría de las empresas no les importará si te quemas. Simplemente te darán la vuelta y te reemplazarán.
  3. Busque otro trabajo u otro equipo con el que trabajar. Languidecer bajo un jefe de mierda es genial para ese sentimiento de camaradería, pero los amigos del trabajo son amigos del trabajo. A menos que rompas esas barreras y te conviertas en una verdadera amistad, no esperes mucho apoyo si intentas organizar una revuelta.
  4. Es muy importante utilizar su sistema de emisión de boletos/sistema de registro que el gerente no puede modificar de cualquier manera para rastrear cosas como solicitudes de información/claridad, trabajo realizado, estimaciones realizadas y discutidas, requisitos especificados, cronogramas discutidos (y cuáles fueron los comentarios de la gente). Eventualmente, podrá señalar todas estas cosas cuando el martillo comience a caer. Usted y su equipo estarán protegidos por su diligencia, y su gerente será visto como un tonto.
Con respecto al punto 2, puedo pensar en algunas cosas que el gerente ha hecho que no debería haber hecho, empezando por prometer un resultado que sabían que no podían cumplir porque se lo dijeron las personas que realizaban la implementación. El segundo sería la compra frívola de sistemas comerciales sin pensar en la integración, ya sea en un sentido comercial o técnico. El tercero sería el silenciamiento activo de los miembros del equipo. Es parte del trabajo de un gerente conocer la disposición del terreno, por así decirlo, no enterrar la cabeza en la arena a la primera señal de problemas.
@ 520 Estoy totalmente de acuerdo contigo en que no deberían haber hecho esas cosas . Sin embargo, la empresa le ha confiado a esa persona que tome las decisiones que considere correctas para el negocio y no OP. Serán evaluados por sus superiores y considerados indignos si traicionan esa confianza. Si OP sabe que los problemas nunca se plantearon a la alta dirección, ya debe tener una conexión con la alta dirección. Eso sugiere que a la alta gerencia no le importa. Esto deja a OP en una posición bastante difícil. OP y su cohorte tendrán que actuar colectivamente si quieren tomar acción directa.