Liderando un equipo, ¿estoy siendo dominante?

Estoy en lo que me parece una posición muy extraña. Soy "líder del equipo" en el papel de un proyecto en particular, ingeniero de software sénior en el cargo. En mi equipo tengo 4 desarrolladores, uno de los cuales cumple una función similar en otro proyecto, pero ahora el mío tiene prioridad, por lo que está trabajando en el mío. También tengo 2 probadores, uno de los cuales es gerente. Otro miembro del equipo es el "Representante del cliente", que forma parte de un departamento completamente ajeno. También tengo un Gerente que está directamente sobre mí y creo que también está por encima del Gerente de Prueba que es parte de mi equipo ... aunque no estoy tan seguro de eso.

He tratado de obtener aclaraciones sobre por qué mi papel es exactamente varias veces. Me ha resultado difícil determinar dónde comienza y dónde termina mi autoridad, si es que tengo alguna. La respuesta con la que estoy trabajando actualmente es que soy el "líder técnico" del equipo. Esto parece significar que mi autoridad está sobre las decisiones técnicas con respecto a la arquitectura, el diseño y los estándares de proceso / codificación en lo que respecta al código del producto.

Hoy surgió algo y los resultados del código que delegué a uno de los miembros de mi equipo se mostraron al resto de la compañía en nuestra reunión Scrum show-it-all-off. La persona representante del cliente hace el alarde. Hoy se mostró algo con lo que realmente no estaba de acuerdo y nadie me había preguntado si quería decir algo sobre lo que sucedió. En resumen, para proporcionar la capacidad de un usuario de mostrar un valor en un informe de las siguientes maneras (unidades "doc", unidades de diseño, redondeadas, no redondeadas) proporcionaron campos de acceso para cada permutación. Por lo tanto, tenemos el valor en unidades de documento redondeadas, unidades de diseño redondeadas, unidades de documento sin redondear, unidades de diseño sin redondear. Cada registro con el que el usuario deseará trabajar tiene muchos de esos valores y cada uno está permutado de esta manera.

Realmente odio esto.

Las personas a las que les mostramos esto quieren asegurarse de que la API que utilizamos para los informes sea la misma que hacemos para exportar datos a Excel. Desafortunadamente, ahora estamos ganando este impulso en una dirección que creo que es muy, muy mala.

Me molesté un poco en la próxima reunión y les pregunté a las dos personas que habían hecho esto: "¿Por qué no estuve involucrado en esta decisión?" Es un problema que sigue surgiendo y me cuesta mucho que parezca que solo las personas en el equipo que debo liderar me pregunten si quiero involucrarme. A veces no lo hago y creo que todo lo que se les ocurra estará bien. Otras veces lo hago. A menos que la gente me pregunte, es difícil incluso saber que algo está pasando que necesita mi aporte y no me dan esa oportunidad.

Desafortunadamente, mi autoridad no se extiende a decirle a la gente: "La próxima vez que salgas y hagas algo así por tu cuenta sin siquiera hablar conmigo, serás disciplinado". Esa es una cuestión de "relaciones públicas" que es un área que claramente no está en mi ámbito de autoridad. Eso está bien para mí, ya que no quiero tener que lidiar con ese tipo de basura si alguien más está dispuesto.

Hoy, sin embargo, mi gerente, frente a todos (lo cual creo que también es en parte culpa mía por mencionarlo así) me dijo que no puedo involucrarme en cada decisión y que necesito delegar.

Por supuesto, creo que tengo razón ... Siempre lo hago. No digo cosas que creo que son BS. Creo que debería haberme contactado sobre este tema y preguntado si tenía una mejor idea. Mi dirección para esto habría sido decidir solo UN valor para proporcionar por ahora, ya que esta era en realidad las etapas iniciales de una nueva característica, y discutir opciones para proporcionar un mayor acceso en el futuro si así lo desea. Nunca hubiera aprobado o recomendado la implementación actual y realmente no creo que debería haber visto la luz del día.

La pregunta es, ¿soy el irrazonable?

Bueno, los dos hablamos sobre eso y acordamos que ambos "tiramos la pelota" y parecemos estar en la misma página. Los lunes por la mañana ... Vamos a tratar de asegurarme de que mi papel sea claro en el equipo y que sí, yo pueda decidir cuándo hay un cambio de diseño o tarea que deba ocurrir; Me proponen y estoy de acuerdo o decido que necesito mirar más profundamente. Luego hay algunos otros aspectos en los que puedo intentar trabajar para asegurarme de que sepan que pueden venir a mí.

