Tratar con un gerente difícil

Hay buenos gerentes y malos gerentes, a veces son la misma persona, todo está en la percepción.

Tu mejor estrategia es concentrarte en tus propias tareas y dejar que las cosas que no son tu responsabilidad o que no están bajo tu control te invadan. Trabajar en entornos de alta presión no siempre es malo, hay cosas que puede aprender de él que le brindarán una experiencia valiosa en años posteriores.

Haz lo mejor que puedas y mejora lo que puedas. Si se queda atascado con ellos, documente el comportamiento que cree que creó un entorno hostil y repórtelo a Recursos Humanos.

Tengo un gerente que es casi completamente así; la única diferencia es que él es el director ejecutivo y propietario de la empresa.

Aunque no vengo de una cultura de trabajo que sea tan dinámica como en otros países, puedo transmitir algunas de mis propias experiencias personales que pueden aliviar el problema:

• Prioriza la velocidad de entrega sobre la calidad del producto en todo momento; comprimirá los plazos de los proyectos a niveles inviables para apaciguar a los clientes.

Depende de su experiencia con el tipo de trabajo que haces. En mi caso soy desarrollador líder, aunque originalmente no fui contratado como tal. Sin embargo, sí tenía experiencia previa en gestión de proyectos y liderazgo.

Lo que hice fue encontrar formas de trabajar de manera más inteligente, no más difícil: incorporé una serie de herramientas al equipo que hicieron que los pasos fueran más fáciles o más rápidos de completar.

Sin embargo, también (como equipo) nos aseguramos de que no hubiera ambigüedad cuando se trataba de una fecha límite poco realista. El resultado final fue que nosotros (el equipo de desarrollo) pudimos planificar y estimar los plazos.

• No introduce ningún orden o estructura en los proyectos, simplemente deja a las personas a flote y "autogestionadas" sin orientación.

Si bien no siempre es el movimiento óptimo para hacerlo, en mi caso, tomé las riendas de las tareas y proyectos asignados, y tracé el camino para los proyectos. En mi caso, me hizo ascender, pero también puede ser un movimiento peligroso en algunos lugares.

• No aprecia el tiempo que lleva trabajar con proyectos heredados que administró anteriormente y que ahora están en mal estado; espera que las cosas se hagan rápido

En nuestro caso, introdujimos un tablero kanban simple para cada proyecto en el que se registraban los errores, los problemas y las notas, junto con el acceso del administrador a los tableros. Si es necesario priorizar algo, tiene plena capacidad para hacerlo y marcar las tareas en consecuencia.

En mi caso, el código heredado era un caso muy malo de "codificación de retazos", que básicamente se volvió insalvable cuando el alcance de las demandas de nuestros sistemas se amplió enormemente. Además de documentar los errores y problemas del código base existente, también comencé activamente una discusión sobre el alcance futuro de los proyectos y el sistema en general; desde entonces, esto ha resultado en una revisión importante de todo nuestro sistema.

Alrededor de 2/3 del nuevo sistema está diseñado para resolver los problemas del diseño anterior y, especialmente, para permitir una depuración mucho más detallada.

Siempre es una apuesta probar que un gerente está equivocado, pero también vale la pena señalar que, para empezar, hay una razón por la que estás en esa posición.

• No ofrece ningún comentario constructivo durante o después del proyecto, simplemente dice, por ejemplo, "Necesitas arreglar esto".

Tuve una discusión importante con el director general de que no estábamos allí simplemente para ayudarlo, sino para ayudarlo a ayudarse a sí mismo . Cuanto más pueda ayudarlo a rastrear el problema, mejor será la base para resolverlo.

Si bien, nuevamente, puede considerarse un movimiento audaz, ha ayudado, ya que hemos demostrado que el proceso de resolución de problemas es mucho más rápido al final.

• Nunca tiene tiempo para escuchar; siempre parece estar en reuniones y no responde a los correos electrónicos.

Si algo está por escrito, consulte continuamente el correo dado donde se planteó el problema. Este es especialmente el caso si se debe tomar una decisión rápida y/o proactiva en su ausencia.

• Del mismo modo, aunque su trabajo es interactuar con los clientes y aclarar sus requisitos, lo hace de manera muy lenta y superficial.

No hay nada de malo (aparte de la simple ineptitud) en preguntar sobre los requisitos dados. Nuevamente, asegúrese de que tanto como sea posible esté por escrito, incluida una nota que "X solicitó la función" en la descripción de la tarea. También tenga en cuenta cada vez que cambia la característica o el elemento y quién cambia los requisitos.

Una vez más, tomando el camino audaz, puede pedir ayuda de manera proactiva en la discusión de los requisitos y el mapeo del proyecto y demostrar que es consciente de que él no puede pensar en todas las preguntas por su cuenta.

• Cuando planteamos inquietudes, por ejemplo, falta de recursos, no se actúa en consecuencia.

Esta es probablemente la parte más difícil, pero en este caso es básicamente lo mejor para seguir "molestándolos" por la falta del artículo XYZ.

En cualquier caso, si se echa en falta una herramienta o un dispositivo para realizar una determinada tarea, lo mejor es tener y servir una lista de argumentos y consecuencias. Entonces, algo como: "La herramienta ABC costará $ XXX, pero nos da la capacidad de YYY y ZZZ. Sin embargo, si tenemos que arreglárnoslas sin ella, la tarea WWW hasta tomar 3 veces más tiempo cada vez que lo hacemos, y He tenido que hacerlo 10 veces este mes".

Siga presionando para obtener la herramienta o el elemento por escrito también; entonces tendrá algo a lo que referirse si la consecuencia asoma la cabeza.

• Cuando los proyectos van mal, culpa a los desarrolladores y dice que "no trabajaron lo suficientemente duro" o "no estaban lo suficientemente organizados", etc.

También tuvimos el problema en mi equipo, e incluso se nos culpó de problemas completamente ajenos porque "el dispositivo X produce datos y, por lo tanto, es su responsabilidad".

Es por eso que la documentación y las referencias adecuadas son importantes: en nuestro caso, hemos tenido personas en otros departamentos que actuaron sin el consentimiento y el conocimiento del director ejecutivo, en cosas que estaban completamente fuera de nuestro control.

La documentación y la referencia también ayudan sutil y silenciosamente a señalarse a sí mismo. Nadie dice nada malo o discriminatorio contra él; en todo caso, demuestra que está organizado y trabaja con las herramientas que tiene.

El gerente problemático es bastante mayor y muy respetado dentro de la empresa, y su voz tiene mucho peso. Sus proyectos casi siempre terminan siendo un tren descarrilado que apenas sobrevive; está más preocupado por cumplir con los requisitos de los clientes en papel y obtener ingresos a corto plazo que por ofrecer un producto útil que pueda mantenerse a largo plazo.

Y esta es especialmente la razón por la que necesita coordinar y documentar su trabajo e interacciones en los proyectos; de nuevo, no mencione activamente ni diga nada despectivo hacia él . Sin embargo, si los problemas escalan a sus superiores, entonces tienes la oportunidad de protegerte a ti mismo y al equipo: "fuerzas" el "dedo de la culpa" hacia el que realmente necesita ser culpado.

Nuevamente, estos son solo ejemplos de cómo manejé a mi gerente, y es posible que el suyo no lo tome tan amablemente. Si bien mi enfoque no ha resuelto todo, ha hecho que ir a trabajar sea mucho más llevadero.