Tengo un empleado junior muy talentoso en el papel de scrum master. Se ha desempeñado mejor en la mayoría de las tareas y está comenzando a asumir un papel más importante en el proyecto. Como gerente, asigné múltiples tareas técnicas difíciles a un arquitecto independiente que es un especialista en el software como yo. trabajo que él hace, pero ella no ve el panorama general y que su entrega era una prioridad menor para él.
Está ausente con permiso de paternidad y no se esperaba que completara este trabajo hasta que regresara. En parte, el problema es su culpa, ya que culturalmente nunca dice que no, pero ese es un problema diferente. Mis otros miembros del equipo le explicaron explícitamente esto, al igual que yo, que él se está desempeñando bien y que es la tercera vez que lo menciona en el grupo.
Cuando traté de 1:1 con ella para pedirle que considerara su situación y que no siempre completa sus tareas menores cuando es de menor prioridad, dijo que estaba siendo irrespetuosa. Estoy de acuerdo en que podría haber tenido más tacto, pero estaba tratando de que ella fuera un poco empática y viera el panorama general. Cuál es el proyecto no se ve afectado y recordar que somos un equipo y respetarnos unos a otros.
Ella está muy enfocada en la excelencia y cualquier cosa menos que perfecta es probable que encuentre algunas críticas. Otros miembros del equipo me han planteado esta preocupación antes de incluir a uno de los otros gerentes en el programa. Es joven y consciente de sí misma, pero tiene una voluntad fuerte y mucho potencial. ¿Cómo la entreno para que no se convierta en una idiota brillante?
Cuando leí el título pensé que te referías a una persona muy inteligente que critica a sus mayores y tiene razón en sus críticas, una especie de inconformista que es demasiado directa.
Sin embargo, si no se esperaba que el arquitecto trabajara en las tareas que ella le acusó de no realizar y no le pagaron, la retroalimentación que le dio fue injusta. La retroalimentación injusta puede afectar el desempeño del equipo al crear un drama innecesario. Puede afectar la motivación de los miembros del equipo y la posición de su empleado en el equipo. Sin mencionar que puede perder un buen contratista, según tengo entendido, por eso.
Primero debe analizar si fue un error de una sola vez o si tiende a ser injusto y no se basa en hechos con frecuencia.
Si sucedió una vez, no te preocupes demasiado. Si se repite, tienes que hablar con ella.
Yo mismo soy una persona muy crítica. Tengo estándares muy altos y odio cuando la gente no los cumple. Sin embargo, utilizo los mismos altos estándares para mí y me mortificó cuando cometí un error hace algún tiempo. Cumplir con los mismos estándares rigurosos que uno usa para los demás es realmente algo necesario si uno no quiere ser visto como un idiota y evitado.
Este no es un trabajador valioso de gran talento. Esta es una prima donna. A las personas les gusta esto en un equipo si no aprenden a bajar el tono y ver las imágenes más grandes, no son un gran activo en ese tipo de posición y pueden ser una desventaja si afectan la moral del equipo.
Ya has probado la manera agradable. Quítele su estatus cuando crea que es su responsabilidad juzgar a los demás hasta que madure lo suficiente para el papel. El talento y el potencial no están a la altura de la madurez y la experiencia de trabajo en equipo.
Si cree que su potencial lo justifica, avísele como "Eres muy bueno en lo que haces, pero no estás haciendo todo lo que se necesita, lo cual es parte del papel". Este es un equipo, vas a tener que ver el panorama completo si voy a dejar que continúes en este rol, te di un respiro, por favor no hagas que me arrepienta.' y avance desde si la juzga como cumplidora o no. Si cree que lo es, explíquele las ramificaciones del papel con más detalle y luego vea cómo va. Si no, degradar su papel.
La pones en el papel de un SCRUM Master. Es función de SCRUM Master asegurarse de que el equipo tenga un intercambio abierto sobre el estado actual de las historias de usuario. Si una historia de usuario está abierta durante algún tiempo, se discutirá repetidamente abiertamente que no hay progreso, pero normalmente sin ninguna implicación moral/disciplinaria "el desarrollador debería trabajar más duro", etc. Sin embargo, es función de un maestro SCRUM preguntar los motivos para asegurarse de que el equipo pueda manejarlos. Eso significa que, sí, si sigue SCRUM, la historia del usuario aparecerá hasta que se solucione: aquí ella solo está haciendo su trabajo.
Ahora llegamos a la parte interesante: " asignaste " a alguien a tareas "múltiples y difíciles". Normalmente, un equipo ágil tiene un procedimiento fijo si una tarea se atasca: acuerdan diariamente cómo abordar el problema. Normalmente, las personas no están asignadas en SCRUM a múltiples tareas. Normalmente se asignan a una sola historia de usuario. En buenos equipos ágiles no existe un "punto único de falla", pero cada historia de usuario puede ser manejada por suficientes personas en el equipo.
Entonces eso significa que hay un desajuste entre su supuesta función en el equipo y la ejecución del proceso. Esto causará fricción y puede pensar en cómo solucionarlo.
Cuando traté de 1:1 con ella para pedirle que considerara su situación y que no siempre completa sus tareas menores cuando es de menor prioridad, dijo que estaba siendo irrespetuosa.
Debe considerar que ella es insegura en esta situación y no quiere o no sabe cómo manejarla de manera efectiva. Esto se siente como una reacción emocional a una situación que necesita ser manejada profesionalmente, no emocionalmente.
Le dijiste directamente que su reacción no era la adecuada pero ella siempre desviaba la culpa a otra persona:
El desarrollador tiene la culpa de llegar tarde. Ella hizo todo bien, él destruyó su resultado perfecto.
Si tratas de echarle la culpa a ella, ella te dirá que le estás faltando al respeto solo para callarte.
Tienes que volver a hablar con ella. Es absolutamente necesario concentrarse en el proyecto, no en las responsabilidades personales . Debe ser el objetivo de todos en el equipo terminar con éxito el proyecto. Echarle la culpa a alguien o incluso buscar la causa de un problema con la intención de culpar a alguien es una pérdida de tiempo porque te distrae de tu objetivo.
Deje absolutamente claro que ella no cometió un error y que tampoco se la culpa por la entrega tardía del componente. Si el proyecto falla, todo el equipo es responsable, no solo una persona. Trate de quitarle algo de presión para que no sienta que tiene que transmitir la presión a los miembros de su equipo.
Como alguien que también hace esto con bastante regularidad (aunque he aprendido a expresar mi "explosión de personas" en un tono más generalizado, centrándome en el problema y no en la persona), puedo empatizar con ella. Basado en mis experiencias, esto es lo que yo haría:
Anímela a centrarse en los procesos, no en las personas. En lugar de "Joe llegó tarde con el constructor del widget", debería ser "El constructor del widget llegó tarde".
Explique la situación del trabajador autónomo. ella lo entenderá Ella no lo respetará, pero al menos ganará perspectiva. Sin embargo, si crees que esta será una respuesta lo suficientemente buena para ella, no lo es. No intente enmarcarlo como "debe aceptar que Joe llega tarde porque XYZ", debe enmarcarlo como "Joe llegó tarde, y eso es un problema. Pero debe entender XYZ antes de descarrilarse".
Las personas como ella (y yo) solo queremos que todo salga bien la primera vez. Esto es importante tanto para nosotros como para usted. La razón por la que queremos que salga bien es porque, si no sale bien, entonces alguien tiene que tomar el relevo, y esa persona podemos ser nosotros. ¿Por qué tenemos que recoger los pedazos del desastre de otra persona? Pídales que lo hagan bien la primera vez, y luego todo irá bien. Desde una perspectiva empresarial. si construye algo mal, tendrá que dedicar más tiempo a construirlo bien la próxima vez. Eso es más tiempo que tomará, y más dinero le costará a la empresa pagar nuestros salarios para hacer el mismo trabajo dos veces. Por lo tanto, debe preocuparse profundamente por lo que ella tiene que decir, no solo porque lo dice, sino también porque hay buenas razones detrás de eso.
Con respecto a este caso en particular, presumiblemente esta persona estaba esperando que Joe terminara su tarea antes de que ella pudiera hacer la suya propia; ella dependía de Joe de alguna manera. La cantidad de tiempo que Joe llegó tarde fue tiempo que ella pasó jugueteando con los pulgares sin hacer nada, y la gente como yo odia eso. Es la peor sensación de estar sentado en una oficina durante 8 horas al día sin nada que hacer esperando algo que debería haberse hecho hace una semana. Tenemos cosas que hacer, hay Netflix para ver, ejercicio para hacer, ropa para lavar, cocinar para hacer, compras de comestibles, etc., y ella está atrapada en el trabajo en su escritorio sin hacer nada porque Joe llega tarde (sí, ella estaría en su escritorio incluso si Joe llegara a tiempo; la parte importante es la parte de "no hacer nada", que se siente como una pérdida de tiempo que podría gastarse mejor en otro lugar). Él'
Ella entiende que el pasado es el pasado y que no puede hacer que Joe termine su trabajo más rápido de manera retroactiva. Sin embargo, a ella realmente le gustaría que, si Joe va a tomar 3 semanas de licencia por paternidad, entonces Joe no debería comprometerse a terminar su tarea hasta que finalice su licencia por paternidad. Luego, todos pueden planificar y programar correctamente, y ella, como Scrum Master, puede volver a priorizar el trabajo en función de lo que se hará y cuándo, de manera adecuada. Ella solo quiere que todo salga bien y cree que Joe le impide hacerlo.
Usted, como gerente, debe querer lo mismo que ella, por lo que está trabajando en la misma dirección pero parece estar en desacuerdo. Por lo tanto, usted, como gerente, debe explicarle que comprende sus frustraciones, explicarle una mejor manera de manejarse para no parecer tan áspera en el futuro, y debe ayudarla en situaciones futuras como esta, por ejemplo, explicando "Joe es de baja por paternidad durante 3 semanas, no programemos cosas que dependan de él para ese periodo de tiempo".
En cuanto a qué hacer con Joe, debes explicarle a Joe que debe decir que no. No es cuestión de quedar mal o lo que sea, es cuestión de programar. Si dice que hará un proyecto en una semana y tarda 2, entonces las personas que dependen de él para hacer su trabajo en esa segunda semana serán bloqueadas. Eso le cuesta dinero al negocio pagando los sueldos de las personas que están bloqueadas y desperdiciando ciclos. Explíquele a Joe que si no puede hacerlo, entonces es mejor para el equipo que él diga que no puede hacerlo que prometer la luna y no entregarla. Si Joe es de una cultura en la que decir que no se considera algo malo (conozco muchas de esas culturas, definitivamente existen), debe hacer todo lo posible para calmar ese miedo en Joe. Debe hacer que Joe se sienta cómodo al decir que no sin temor a que pierda su trabajo o su reputación en el futuro. Joe probablemente dice que sí a todo porque tiene miedo de que si dice que no, será visto como un holgazán, y debes asegurarle a Joe que eso no es lo que está sucediendo.
Este...
En la llamada de scrum, ella lo criticó al equipo diciendo que tiene tres semanas de retraso con una entrega y no documenta el trabajo que hace, pero ella no ve el panorama general y que su entrega era una prioridad menor para él.
..y esto:
Empleada júnior calificada crítica con sus superiores
... son inconsistentes. Ella claramente no es experta en mi opinión. Experto sería alguien que puede manejar la situación. Ella no está manejando la situación de manera efectiva.
Esto también es un problema...
Mis otros miembros del equipo le explicaron explícitamente esto, al igual que yo, que él se está desempeñando bien y que es la tercera vez que ella lo menciona en el grupo .
.. luego esto...
Cuál es el proyecto no se ve afectado y recordar que somos un equipo y respetarnos unos a otros.
.. finalmente esto:
idiota brillante
Perdón por las citas, pero necesito construir un cuerpo de evidencia antes de responder. La verdad aquí, es que ella no es brillante. Si fuera brillante, entonces lo obvio no sería tan difícil de entender para ella. Personalmente, creo que la estás poniendo en un pedestal. Ha cumplido con algunas tareas difíciles, pero eso no la hace brillante. Eso la hace efectiva en la entrega de tareas. Pero, hay más en su posición que la entrega. Existe la necesidad de comprender las dinámicas de grupo y comprender cómo funciona la comunicación entre las personas. Claramente tiene muy poca capacidad para escuchar y eso está afectando al equipo. En mi opinión, el problema es que se la ve como "brillante", no lo es, todas las pruebas apuntan a que no es brillante. Toda la evidencia apunta a alguien que es competente y testarudo.
El entrenamiento que recomendaría es ser severo. Pero, considerando que tuviste que entrenarla en empatía , no sé qué más podrías hacer con ese tipo de personalidad.
cdkMoose
cdkMoose
JPK
JPK
JPK
Yo no
gordito
Marcos Rotteveel
erik