Parece que necesita monitorear las confirmaciones de origen. Perforce tiene esta habilidad de forma nativa, Git la tiene a través de ganchos, otros estoy seguro de que tienen sus propios métodos. No tiene que analizar cada confirmación, pero al menos recibir una notificación y diferenciarlas le dará una breve visión de todo lo que está pasando en su proyecto.

En cuanto a que su gerente le diga que necesita delegar, no estoy tan seguro de estar de acuerdo: con un equipo de cuatro desarrolladores, debería poder manejarlo. Además, podría estar del lado de él (o ella). Por supuesto, incluso en las tareas que se delegan, debe solicitar actualizaciones de estado o recorridos sobre cambios de diseño, etc.

Nada negativo debe siempre ser educado en las reuniones - suena como usted y su gerente dejó caer la pelota en este caso. La peor cosa que usted podría nunca hacer a un compañero es avergonzarlos. Como líder (como con su gerente), debe ser accesible y confiable. Menospreciar a alguien generará resentimiento, lo que afectará su capacidad de liderar a su equipo (así como a empleados descontentos).

Me gusta escuchar la palabra "disciplina" de cualquier persona en un papel principal. La disciplina (al menos en este contexto) es negativa y no productiva. Trabajar con alguien (personalmente y no en una reunión), averiguar por qué hicieron algo y proporcionar alternativas si no está de acuerdo con sus soluciones propuestas es lo que debe hacerse. A veces, encontrarás que la persona con la que estás trabajando tiene razón y tu instinto está equivocado. ¿Por qué? Han pasado más tiempo en ese problema específico que tú.

Otra cosa que me preocupa es "siempre creo que tengo razón". OMI, esa es la peor actitud posible de cualquier líder. Usted debe , evidentemente, tener confianza en sus habilidades, pero se dan cuenta de que si no estás hasta el cuello en un problema específico, a continuación, más veces que no, sus sugerencias están saliendo de su trasero (no importa la cantidad de experiencia que tiene) y no siempre sé el mejor. Si alguien que se concentra en un problema específico ofrece una alternativa, entonces es su trabajo (bueno, así como el suyo, dependiendo de su propio nivel de experiencia) demostrar por qué el suyo es mejor, no solo decir "Soy el líder y Siempre pienso que tengo razón ", que es lo que tu oración me lleva a creer.

Para envolverlo

Sí, no eres razonable en algunos puntos, pero otros no. Como una ventaja, esperaría que si hay cambios de características o arquitectónicos que al menos sean pasados ​​por usted.

Sin embargo, también es su trabajo garantizar la calidad general del sistema y del código, lo que debe hacer por su cuenta. ¿Su empresa emplea revisiones de código? ¿Hace que sus programadores diseñen en qué están trabajando antes de ingresar al código? De lo contrario, es posible que desee comenzar a utilizar este tipo de mecanismos de control de calidad.

Es posible que se le haya retirado la administración y, de ser así, está fallando (lo que puede no ser algo malo; muchos de nosotros somos buenos desarrolladores y seríamos malos administradores, y prefiero programar que administrar programadores).

Los gerentes con frecuencia no tienen la autoridad para todo lo que se espera que hagan. Hacer las cosas de todos modos es una señal de un buen gerente. Necesita encontrar formas de hacer que las personas hagan cosas sin tomar ningún tipo de acción disciplinaria. (Nota: menospreciar a las personas en público no lo es. Elogie en público, critique en privado y muestre cierto interés en sus subordinados como personas).

Los gerentes también tienen que delegar, incluso cuando duele. Es probable que pases más tiempo lidiando con este problema del que hubieras pasado escribiendo tú mismo, y eso está bien. Una vez que lo haya tratado, las personas que hicieron eso deberían haber aprendido algo, y es menos probable que hagan las cosas de la manera incorrecta en el futuro.

La forma correcta de lidiar con algo como esto es en privado, primero preguntando a los desarrolladores por qué hicieron la pantalla de esa manera. No en una reunión, y no asumiendo por adelantado que tienes razón y que están equivocados (incluso si tienes razón y están equivocados). Dales la oportunidad de explicarte. Eso no significa que tengas que ir con su decisión; usted, después de todo, es el líder técnico. Significa que debe darles razones para hacerlo a su manera, y debe abordar cualquier problema fundamental que se presente durante esa reunión privada.

