Cómo manejar a un colega que no puede manejar el estrés y toma malas decisiones pero que puede trabajar duro

Hace unos 6 meses contratamos a un desarrollador que venía directo de la universidad. Es inteligente, trabaja duro y parece crear código de calidad. Los primeros meses actué como un amortiguador entre la gerencia y él, todavía tenía que aprender mucha lógica relacionada con los negocios, los marcos que usamos... Fui fácil con él y le comuniqué claramente que la carga de trabajo aumentaría. una vez que conoció el negocio y las tecnologías requeridas. Trabajamos en una herramienta de automatización financiera para una gran empresa acelerada que tiene que reducir un equipo de 18 tenedores de libros a 2 o 3 personas

Ahora, ha llegado el momento, la carga de trabajo aumentó, tomé cierta distancia para ver cómo se desempeña en plazos ajustados, mucho trabajo y reuniones con la gerencia. Después de unas dos semanas lo vi cambiar, no positivamente, todavía trabaja duro, pero veo que ocurren errores todo el tiempo. Los plazos que se fijó para sí mismo no se cumplen y la calidad general de su código sufre. Parece estresado, no puede pensar con claridad y parece olvidar muchas cosas. Una parte de esto es que a menudo se queda hasta tarde en la oficina, comienza temprano y solo se va a casa después de las 10 p. m. varias veces a la semana. Todos sabemos lo contraproducente que puede ser esto, trabajar largas jornadas a menudo produce menos calidad en el trabajo que tomarse su tiempo y repartir su trabajo en varios días.

