¿Qué sucede si soy mejor desarrollador que mi líder de equipo?

Un error común en la ingeniería es que "el líder del equipo tiene que ser el mejor y si no lo son, puedo hacer que sean una hamburguesa".

Lamentablemente, el término es "líder de equipo", no "mejor desarrollador".

Piénselo de esta manera: Abraham Lincoln lideró la Guerra Civil, pero no fue un general ni un gran luchador. Steve Jobs dirigió Apple, pero no era un gran ingeniero.

El liderazgo no se trata de ser el mejor, se trata de inspirar a otros a que lo sigan, de guiar un barco que tiene muchas, muchas partes móviles, algunas de las cuales quieren ir por el camino equivocado, ¡algunas quieren reemplazar al líder! - hasta el destino final.

El hecho de que sea un ingeniero competente no lo convertirá en un buen gerente de ingeniería, ni siquiera en un líder de equipo. Si no puede convencer al líder de su equipo para que siga las mejores prácticas, ¿qué esperanza tiene de liderar?

¿Y qué alegría obtendrías al imponer esta vista? ¿Sabes por qué SÓLIDO y SECO son buenos? ¿Sabes que en Clean Coding, Robert Martin suspira por los días de cortar y pegar código? Solo conocer y usar un principio no es suficiente para convencer a otros por qué es bueno. Tal vez hacer eso hace que el tiempo de desarrollo sea más corto, o tal vez el líder de su equipo es de la opinión (sensata) de que cortar y pegar código varias veces es mucho más simple y más fácil de manejar que una bestia de patrón de fábrica en expansión que combina lógicas comerciales fundamentalmente diferentes. .

Si desea liderar, le sugiero que organice una reunión de equipo semanal de una hora de duración, en la que guíe a todos a través de la sustitución de un código y discutiendo las implicaciones: a los ingenieros les gusta conversar sobre el código, y esta es una buena manera de llegar a un consenso. O vaya a leer sobre Agile y presione algo como Kanban.

Pero no caiga en la trampa de que la pura habilidad es equivalente al liderazgo. Rara vez es cierto en cualquier otro aspecto de la vida humana, ciertamente no es "más cierto" en ingeniería. ¿Por qué sería?

El liderazgo necesita una visión y el liderazgo necesita ventas. De los dos, las ventas son las más importantes. La visión puede definir cuán exitoso y bien recordado será, pero las ventas lo llevan allí. Hay muchos líderes con poca visión, pero no estoy seguro de que haya alguno que no pueda vender.

Antes de responder a sus preguntas, creo que es importante mencionar que suponiendo que tenga razón y sea un mejor desarrollador que el líder de su equipo, eso no debería ser un problema. Un líder de equipo no necesita ser el mejor desarrollador del equipo. Debe ser el mejor en liderar, en sacar lo mejor de cada miembro del equipo (desarrolladores y no desarrolladores), en resolver problemas internos y externos que bloquean el flujo y la productividad del equipo, y el mejor en formar un equipo, entre otros. muchas otras cosas.

Entonces, respondiendo a tus preguntas:

¿Debería el líder del equipo estar familiarizado con las mejores prácticas?

En mi opinión, sí, el líder del equipo debe estar familiarizado con ciertas mejores prácticas. Una vez más, esta persona no será necesariamente un experto en todos los conceptos de desarrollo de software, pero debe estar familiarizado o ser competente con muchos de ellos.

¿Qué pasa si soy mejor desarrollador que el líder del equipo?

Tomemos el ejemplo de un equipo de fútbol. El capitán no es necesariamente el jugador más técnico, pero es el mejor dirigiendo y capitaneando un equipo.

Puede (o no) ser un mejor desarrollador, pero lo más probable es que el líder de su equipo sea mejor que usted para hacer muchas otras cosas que tal vez ni siquiera se dé cuenta de que esta persona está haciendo.

Concéntrese en ser el mejor desarrollador que pueda ser, sin importar cuán bueno o malo sea en comparación con el líder de su equipo.

¿Debería tratar de 'tomar su lugar' como líder del equipo?

Yo no haría esto, en absoluto.