Además, los gerentes tienen la responsabilidad de lo que sale de su gente. Debe tratar de no dejarse sorprender por nada de lo que hacen, particularmente frente a un cliente. Esto puede implicar realizar un seguimiento de los registros de código o tener mini-conferencias rápidas con sus desarrolladores (aunque debe tener cuidado con eso, no desea interrumpirlos cuando están en la zona). Posiblemente debería hablar con todos los desarrolladores la tarde antes de la reunión con el representante del cliente.

No lo tomes como algo personal

Es un esfuerzo de equipo. Eres el líder técnico, no el único chico en el proyecto. Debes concentrarte en que el equipo aprenda de los errores o cambie el proceso.

Lidera y aprende

Parte de cualquier posición de liderazgo, incluido un liderazgo técnico, es comprender que haces lo mejor que puedes con las personas que tienes. Cuanto más trabaje el equipo en conjunto, más sabrán cuándo mencionar las cosas y cuándo no. Solo asegúrate de no caer en la trampa de dictar a tu equipo. Revise lo que salió mal y lo que salió bien semanalmente. Comunícate con tu equipo si quieres que hagan las cosas de manera diferente. La medida punitiva siempre debe ser un último recurso y generalmente significa que debe despedir a alguien o que ha fallado en su papel.

Revisión antes de la presentación del cliente

Si usted es el líder de un proyecto, ¿por qué no había revisado la característica y la implementación antes de que se presentara?

Si está mal, arréglalo

Explique claramente por qué algo está mal y cámbielo. Es más costoso, pero si está realmente mal, entonces arréglalo. Si no está mal, simplemente diferente de cómo quería que se hicieran las cosas, de nuevo; entiendo que no eres el único que trabaja en el proyecto.

¿Hubo alguna especificación que documente lo que se supone que debe implementarse? Dado un requisito demasiado abierto, los desarrolladores a menudo llenan los espacios en blanco (o requieren microgestión) con lo que consideren apropiado.

Entonces terminas yendo a tu gerente con "Entonces, en lugar de trabajar en lo que está en la especificación, decidieron hacer [función] en su lugar. Ahora estamos atrasados, debido a una función que no fue aprobada en primer lugar".

Luego, puede comenzar a trabajar para eliminar la función una vez que los desarrolladores hayan sido reasignados.

editar> Y no, no creo que estés siendo dominante. Su trabajo termina siendo tu trasero.

A menudo me encuentro en la misma posición y, al parecer, lo planteo en reuniones y discusiones no parece llegar a ningún lado. A veces, como último recurso antes de resignarme a tomar la decisión (aunque no la mía), envío un correo electrónico a las partes relevantes indicando esto en blanco y negro con mis razones.

Luego archivaría ese correo electrónico para asegurarme de tenerlo para referencia futura en caso de que sea necesario más adelante cuando un gerente o cliente pregunta por qué se hizo algo de esa manera, o por qué un cambio cuesta tanto solucionarlo.

Creo que te equivocaste al mencionarlo como lo hiciste, como reconociste. No se equivoca al decir que debe tener alguna información sobre el diseño a este nivel, pero no estoy seguro de cómo espera implementar eso que sea razonable. La gente no va a ejecutar un diseño tuyo si lo consideran sencillo; ya que pueden estar equivocados con la misma facilidad con respecto a que sea sencillo como pueden sobre el diseño en sí mismo, no encontrará personas que se ofrezcan como voluntarios para mostrarle todos sus diseños incorrectos. En este punto, tengo curiosidad por sus hábitos de trabajo y patrones de comunicación, pero en realidad, no importa cómo se haga todo, a veces quedará sorprendido por estas cosas. A falta de revisar diligentemente cada confirmación, no estoy seguro de cómo se prueba esto.

Con demasiada frecuencia me siento así emocionalmente:

 I of course think I'm right....I always do. 

pero tengo el sentido intelectual de saber que ocasionalmente estoy equivocado. También sé cuándo elegir una pelea: no puedes discutir sobre todo y, a veces, un acuerdo inesperado de tu parte puede hacer maravillas.

¿Qué es un verdadero líder?

Es alguien que puede despedir a un subordinado, cualquier subordinado. (pero no necesita contratar uno nuevo)

A veces, la mayoría de las personas son "etiquetadas" como líderes de algún proyecto, pero, sin el poder de despedir a alguien, es más una "guía" / "maestra" que un verdadero líder.