Ayer tuvimos una reunión sobre una nueva función que se necesitaba lo antes posible. Él estará trabajando en esta función, así que lo quería en esa reunión. Comunicé claramente que no me invalidaría en las estimaciones de tiempo o las decisiones que tome durante esta reunión, ya que sé lo que espera la gerencia y cómo abordarlo. Cuando surgió la estimación del tiempo de desarrollo del MVP, dejé en claro que no fue fácil y que necesitaremos algo de tiempo para investigar antes de poder hacer una estimación definitiva. Anuló esto diciéndole a la gerencia que podría hacerse en 2 días con todas las campanas y silbatos. Estaba furioso, con su declaración no solo socavó mi autoridad y le dio a la gerencia información incorrecta que generó expectativas equivocadas y podría dañar el producto, sino que también asfixió a todo el equipo al establecer un plazo demasiado corto. (Para su información:

Después de una llamada telefónica con el CEO explicando lo que estaba pasando, logré extender este plazo. Pero también me dijeron que soy responsable de mi equipo y que situaciones como esta no son aceptables.

¿Cómo puedo manejar a un empleado que puede trabajar duro pero que no puede tomar decisiones y estimaciones de tiempo adecuadas, que parece estresado por la carga de trabajo y la naturaleza acelerada del negocio en el que trabajamos? Quiero que trabaje menos, pero que sea más productivo . Puedo verlo entrar en un agotamiento en poco tiempo si las cosas siguen como están ahora.

Tengo que admitir que solo unos pocos con los que he trabajado en el pasado pueden mantenerse al día en esta empresa. He visto muchos ir y venir. Los que manejan son todos personas brillantes, inteligentes y trabajadoras. Veo potencial en este desarrollador, por lo que realmente quiero ayudarlo a crecer en esta empresa. Aquí hay espacio para construir una carrera superior a la media y quiero que tenga éxito. (Dejó en claro que también quiere esto)

@JoeStrazzere Manejamos una especie de jerarquía plana en nuestro equipo, donde asumo la responsabilidad final del producto y las decisiones relacionadas con el desarrollo. Todos deberían poder asistir a las reuniones con la gerencia conmigo o sin mí. Confío en ellos, ellos confían en mí y esto nunca antes había dado lugar a problemas.
De la pregunta no estoy seguro: ¿es su colega o subordinado? Eres un poco inconsistente en eso. Si formalmente usted es su colega sin "poder administrativo y disciplinario" sobre él, pero se espera que lo administre y lo discipline, es un problema muy diferente.
"Los plazos que se fijó para sí mismo no se cumplen": hay toda una escuela de gestión de proyectos que acepta que los plazos no pueden ser predichos y, EN PARTICULAR, no por UNA PERSONA. Scrum, hay un juego de póquer (donde todo el equipo de scrum apuesta por la complejidad de una historia, explicando el razonamiento de los valores atípicos, es decir, el más alto y el más bajo). No debe, como persona, determinar sus plazos por sí solo para empezar. Cuestión de gestión.
No estoy seguro de entender la situación. Hay una reunión en la que alguien fuera de la escuela estima que una tarea se puede realizar en 2 días. El líder del equipo dice algo más, la gerencia ignora los aportes del líder del equipo y los planes ingenuos para una estimación más corta. Luego, el líder del equipo llama al director ejecutivo para anular la planificación de la gestión y luego el director ejecutivo le da una advertencia al líder del equipo porque el líder del equipo hizo su trabajo para advertir que el cronograma no es realista.
Además, ¿no es más el trabajo de gestión planificar y evitar dañar el producto con la consiguiente pérdida de ingresos? Siento que la gerencia debería asumir más responsabilidades de sus decisiones, como si fuera su decisión ignorar los aportes de un miembro más experimentado y no establecer ningún margen en el cronograma.
Lo siento si esto puede ofenderlo, pero para el caso de anulación, usted sabe que él / ella es "nuevo", bajo estrés y tomando malas decisiones, también agregó "Lo antes posible" como descripción. Claramente, está confundido y estresado como usted dice, debería haberle dicho a la gerencia que hablara con usted, no con el desarrollador sobre este asunto, y decirle que no responda nada y que redirija las preguntas a usted.

Respuestas (4)

Es un desarrollador junior, recién salido de la universidad, y hay cosas que aún no ha aprendido. He estado en el estado en que él se encontró una vez . Demasiada presión, me estresé, trabajé muchas horas y logré mucho menos de lo que normalmente hubiera hecho en ocho horas al día. Lo descubrí yo mismo, y desde entonces no dejo que nada me estrese. Si hay presión, no me estreso sino que me concentro, pero si no se cumple una fecha límite, es problema de mi jefe.

Él no sabe esto todavía. Hable con las personas que querían saber el presupuesto y dígales que la función no estará disponible en dos días. Sabes que no lo hará.

Luego, en la mañana posterior a la fecha límite, tiene una conversación con el joven desarrollador. Pregúntele cuánto tiempo llevará la función. Cuando te dé una respuesta (probablemente “dos días”), vuelve a preguntarle. Pero preguntas “esta vez no lo que crees que quiero escuchar, sino cuánto tiempo tomará”. Si no está de acuerdo con la respuesta, vuelve a preguntar hasta que le dé una respuesta realista. Esa es la primera lección importante aprendida.

Luego le pregunta cuántas horas trabajó en los últimos dos días. Y cuánto logró en ese tiempo. Y por qué logró tan poco. En ese momento, debería darse cuenta de que trabajando muchas horas y apurándose logra menos de lo que habría logrado con ocho horas de trabajo concentrado y sin estrés. Y pregúntale cómo se siente al respecto. Porque estoy seguro de que no está contento con toda la situación.

Y esa es la segunda lección importante. Que nada bueno sucederá si te esfuerzas demasiado. Que necesitas estar relajado en el trabajo y no dejar que la presión te afecte.

Esta respuesta claramente ha sido escrita por alguien que ha sido ese desarrollador junior: reconozco muchos de mis propios errores como desarrollador junior en ella :-)

Tu CEO ya te ha dado la respuesta. Eres el líder del equipo, estableces los plazos y gestionas las expectativas.

No importa lo bueno que sea, no es correcto ni apropiado que un nuevo titular vaya por encima de tu cabeza y diga lo que cree que puede hacer y en qué marco de tiempo. Él te dice lo que piensa, tú le dices a tus superiores en base a tu conocimiento y experiencia, y así sucesivamente.

Incluso después de que le dijiste que no te anulara, fue y lo hizo de todos modos. Eso es insubordinación, simple y llanamente.

Tienes que preguntarte cuánto quieres a alguien así en tu equipo. Todo está muy bien ahora donde puedes vigilarlo y, hasta cierto punto, controlarlo, pero ¿qué sucede en el futuro? Cuando te tomes días de vacaciones, ¿ignorará lo que le has dicho al equipo y hará lo suyo? ¿Qué pasa si se convierte en un líder de equipo y comienza a prometer cosas a la alta gerencia que, como este proyecto, simplemente no se pueden cumplir?

Tu única opción en este momento es ser tan firme con él como puedas. Envíalo a casa si es necesario, asegúrate de que no tenga interacción con la alta dirección a menos que lo autorices, o sea 100% esencial. Si no puede seguirlos, es posible que deba considerar el siguiente procedimiento de la compañía para PIP y cualquier evento disciplinario que considere apropiado.