¿Qué tengo que hacer?

Si trató de ser amable y explicó las mejores prácticas y aún así el líder de su equipo codifica de una manera con la que no se siente cómodo, no hay muchos caminos fáciles que pueda seguir. Puedes intentar tener una conversación más seria con él, siempre siendo respetuosa, explicándole tus preocupaciones, pero dudo mucho que te vaya bien.

Plantear esto con alguien de la cadena es otra opción y, de nuevo, rara vez funcionará a tu favor.

Si la situación sigue así después de haber intentado hablar con tu jefe, a veces es más fácil y más razonable encontrar un equipo y un líder de equipo que esté en línea con tu forma de pensar y trabajar, en lugar de tratar de convencer a muchas personas para que lo hagan. cambiar o mejorar para que coincida con sus deseos o estándares.

Estoy de acuerdo con las respuestas existentes: que no tiene por qué ser un problema que un líder de equipo/gerente de desarrollo no sea el mejor desarrollador del equipo. El liderazgo y la capacidad de gestión no necesariamente se superponen mucho con las sólidas habilidades de desarrollo de software.

Sin embargo, la razón por la que esta respuesta difiere de la de ellos es que creo que todavía hay un problema aquí:

por cada línea de código que refactorice habrá 10 nuevas

Creo que está bien que un líder de equipo sea un codificador menos que estelar si no está programando mucho o no se está poniendo en el camino crítico (es decir, si prioriza su rol de liderazgo sobre el desarrollo), pero suena como si en este caso, es él.

En ese caso, sugiero que su pregunta no sea tanto "¿qué pasa si soy un mejor desarrollador que mi líder de equipo?", sino "¿cómo puedo introducir las mejores prácticas frente a la resistencia de los desarrolladores establecidos/senior?"

Eso es complicado y requerirá paciencia. Las revisiones de código son un paso en la dirección correcta, al igual que las herramientas de análisis estático, la cobertura de pruebas unitarias, etc., aunque lograr que se acepte su uso puede ser un desafío. Hay otras respuestas a preguntas como esa que valdría la pena investigar.

Pensando en voz alta, también me pregunto si su líder de equipo puede sentirse presionado para seguir codificando además de liderar el equipo. Puede ser que sienta que necesita ser tan productivo como lo era cuando "solo" era programador, además de desempeñar su papel de líder. Tal vez la falta de tiempo percibida podría ser la culpable de la mala calidad de sus registros; tal vez necesita más confianza en su equipo para hacer el trabajo mientras él se queda atrás. No lo sé, pero podría valer la pena considerar la situación desde su punto de vista, tal vez incluso discutirlo con él de manera informal, solo para sondearlo ("buenos días, jefe, entonces, ¿tiene mucho trabajo hoy?" podría ser ojo -¡apertura!). Esto ayudará a saber si es un mal programador que no ni siquiera lo sabe, pero tiene la autoridad para anular a cualquiera que lo señale (una situación muy difícil de manejar), o alguna vez fue un buen programador, pero sus responsabilidades de liderazgo significan que ya no tiene tiempo para hacerlo correctamente, y solo necesita aprender a dejar que usted y el resto del tiempo lo manejen. Con una mejor comprensión de eso, su camino puede volverse más claro.

¿Sería recomendable si intentara "tomar su lugar" como líder del equipo?

No.

Si ve un rol de liderazgo como el próximo paso en su carrera, entonces, por todos los medios, trabaje para convertirse en líder de equipo (que algún día puede significar suceder al líder de equipo actual, pero eso es algo menos agresivo que "tratar de tomar su lugar" suena !). Personalmente, empezaría por aquí .

Si, OTOH, solo quiere ser el mejor desarrollador posible y ha caído en la trampa de pensar que el líder del equipo es una recompensa o un reconocimiento por ser el mejor desarrollador... concéntrese en mejorar las prácticas tanto en usted mismo como en todo el mundo. el equipo, y dejar el liderazgo y la gestión a aquellos que quieren dirigir y gestionar. (Ese papel es, o debería ser, mucho más sobre las personas que sobre la codificación). Esto podría ayudar a ver la diferencia.