Pero nuevamente, puede suceder que usted pueda ser un líder de equipo pero no liderar su proyecto actual. El peor de los casos es cuando el cliente lidera el proyecto. En este punto, si el proyecto falla (y fallará), entonces, no es su responsabilidad.

Y el peor de los casos es cuando existen dos líderes de proyecto.

Como militar, las cadenas de mando lo son todo (no tan radical como "morir por un proyecto" pero lo suficientemente cerca). Para este asunto, su gerente rompió su estatus, bajó la moral de "su" gente y no ayudó en absoluto.

Sí, su jefe tiene razón: no puede participar en todas las decisiones. De hecho, es imposible atrapar todo así a menos que lo haga todo usted mismo. Creo que de ahí es de donde vienes: sientes que no puedes manejar bien todo el proyecto a menos que estés involucrado en cada pequeño detalle, pero no puedes estar involucrado en cada pequeño detalle sin abrumarte (lo que desmoralizará totalmente el equipo y probablemente te quemes).

La respuesta no es preocuparse por las cosas que salen mal, siempre lo hacen, sino preocuparse por arreglarlas después, de manera constructiva.

Si se mantiene al día con la comunicación, no solo puede delegar, sino que puede dejar que sus personas mayores se vayan y hagan lo que saben que es necesario sin siempre detenerlos con revisiones, discusiones e intentos equivocados para controlarlos. Confíe en ellos para que hagan lo correcto, y esté allí para 'conversar' sobre lo que está sucediendo para que pueda mantenerse informado (y meter la nariz cuando sienta que realmente es necesario).

Tienes varios problemas Primero, su gerente se puso del lado de su equipo y le dijo que delegara más. Esto muestra una falta de confianza en su capacidad para liderar el equipo. De hecho, muestra que si bien tienes el título de líder tecnológico, de hecho, no eres el líder tecnológico porque no tienes autoridad. Necesita sentarse con su gerente y tener un corazón a corazón sobre esto. Nadie puede tener éxito en una posición de liderazgo técnico sin el apoyo de su gerente y sin la autoridad para cambiar las decisiones de diseño tomadas por el equipo sin su consentimiento. No tienes la autoridad para hacer tu trabajo. Su jefe necesita comprender que usted está en una posición sin ganancias y que debe brindarle su apoyo público para que mejore. La responsabilidad sin autoridad es la peor situación posible para encontrarse.

Luego, tu equipo te sorprendió. Necesitas hablar de esto con ellos. Debería tener una discusión de diseño con ellos antes de que realicen cualquier desarrollo y mucho antes de que hagan una presentación pública. Está bien delegar parte del diseño (aunque usted, no ellos, puede decidir qué cree que debería delegarse), pero no está bien que continúen sin informarle. Han perdido su confianza al cegarle, ahora tienen que aprender un mejor comportamiento. Debe consultar con ellos con frecuencia para asegurarse de que no lo vuelvan a dejar ciego y, si lo hacen, debería informar a HR de algún tipo de problema. Los leads no son leads para ser populares, cuando los desarrolladores los rodean deliberadamente después de que se les diga que no lo hagan, entonces merecen consecuencias. No lo hace No importa si les gustas o no, pero claramente en este momento no te respetan. Necesitan tener consecuencias por su comportamiento inapropiado o simplemente empeorará. Sin embargo, no puede solucionar esta parte del problema hasta que solucione el problema de soporte de administración.

A continuación, explotó públicamente, debe disculparse públicamente. Esto te ayudará a recuperar tu reputación.

Luego, debe llevar a cada una de las personas a un lado en privado y decirles las consecuencias de su continuo mal comportamiento (una vez que haya logrado que su gerente acepte permitirle darles consecuencias). El elogio público y el apoyo, la crítica privada debe ser su regla. También es posible que deba consultar con ellos con más frecuencia fuera de las reuniones del grupo para que no puedan cegarle.

Ahora, francamente, ya que tanto los de arriba como los de abajo piensan claramente que son alguien a quien se puede ignorar y no mantenerse informado, es necesario que se investigue seriamente sobre lo que está causando que le falten al respeto. También debe decidir si no sería más feliz no ser un líder tecnológico o si debería mudarse a un lugar donde tenga la autoridad para ir con la responsabilidad. Si decides que quieres quedarte en la posición, tendrás que pedirle a la gente que te identifique por qué te tratan tan mal. Eso será doloroso y probablemente no querrá escuchar la respuesta, pero necesita saber por qué se le percibe de la manera en que lo perciben claramente.