O OP podría simplemente preguntarle por qué anuló OP a pesar de la advertencia...
Se debe tener una conversación con el niño. Uno a uno, puerta cerrada, ambiente formal. El OP debe ser bastante duro con él. Luego ofrezca liderazgo y orientación cuando se trata de trabajar hasta tarde, los plazos personales de este niño (que parecen poco realistas), etc. Parece que si el OP está interesado en "salvar" a este desarrollador, es posible que necesite microgestionarlo (entrenarlo) por un tiempo .
@AndreiROM ¿Está recomendando que un líder de equipo "se enfade mucho" con un miembro del equipo sin experiencia por una sola vez?
Sí, porque así aprenden los inexpertos. Claramente, una charla anterior no fue lo suficientemente acertada.
@SebastienDErrico, Esto no es realmente una "cosa de una sola vez". Ya tiene un mal historial de hacer estimaciones de tiempo y se le advirtió claramente que no lo anulara durante esta reunión con la alta dirección. "Le comuniqué claramente que no me invalide en las estimaciones de tiempo o decisiones que tome durante esta reunión". Si el OP intenta corregirlo suavemente ahora, obviamente no funcionará. El OP ya probó ese enfoque y no funcionó.
@StephanBranczyk Trabajé en TI durante casi 4 años y si me piden que calcule cuánto tiempo se hará algo para un nuevo proyecto, pensaría mucho y aún no estoy seguro de la respuesta. A menos que OP o alguien ya le haya dado una conferencia al novato sobre esto, realmente no puede dar una advertencia y esperar que ahora pueda estimar un 100% mejor sin ninguna pista ni guía. Cuando era un novato, mi único objetivo era hacer el trabajo, si el trabajo se acumula, todo lo que puedo pensar es cómo hacer más y no perder ninguna fecha límite. Creo que es injusto para el novato.
@Encryptoferia, "A menos que OP o alguien ya haya dado una conferencia al novato sobre esto" ¡Exactamente! El OP afirma que ya lo instruyó sobre este tema. Aquí están las palabras de OP: "Me comuniqué claramente para no anularme en las estimaciones de tiempo o las decisiones que tome durante esta reunión"
@StephanBranczyk Con 10 años en el campo, la mayoría de las personas no pueden estimar de manera efectiva, es la habilidad menos enseñada y la más difícil de dominar. También hay un desajuste en el que se esperan estimaciones sobre la marcha, donde una buena estimación requiere tiempo para desglosar el problema. No esperaría que se acercara al tiempo real en una estimación la mayor parte del tiempo hasta dentro de un año o dos. El problema no es el desarrollador junior, es la empresa por ponerlo en esa posición. ¿Y por qué las otras personas tomaron la palabra de un jr sobre su gerente? Ese es otro fracaso de la empresa.
@GabeSechan, estoy totalmente de acuerdo con esa parte. Definitivamente hay algo sospechoso en la empresa y, por lo general, eso es una señal de que personas sin conocimientos técnicos están en posiciones de poder.

Tienes que alejarte de él. Es un nuevo desarrollador 6 meses fuera de la universidad. No está listo para el nivel de trabajo que le estás dando. ¿Por qué llevarías a un desarrollador EXTREMADAMENTE junior a ese nivel de reunión? ¿Y por qué no dijiste simplemente "No, no podemos" y lo llevaste a un lado si era necesario? Fracasaste por completo como gerente en ese momento.

Si usted es su líder/gerente, es su trabajo hacer esas reuniones por él hasta que esté listo. Obviamente aún no está en ese nivel, y probablemente no lo estará por un tiempo. Todo lo que dijiste muestra que lo atacaste demasiado rápido, demasiado fuerte y antes de que él fuera capaz de hacerlo. Su trabajo como mentor principal de un joven talento es aumentar lentamente el trabajo/dificultad, permitiéndole crecer en el papel. Eso no tomará 6 meses. Se necesitan años para convertir a un junior en un nivel medio. No son solo habilidades técnicas, que posiblemente ya tenga. Es aprender cómo trabajar con otros, cómo navegar por las estructuras de poder, cómo comunicarse, cuáles son sus capacidades reales y cómo entregar código listo para producción (a diferencia de un proyecto escolar). Es la gestión del tiempo. es confianza Es aprender a priorizar.

