Liderando un equipo, ¿estoy siendo dominante?

12

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í.

Edward extraño
fuente
1
Si el representante del cliente lo mostró como si esto fuera lo que quiere, entonces sí, no está siendo razonable. Debe argumentar (si hay uno) que lo que hicieron les impedirá obtener lo que realmente quieren en el futuro (si es que lo harán). Si puede mostrarlo en términos monetarios (es decir, si lo hacen a su manera, les ahorrará x millones de dólares), será un héroe.
Robert Harvey
1
@Robert - Estoy de acuerdo con eso con una advertencia ... Creo que debería involucrarme antes de que se muestre. Creo que debería haber tenido la oportunidad de decir: "No, no hagamos esto de esta manera y he aquí por qué". Si me anulan, no importa cuán equivocados estén los demás, entonces es así. Lo reconozco y vivo con eso. Mi problema no es tener la oportunidad mientras supuestamente soy el "líder". ¿Todavía lo considerarías irrazonable?
Edward Strange
8
No creo que te perciban como el líder, según tu descripción de la situación. Tendrás que convertirte en el "líder con el ejemplo", el tipo al que recurrir cuyas sugerencias se consideran seriamente porque haces buenas. Esto sería cierto incluso si se le otorgara una autoridad específica.
Robert Harvey
@Crazy: no, no es irrazonable, para eso está el líder.
rapid_now
1
Recuerde que el respeto se gana y no se puede hacer cumplir. Te seguirán eventualmente, si lo haces bien.
Falcon

Respuestas:

17

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.

Demian Brecht
fuente
Intenté implementar revisiones de código y pre-diseño. Ninguno de los dos funcionó debido a una variedad de razones, incluidas algunas de las que lamentaba anteriormente. También me ha costado encontrar una manera que no nos detenga. Otra parte del problema era que la gente no parecía muy dispuesta a criticar el código. También he intentado que varias personas presenten ideas / diseños para partes difíciles de nuestro proyecto. Desafortunadamente, el mío siempre fue el que usamos, así que creo que podría haber sido desalentador. Ambas son cosas que creo que debemos hacer (y pruebas de unidad también, sí), pero hemos tenido problemas.
Edward Strange
¿Alguna sugerencia? ¿Cómo podemos hacer revisiones de código sin tomar mucho tiempo? ¿Cómo puedo hacer que los otros miembros del equipo lo VALOREN (y también las pruebas unitarias)? Ese parece ser el gran problema. Parece que solo soy yo el que asigna un montón de trabajo ocupado que ralentiza a todos cuando realmente creo que estaríamos mejor. Un gran problema para mí aquí es que nunca me han orientado en este puesto, solo tuve que asumirlo (una pequeña empresa de nicho que contrata a personas directamente de la universidad). Llevo mucho tiempo en esto, pero lo aprendí por investigación, ensayo y fracaso en lugar de trabajar mejor bajo uno.
Edward Strange
2
- Algo más que me preocupa es "siempre creo que tengo razón". Veo todos sus puntos y estoy de acuerdo con ellos. Fue una mala elección de expresión mezclada con un poco de humor autocrítico. Intento evitar que mi cabello apunte hacia arriba.
Edward Strange
Existen algunas herramientas que puede usar para acelerar las revisiones de código. Las herramientas basadas en la web parecen funcionar bien: puede encontrar una lista de proyectos de SO aquí: ostatic.com/blog/open-source-code-review-tools . Por supuesto, el componente más importante para que las revisiones sean exitosas es la responsabilidad . Los revisores deben ser responsables de sus revisiones.
Demian Brecht
1
Realmente, se reduce a asegurarse de que su equipo se enorgullezca de lo que hacen y de lo que producen. Saber que su nombre está adjunto a una revisión y que han aprobado lo que está sucediendo en el cambio debería llevarlos a hacer bien su trabajo (o al menos tan bien como puedan). Si no lo están, entonces tal vez sea necesario algún tipo de tutoría (nuevamente, en privado). Descubra por qué no les importa lo que están revisando y haga hincapié en la importancia de las revisiones (menor conteo de errores, calidad del código, etc)
Demian Brecht
9

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.

David Thornley
fuente
Supongo que es posible, pero realmente lo dudo. Acabamos de contratar a un gerente y cuando solicité el mismo puesto, el CEO me llevó a un lado. Es bastante claro que no ven esa posición como un juego para mis puntos fuertes: PI puede ser abrasivo. Después de ver al chico nuevo, tengo que estar de acuerdo con algunas de las evaluaciones. Su maniobra política y diplomacia para hacer una mierda es algo de lo que ciertamente tengo mucho que aprender.
Edward Strange
"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". Sí mucho así. Siempre he tomado la actitud de extender mi autoridad lo más que puedo y ver lo que sucede. ¿Ser golpeado? Bueno, encontré dónde están los límites. Sin embargo, al hacer esto, debes estar en lo correcto más a menudo que equivocado. Desafortunadamente, el otro lado de una posición de líder / gerente es que algunas personas son REALMENTE DIFÍCILES de tratar, y cuando no son susceptibles a ninguna razón en absoluto, la vida se vuelve muy difícil.
rapid_now
4

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.

dietbuddha
fuente
3

¿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.

Steven Evers
fuente
Bueno, fue abierto en el hecho de que no decía NO hacer lo que se hizo. Todo lo que decía la historia en la que se estaba trabajando era introducir los valores en el informe en las unidades del documento. Alguien más, en algún lugar, decidió que necesitaban más que eso, con lo que podría estar de acuerdo en algún momento más adelante ... lo que me molesta es el hack, me hubiera gustado haber dicho: "Realmente no creo que debas hacerlo de esa manera."
Edward Strange
@Crazy Eddie: también puedes abordarlo de manera progresiva. Cree un error que indique que la funcionalidad necesita ser eliminada / reemplazada por lo que sea, y asígnela al desarrollador que la escribió en primer lugar. Entonces es solo negocios como siempre arreglando un error.
Steven Evers
2

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.

dreza
fuente
+1: Esto se llama "El archivo de la pistola humeante". Imprima esas cosas y guárdelas en casa.
rapid_now
2

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.

Jeremy
fuente
1

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.

Neil Butterworth
fuente
Siempre dejo que alguien demuestre que estoy equivocado o me convenza de que lo estoy. Tiendo a pensar que estoy en lo correcto hasta que eso termine: P
Edward Strange
1

¿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.

magallanes
fuente
1

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).

gbjbaanb
fuente
0

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.

HLGEM
fuente
te sorprendió? Dolor, ¿en qué tipo de organización de tiendas de sudor trabajas y tienes que pedirle a tu gerente cada pequeño detalle y acordar cada pequeño trabajo? Si no fuera por su manager, puedo ver fácilmente a todo su equipo queriendo renunciar.
gbjbaanb
@gbjbaanb, los problemas de diseño no son pequeños detalles, sino que afectan más que lo inmediato. El diseño es su responsabilidad, no la de ellos. A sabiendas excedieron su autoridad (y según la descripción no era la primera vez) y merecen ser golpeados por ello.
HLGEM
1
@gbjbaanb: eso sería muy difícil para mi empleador porque también he decidido que es hora de seguir adelante. Tengo en mí que ser un buen líder, y sé mucho (por eso terminé en esa posición), pero ser arrojado a él sin tener ningún mentor ha sido un desastre y una frustración constante para mí.
Edward Strange