Soy un líder técnico que también administra la línea de desarrolladores. Uno de los desarrolladores (vamos a llamarla Alice) que administro trabaja en un equipo de scrum separado de aquellos para los que soy el líder técnico. Los equipos hacen todo el trabajo en el mismo proyecto. Alice se colocó recientemente en un equipo que no se ha desempeñado muy bien y ha comenzado a resaltar directamente las formas en que pueden mejorar. Mi equivalente en ese equipo, llamémoslo Bob, prefiere un estilo de liderazgo técnico muy de arriba hacia abajo y no se ha adaptado bien a esta nueva llegada al equipo. También piensa que el equipo está funcionando bien.
Ha habido bastantes desacuerdos, varias veces Bob ha usado su autoridad para silenciar a Alice y evitar más discusiones sobre formas de mejorar el equipo. También he recibido comentarios sobre Alice quejándose de que está perturbando al equipo y que si fuera una contratista "la habrían dejado ir".
Convenientemente, también tenemos un consultor/entrenador en el equipo que busca mejorar su forma de trabajar con quien he podido discutir esto para obtener una imagen más equilibrada. Su opinión es que Alice tiene razón el 90 % de las veces y que el equipo necesita una disrupción saludable; sin embargo, Alice podría tratar de expresar sus puntos de una manera más diplomática. También hablé con Alice y le sugerí que comenzara a enumerar todos sus puntos en los que el equipo puede mejorar, buscar priorizar esta lista y luego trabajar con el entrenador para descubrir la mejor manera de comunicarlos uno por uno al equipo. en lugar de resaltar cada problema a medida que surge.
Si bien Alice está de acuerdo con este enfoque para la mayoría de las cosas, no cree que pueda dejar de resaltar y seguir resaltando un problema cuando, en su opinión, es un problema importante, por ejemplo, deshabilitar pruebas fallidas o considerar un ticket completo a pesar de una compilación fallida de Jenkins. Estoy completamente de acuerdo con su punto de vista sobre esto, pero Bob continúa frustrado con Alice y temo que la situación está pasando de una interrupción saludable a una simple interrupción.
No tengo autoridad sobre Bob porque es un equivalente y no creo que me ayude involucrarme directamente con todos y cada uno de los puntos planteados por Alice, tampoco tengo tiempo para hacer esto. Organicé una reunión conmigo, Alice, Bob, el scrum master del equipo y el entrenador para ver si podemos encontrar un camino a seguir y discutir algunos de los puntos que Alice siente que no puede dejar de resaltar. Si esta reunión no va bien y tengo todas las razones para sospechar que no, entonces no sé qué intentar a continuación y actualmente me siento atrapado en el medio. No existe una autoridad técnica superior real a la que se pueda escalar esto debido a una estructura de gestión técnica bastante plana mientras continúa una reorganización corporativa.
Esa es una situación difícil de manejar.
Creo que la forma más fácil de salir de esto (por ahora) sería sacar a Alive del equipo de Bob y regresar al tuyo o a un lugar que sea más compatible con su estilo y valores. Tal vez haya un intercambio que se pueda orquestar.
A largo plazo, debe haber una manera de abordar la falta de coincidencia entre Bob y tú/Alice. Necesita construir una cultura consistente y un conjunto de valores o tendrá conflictos como este continuamente. Eso será difícil sin una autoridad superior, pero tal vez esto cambie después de la reorganización. Hasta que haya una cultura unificada, lo mejor que puede hacer es minimizar los puntos de contacto.
Bob quiere "despedir" a Alice, por lo que parece ser un desacuerdo de fondo, no solo de expresión. Mientras tanto, cree que Alice está logrando un buen trabajo, pero tal vez le vendría bien un poco de asesoramiento sobre comunicación.
Parece que lo que realmente necesita hacer es mover a Alice del equipo de proyecto de Bob al suyo.
Tratar de forzar "ayuda" donde no se desea simplemente no funcionará. Ni siquiera importa quién tiene "razón" en un sentido técnico objetivo, es suficiente que simplemente no encaje.
Pregúntale a Bob si quiere liberarla. Entonces, los problemas o el progreso de su equipo pueden ser sus problemas o logros, y usted puede ayudar a Alice a ser aún más efectiva al presentar y aplicar sus soluciones en un contexto donde su intención es generalmente bienvenida.
Si su organización no puede sacar a Alice de una situación en la que su ayuda no es bienvenida a otra en la que sí lo sea, entonces probablemente la perderá como recurso para otra organización donde se valoren sus contribuciones.
"Varias veces Bob ha usado su autoridad para silenciar a Alice y evitar más discusiones sobre formas de mejorar el equipo".
"equipo scrum separado".`
Un equipo scrum es un equipo de desarrolladores sin roles. Esto debe ser planteado por el maestro de scrum al equipo de desarrollo sobre si así es como les gustaría operar.
Hable con el experto en scrum del equipo de desarrollo del que forma parte Bob y hágale saber el estado actual del equipo de desarrollo. En un camino diferente, Alice sería el mejor servidor al mencionar esto también con el maestro de scrum y durante la retrospectiva de Sprint con todo el equipo de desarrollo.
Según el OP, es un proyecto scrum, por lo que mi primera sugerencia es usar la etiqueta scrum que permite encontrar la publicación más fácilmente. La segunda crítica es que la oración inicial no tiene mucho sentido.
cita: “Soy un líder técnico que también administra la línea de desarrolladores. Uno de los desarrolladores (vamos a llamarla Alice) que administro trabaja en un equipo de scrum separado de aquellos para los que soy el líder técnico.
En la técnica de gestión de scrum, el gerente es igual al cliente externo, pero en el OP se afirma que es un gerente de scrum dentro de la empresa. La razón por la que Scrum se denomina ágil es porque el propietario del producto no forma parte del equipo, pero genera estrés desde fuera de la organización.
En lugar de hacer referencia a los miembros del equipo por su nombre, la mejor idea es dirigirse a los usuarios con su rol social. Cada miembro del equipo se ubica en la jerarquía de acuerdo al salario anual. Y el tipo que no recibe nada está en la cima de la pirámide, mientras que la persona que gana más tiene que hacer todo el trabajo por los demás.
Una explicación de la confusión con la organización matricial, los roles sociales y la falta de jerarquía se puede explicar porque scrum es un concepto de gestión muy nuevo. Es normal que al principio la mayoría de los gerentes clásicos luchen por encontrar su rol. Una forma recomendada de entender scrum durante un proyecto práctico es imaginar que el equipo tiene que resolver una tarea en el centro de operaciones de emergencia. Dicho entorno tiene la tendencia de ir solo en la dirección de scrum, especialmente si aumenta el nivel de estrés del usuario, la cantidad de recursos es limitada y los conflictos se vuelven visibles.
Si no hay una autoridad superior, puede pedirles a los otros líderes de equipo que ayuden a escribir algunos estándares técnicos.
En primer lugar, eso muestra a Bob (o posiblemente a ti ;-) el estándar que todos quieren.
Si eso falla, puede acudir a una autoridad no técnica con pruebas de que Bob no es un jugador de equipo y no cumple con lo que ahora son los "estándares de la empresa".
Jugador uno
Pablo