Si se queda ahí hasta las 10 de la noche, le estás dando demasiado trabajo. Si está dando malas estimaciones, debe enseñarle a dar mejores estimaciones. Y sí, en ese proceso cometerá errores. En muchos casos lo mejor será dejar que los haga y aprender de ellos, siempre que el coste no sea demasiado elevado. Eso es lo que obtienes con un desarrollador junior: verás una gran cantidad de tiempo perdido. Considéralo costos de capacitación.

Lo que debe hacer es reducir su carga de trabajo hasta que pueda hacerlo en un tiempo razonable. Luego averigüe en qué áreas es deficiente, aquí puede ser estimación y comunicación, y planee una manera de enseñarle.

Tengo que admitir que solo unos pocos con los que he trabajado en el pasado pueden mantenerse al día en esta empresa.

Entonces, en otras palabras, tienes un problema sistémico en la empresa que no sabes cómo desarrollar el talento. El problema no son los desarrolladores que se fueron, es tu empresa. Y es al menos en gran parte usted- esta actitud es inaceptable en un gerente. Aprende a hacer tu trabajo correctamente, estás fallando a estos desarrolladores.

No veo el problema de invitar a alguien a una reunión solo para mantenerlo informado sobre el contexto comercial y la información específica. Especialmente dado que OP le indicó explícitamente que no interviniera, no creo que sea una evaluación justa culpar solo a OP aquí por invitar al junior y no al junior por ir en contra de instrucciones explícitas.

Realmente quiero ayudarlo a crecer en esta empresa... Quiero que tenga éxito. (Dejó en claro que también quiere esto)

Escriba esto oficialmente, siéntelo, explíqueselo como nos lo explicó a nosotros.
Incluya el hecho de que el CEO "me dijo que soy responsable de mi equipo y que situaciones como esta no son aceptables". Señale nuevamente que usted le dijo antes de la reunión que "no debería anularme en las estimaciones de tiempo o las decisiones que tome durante esta reunión".

Explique que dañó su reputación y la suya con su desobediencia.

Siga las pautas de recursos humanos:
déle el resumen escrito de lo que dijo y pídale que lo firme para reconocerlo.
Asegúrese de que la declaración tenga un método en el que pueda disputar cualquiera de los hechos por escrito y dígale que se adjuntará a la advertencia para que conste en acta.

Explique que lo único que le impide despedirlo es el hecho de que es nuevo, es su primer trabajo, sabe que está bajo mucho estrés y ve potencial para que se convierta en un gran empleado.

Preste atención a la advertencia verbal que le dio su director ejecutivo: es su trabajo el que está en juego, no el de él.

Obviamente tienes mucha compasión y comprensión por el chico, así que no te daré lecciones sobre eso.

Haga un seguimiento al CEO diciendo que lo ha notificado con una advertencia por escrito de que habló con él en persona. También dígale al director ejecutivo que no estará en reuniones con clientes durante al menos un año.

Agregando a mi respuesta un punto muy relevante de los comentarios:

... hablar en esa reunión cuando se le dijo explícitamente que no lo hiciera, no es una cuestión de no saber algo, es una cuestión de insubordinación deliberada...
Dicho esto, aquí hay espacio para aceptar que esto fue un error de una sola vez y estar dispuesto a seguir adelante, si se detiene. – Flater 5 de mayo a las 15:16

mi énfasis

Creo que esto es demasiado, una reunión 1 a 1 sin todo el papeleo debería ser suficiente, considerando que él quiere quedarse con este tipo. Estaría de acuerdo con este enfoque si solo necesita razones para despedirlo.
@Homerothompson No estoy de acuerdo. El CEO notificó al OP que es su culpa la referencia al cuarto párrafo, donde dice que "me dijeron que soy responsable de mi equipo y que situaciones como esta no son aceptables". En mi opinión, solo una palabra en este punto, aunque sería bueno hacerlo, podría poner en peligro el trabajo de OP si sucede algo más .
@Homerothompson: Si bien en general estaría de acuerdo con usted en la mayoría de los problemas, hablar en esa reunión cuando se le dice explícitamente que no lo haga no es una cuestión de no saber algo, es una cuestión de insubordinación deliberada. Incluso si tenía la intención de hacer algo bueno, cruzó una línea clara y rompió la confianza. Repetidamente, este comportamiento es motivo de despido, y una advertencia oficial vende mucho ese punto que claramente ha caído en saco roto hasta ahora. Dicho esto, aquí hay espacio para aceptar que esto fue un error de una sola vez y estar dispuesto a seguir adelante si se detiene.
Cómo manejar a un colega que no puede manejar el estrés y toma malas decisiones pero que puede trabajar duro
RespuestasAquíPolítica de privacidad1y, 0v