Cómo liderar un grupo de desarrolladores que tienen mucho más talento que tú

Recientemente me pidieron que asumiera un rol híbrido de liderazgo/desarrollo con el cliente para el que estoy trabajando. Estaré facturando a una tarifa más alta y seré responsable de informar y otras tareas administrativas.

No me preocupan mis habilidades de liderazgo, ya que he dirigido equipos antes. Sin embargo, en esta función, no soy realmente el jefe del equipo: no puedo tomar decisiones sobre el personal y, en gran medida, solo soy responsable de informar sobre el estado de mi equipo al siguiente nivel. Estaré facturando ~150% de lo que están facturando mis compañeros de equipo.

Mi preocupación es que mi equipo está formado por personas que comenzaron antes que yo y tienen una enorme cantidad de experiencia en desarrollo de la que yo carezco. ¿Cómo me respetará este equipo cuando saben que mis habilidades técnicas son, bueno, deficientes en el mejor de los casos, al menos en comparación con ellos? Todos ellos habrían sido buenas opciones para la posición de liderazgo que estoy tomando.

¿Son estas preocupaciones justificables? ¿Cómo puedo ayudar a aliviar la frustración que algunos de los miembros de mi equipo podrían sentir?

Relacionado: esta pregunta , sin embargo, estos no son compañeros de equipo expertos de alto nivel que estaré cuidando. Nivel de entrada y un paso por encima.

EDITAR : Realmente quiero aclarar en base a algunos de los comentarios/respuestas. No me estoy moviendo a una posición de gestión. Tampoco estoy preocupado por mi capacidad para liderar al equipo. Me preocupaba en gran medida cómo se sentirían mis antiguos iguales acerca de esta transición y cómo puedo aliviar algunas de las preocupaciones que tendrán. Y como muchos carteles han señalado, en su mayor parte, ser un buen líder y dejar que lo superen es un gran consejo.

@snowlockk Se suponía que uno de ellos tendría el trabajo (ese era el plan original). Otro que conozco ha estado hablando de esperar el papel en el enfriador de agua. No saben que me lo han asignado.
Re "mis habilidades técnicas son, bueno, deficientes en el mejor de los casos", ¿no es esta la definición de un gerente? En serio, haz bien tus tareas de gestión.
@jamesqf Una mejor reformulación de esto sería "falta confianza en mis habilidades técnicas en el mejor de los casos"
@ USER_8675309 - Eso no cambia mucho el significado. La mayoría de los técnicos son dirigidos por personas no técnicas. El hecho de que haya comenzado en una posición técnica no significa que no será respetado como gerente. Realmente, la única forma de perder el respeto es si haces alarde de tus "conocimientos técnicos" y te equivocas. También conocido como "Deberíamos hacerlo de esta manera" cuando solo crees eso personalmente debido a tu falta de habilidad técnica. Si no lo sabe, déjelo en manos de alguien que lo sepa. Eso no solo está bien, sino que es, de hecho, una buena práctica.
algo relacionado: Principio de Dilbert
Los que pueden, que hagan . Los que no pueden, lideran .
Entonces, ¿por qué se le factura al 150%?
Eres un líder, no un comandante. No está allí para decidir cuestiones técnicas y decirle a la gente cómo hacer su trabajo; su propia experiencia técnica puede ser tanto un obstáculo como útil. Simplemente haga su trabajo y no use su autoridad para hacer alarde de su (autoadmitidamente carente) habilidad técnica. De hecho, el hecho mismo de que el líder alternativo fuera significativamente mejor que usted en el rol técnico probablemente contribuyó a que usted fuera elegido como líder; no tiene sentido desperdiciar a un gran colaborador técnico en un rol de gestión, a menos que también sea el mejor gerente.
Deles lo que necesitan para hacer el trabajo de manera efectiva y recuérdeles que usted confía en su juicio.
¿Crees que al francotirador del ejército le importa que el comandante de su compañía no pueda disparar tan bien como él? ¿O al conductor del tanque le importa que el general no pueda conducir un tanque tan bien como él? No. Quieren líderes que sean buenos para ser líderes. Haz eso. Lea algunos libros sobre liderazgo y sobresalga en eso.
@jamesqf En el mundo técnico, es mucho más común que los gerentes carezcan de habilidades de gestión, ya que a menudo son promovidos apresuradamente de las filas de desarrolladores sin ningún tipo de capacitación.
@Laconic Droid: Cierto, por eso (si tienes suerte) la secretaria del departamento termina dirigiendo las cosas :-)
Para evitar confusiones, es posible que desee diferenciar su función entre la de "supervisor" (es decir, un "jefe") y la de un "líder de equipo" (es decir, un miembro senior del equipo que ofrece liderazgo y orientación a otros miembros del equipo). ). No es raro que una sola persona ocupe ambos roles, pero la mayoría de la gente de TI entendería fácilmente la diferencia entre las responsabilidades involucradas en cada uno.
Sé el mejor protector de carne que puedas ser.
"Todos ellos habrían sido buenas opciones para la posición de liderazgo que estoy tomando" - pero ninguno de ellos fue elegido - usted lo fue.
Tengo el hábito de contratar siempre a personas más inteligentes que yo. No es broma.
Un líder de proyecto técnico debe ser el mejor en las tecnologías involucradas. Por el contrario, un gerente de proyecto no necesita ser muy hábil en las tecnologías del proyecto, pero debe tener habilidades de gestión. Las habilidades de "liderazgo" deberían ser parte de ambos, pero los dos puestos no tienen la misma descripción. Las tareas administrativas son (esencialmente por definición) más dentro de un rol de gerente de proyecto. No es tan importante qué etiqueta va con un rol real como lo es tener muy claro dentro del equipo cuál es tu rol.

Respuestas (12)

Como desarrollador, estas son cosas que odio:

  1. Solicitar software/recursos tarda una eternidad y necesita muchos formularios, etc.
  2. Requisitos estúpidos que son contradictorios con otras características o que técnicamente no son posibles debido a la funcionalidad existente.
  3. Se establecen plazos irrazonables y arbitrarios/retirados de la nada.
  4. No saber la prioridad de mi trabajo.

Entonces, si puedes resolver lo anterior, entonces no me importaría un carajo lo que estás haciendo. Si haces mi vida más fácil, cuando me pidas que haga X/Y, estaré mucho más inclinado a hacer todo lo posible para ayudarte.

Use su conocimiento técnico para asegurarse de que los desarrolladores obtengan lo que necesitan y el conocimiento comercial para resolver cuándo se están haciendo las cosas.

Habrá gente a la que no le guste (es decir, aquellos que lo querían, etc.). Trátelo como una práctica de gestión habitual (así que busque las preguntas relevantes aquí para obtener orientación).

No lo eligen para realizar "tareas de administración" porque es el mejor desarrollador. Se le elige para hacerlo porque se le ha considerado la persona que desempeñaría ese papel con mayor eficacia.

Sí, actúa como expedidor y tu equipo te amará. +1
+1 de mi parte también. Mi jefe favorito nunca supo nada sobre cómo escribir código, pero fue un defensor para mí. Sabía que siempre me respaldaba y que sería un amortiguador entre el cliente o la gerencia y yo. No cambiaría eso por ninguna cantidad de excelencia técnica.
+1 La resolución de tales problemas es parte de la responsabilidad de un Scrum Master, por ejemplo, que es un rol de liderazgo de servicio. No se trata de tener las mejores habilidades técnicas y experiencia, se trata de eliminar los obstáculos para que los desarrolladores realmente buenos puedan hacer su trabajo de manera efectiva. Haz eso por ellos y tendrás su respeto.
Puntos de bonificación: a veces puede ser contraproducente tener al mejor desarrollador haciendo "tareas de administración": están gastando tiempo administrando lo que podrían estar usando para escribir más/mejor código. Idealmente, desea que el tipo de "administración" sea el desarrollador menos bueno que pueda realizar la administración de manera efectiva.
+1, Es curioso cómo nunca se trata de lo que eres, sino de lo mejor que puedes hacer con la situación que enfrentas. Nos quedamos atrapados pensando en lo que somos en lugar de enfrentar la situación con lo que podamos dar.
"No te están eligiendo para hacer 'tareas de administración' porque eres el mejor desarrollador". +1. El conjunto de habilidades de un buen gerente es diferente al de un buen desarrollador. Sea un buen gerente y no se preocuparán por sus habilidades tecnológicas.
+1 para prioridades y plazos. Como necesitaba explicar más veces de las que debería, si todo tiene prioridad "inmediata", entonces toda la lista de prioridades puede irse por el desagüe. Espero que mi gerente sepa lo suficiente para establecer prioridades y realmente hacerlas diferentes. Además, si mi gerente me pregunta cuánto tiempo tomaría la tarea X. Y respondo "si se me permite hacer solo eso, serán 5 días", luego espero que la fecha límite se establezca no antes de 5 días a partir de ahora, y otras tareas se reprogramen. Además, como desarrollador OP, probablemente sepa que hacer 2 tareas una tras otra es mucho más rápido que cambiar constantemente...
5. No haga cosas estúpidas como no dar a los desarrolladores acceso de administrador a sus propias máquinas. (Esto casi cae en el n. ° 1, pero no del todo).
Dios mio numero 3...
5 (¿6?) . No evalúe a personas externas a su equipo (gerente de proyecto, marketing, ventas, etc.) cuando vengan a quejarse, agreguen proyectos, cambien especificaciones, etc. El trabajo realizado se ha ganado mi admiración y respeto.
Lo único que agregaría es que a veces el mejor administrador es el que traduce de manera más efectiva entre desarrolladores y clientes. Los mejores codificadores a menudo tienen dificultades para explicar las cosas de una manera que los que no son desarrolladores puedan entender.

No tienes que ser el mejor desarrollador del equipo para ser el líder. Es importante que sea técnicamente competente para mantener el respeto, ya que se encuentra en un rol híbrido. Nunca pierdas de vista que tú también eres desarrollador, ya que deduzco que seguirá siendo al menos el 50% de tu función.

En mi humilde opinión, la mayoría de los buenos desarrolladores no tienen interés en cargar con el trabajo administrativo, por lo que no tiene nada de qué preocuparse en ese sentido. Haz lo que tengas que hacer para cumplir con las nuevas responsabilidades de "líder", pero concéntrate en seguir siendo un buen compañero de equipo.

Ni siquiera necesita ser competente, siempre y cuando escuche a los desarrolladores competentes y no pretenda saber más.
Sí, +1 por conservar una generosa dosis de humildad.
@ gnasher729 Ser algo competente es ventajoso aquí. Le permite eliminar BS y tomar decisiones más inteligentes que impactan a su equipo de manera más positiva. Simplemente escuchar a alguien que parece saber de lo que está hablando, pero no poder filtrar esa información de manera inteligente, conducirá a una mala toma de decisiones. Por ejemplo, todos los desarrolladores que se entusiasman con la última tecnología hotness/buzz, pero que realmente no consideran si es realmente práctico de usar o si es la mejor tecnología para la tarea. Si no sabe nada mejor, cometerá ese error y luego se arrepentirá.
@gnasher729, ser completamente incompetente será un problema. Será muy difícil entender a los desarrolladores. Esto lleva (al menos por lo que he visto) a los gerentes técnicamente incompetentes a planificar y documentar en exceso. Falacia "no lo entiendo, pero al menos lo tengo escrito". Y eso suponiendo que los desarrolladores tengan las mejores intenciones; es posible que no, que vean al gerente como incompetente y traten de engañarlos.
@SnakeDoc + Akavail: El OP está trabajando con personas que tienen "mucho más talento" que él, como desarrolladores. No necesita competencia como desarrollador, sino como gerente. Un buen gerente detectará tonterías sin ser competente en el desarrollo. Y los desarrolladores competentes harán cualquier cosa para apoyar a alguien que sea competente como gerente y que mantenga alejadas todas las cosas que los desarrolladores odian.

Un equipo de desarrolladores talentosos busca que su administrador de desarrollo no sea mejor que ellos en el desarrollo, sino que sea un defensor contra las pérdidas de eficiencia. Su trabajo administrativo será fundamental.

¿El director viene a pedir el tiempo de X compañero de trabajo cuando ese compañero de trabajo ya está asignado al 100 % a otro proyecto? Esté allí para hablar con el director, explicar las prioridades y evitar la interrupción del compañero de trabajo.

Además , si hay que tomar una decisión técnica, reclute a sus talentosos compañeros de trabajo para que le den su opinión. Es importante saber que son más fuertes técnicamente que usted y demostrarlo pidiéndoles su opinión sobre las decisiones.

Estoy muy de acuerdo con este consejo. En lugar de pensar en ti mismo como un jefe que se supone que manda a la gente, mírate como un miembro del equipo que trabaja con el equipo, usa las fortalezas de tu equipo en lugar de tratar de menospreciarlos o ponerte por encima de ellos. Usted está a cargo de las cosas, pero puede usar las herramientas disponibles de la manera prevista, solicitar asesoramiento técnico cuando sea necesario y confiar en su equipo.
Esto coincide con mi experiencia como líder técnico de un equipo que contiene personas con habilidades superiores a las mías. El rol del líder es hacer que las cosas sucedan (y aislar al equipo), no necesariamente hacerlas personalmente. (En mi equipo también involucró parte del trabajo de custodia; por ejemplo, hice todas las integraciones de las sucursales a la principal).
Esto necesita un énfasis cuádruple en la parte de estar allí .

Mi consejo para ti es que no te subestimes.

Abandone inmediatamente la actitud de que es de alguna manera inferior a ellos, y nunca, nunca exprese esa idea al equipo, o deje que muestre que lo ha pensado siquiera una vez.

El tipo a cargo no necesita ser un experto en tecnología, debe proporcionar dirección y liderazgo. Resuelve conflictos, asigna tareas, genera métricas de rendimiento, etc. Si pudieran hacer tu trabajo serían los que facturan al 150% . Ellos no están.

En cuanto a "aliviar la frustración", no tenga miedo de reconocer que algunos de ellos tienen más conocimientos que usted, y siempre dé el crédito que se merece. Si hay un problema y [X] lo resuelve, elógielo y reconozca a la gerencia/al cliente que [X] salvó el día. Sin embargo, no tolere ningún desafío a su liderazgo. Claro, no eres el mejor desarrollador, pero eres el líder, y eso no es negociable.

Estoy de acuerdo con eso, sin embargo, creo que le faltan algunas cosas que OP debería evitar. Personalmente, cuando tengo a alguien por encima de mí que tiene algo de tecnología de fondo pero claramente le falta, realmente no me gusta cuando está tratando de eludir algunas cosas que afirmo (por ejemplo, estimación) diciendo cosas que son incorrectas o no lo suficientemente precisas. El mejor gerente de proyectos que he tenido nunca fue un 100% sin conocimientos técnicos. Nos pidió un presupuesto, no quiso discutirlo. TL; DR no intente hacer algún trabajo técnico como gerente, déjenos manejar eso y confíe en nosotros y concéntrese en su liderazgo y administración.
@walfrat: nunca sugerí que el OP ignorara los consejos técnicos. Mi propio gerente es un desarrollador autodidacta que perdió el contacto con la tecnología para pasar a la administración de tiempo completo. Pide una aclaración, pero respaldará mis decisiones cuando se dé cuenta de que está fuera de su alcance. Sin embargo, cuando toma una decisión, sigo su ejemplo. Puedo argumentar en privado que es una mala decisión, pero él sigue siendo el jefe.
+1 para las dos primeras líneas. Si no tienes confianza en ti mismo, nadie más la tendrá. Eso no significa que debas ignorar las habilidades de tus desarrolladores, pero nunca insinúes que crees que no eres apto para el trabajo o que ellos serían mejores en él.
No dije que lo sugirieras. Mi punto era decir que dices cosas que el OP debería hacer, pero creo que faltan algunas sugerencias sobre lo que el OP no debería hacer frente al tipo de perfil que tiene que administrar.
Buen consejo. Sería útil incluir también información sobre lo que percibe como el "desafío para su liderazgo" que mencionó y cómo abordarlo sin quemar la casa. Hay un dicho "Si tienes que decir que eres el líder, es bastante obvio que no lo eres".

¿Crees que un entrenador de fútbol es mejor lanzador que el mariscal de campo estrella?

Aunque ambos saben jugar al fútbol, ​​tienen diferentes funciones y habilidades en el equipo.

Su descripción suena como el modelo de "líder-servidor", y su falta de habilidades técnicas en relación con su equipo realmente lo ayudará a tener éxito.

Se ganará el respeto del equipo reconociendo sus talentos y aprovechándolos adecuadamente.

Por ejemplo, si alguien es más inteligente que usted en el "Asunto X", consulte con ellos sobre el "Asunto X" cuando tome una decisión. Esto demuestra varias cosas: (1) reconoces su talento, (2) respetas su talento, (3) quieres que el equipo tenga éxito, no tú.

Deja que te guíen técnicamente, mientras tú los lideras profesionalmente.

Indicador de éxito: cuando su proyecto esté terminado, debe sentirse como si el Equipo lo logró, no usted, o cualquier otra persona.

Te das cuenta de que no todo el mundo sabe quiénes son Bill Belichick y Tom Brady. Las analogías deportivas rara vez son útiles.
@adelphus La respuesta en sí misma deja en claro que Tom Brady es un mariscal de campo. Lo primero que supuse fue que Bill Belichick es entrenador, y una búsqueda de 2 segundos en Google lo confirmó. Si te preocupa, convierte los nombres en enlaces de Wikipedia o algo así.

Así que... aquí está el trato. Trabajas con desarrolladores que son mejores en el desarrollo que tú. ¡Eso está perfectamente bien! De hecho, comprender esto de inmediato lo coloca por delante de una gran parte de los gerentes intermedios que nunca llegan a este punto, ya sea porque contratan a propósito a personas que no son tan buenas como ellos o porque están tan consumidos con Dunning-Krueger que nunca "entienden" cuánto mejor es la gente que los rodea.

Pero no se le paga por escribir código, se le paga por administrar a otras personas que escriben código. Así que... tal vez esto ayude: considérese menos un "líder" en el sentido de un capitán de equipo y más un personal de apoyo para ellos. Sea esa pantalla entre la alta gerencia y sus muchachos: si alguien en la parte superior tiene problemas con el trabajo de su equipo o si necesita que se haga un trabajo determinado en X cantidad de tiempo, asegúrese de que usted y no uno de los desarrolladores sea la persona que recibe eso. info (y luego registrar el problema y priorizarlo). Si no tiene un BA, actúe como tal. Hablando como desarrollador, si tengo que hablar con personas que no son desarrolladores, lo haré, pero sé que realmente lo aprecio cuando hay alguien entre el populacho y yo.

La otra cosa que creo que realmente funciona y que muchos desarrolladores no necesariamente hacen por su cuenta es mucha, mucha comunicación. ¿Estás trabajando en Agile/Scrum? Si no, lo consideraría seriamente. Incluso si está haciendo Waterfall puro porque su empresa dicta que lo haga, no hay razón para no agregar algunos aspectos de Agile/Scrum como el standup diario o la estimación de la carga de trabajo por "sprint" en términos de puntos. Si alguien tiene dificultades con una tarea, llame a un desarrollador superior para hablar con ellos sobre cómo superarla y trate de fomentar una actitud de "triunfamos y fallamos como equipo" para que las personas que puedan quedarse atrás puedan captar con la ayuda de los que están delante.

Finalmente, eres la persona a cargo de los sistemas, cosas como el código base, el proceso de registro, las pruebas, etc. Como programador con TDAH, soy un. muy, muy desorganizado a veces, y b. Estoy muy, muy, muy lejos de ser la única persona que trabaja en esta profesión con esa condición particular. Personalmente, me beneficio mucho de tener un equipo de gestión/apoyo dispuesto y capaz de proporcionar estructura. Cuanto menos tengo que pensar en esas cosas, más puedo concentrarme en escribir código. ¡Oh, mira! ¡Pájaro!

También puede usar este lugar para probar cosas nuevas, y creo que cuanto más haga, más apreciará el esfuerzo su gente debajo de usted. ¿Habéis probado todos la programación en pareja? Hay gente que dice que en realidad es tan eficiente, si no más, en términos de líneas escritas por hora-hombre que la codificación de hombre a hombre. Tal vez funcione bien para tus muchachos, tal vez no. ¡Nunca lo sabrás hasta que lo intentes! ¿Qué tan comprometido está su equipo con el desarrollo basado en pruebas? ¿Qué hay de la revisión del código? No puedo decir que ninguna de estas cosas funcionará para su equipo, pero creo que la voluntad de ser abierto y probar cosas nuevas se filtrará.

El OP cumple una función híbrida, por lo que le pagan por escribir código una buena parte del tiempo. El OP es un líder, no un gerente.

Es raro que un gerente sea un gran desarrollador a los ojos de sus subordinados, porque los gerentes no pueden pasar mucho tiempo programando, lo que hace que su conocimiento se desvanezca. No me importa si un gerente alguna vez programó,

Por otro lado, no logro vaciar un vaso de agua con las instrucciones escritas en el fondo. Sin un buen gerente, soy grande en problemas. Siempre priorizo ​​y leo a las personas de la manera que creo que es correcta y nadie nunca está de acuerdo. Sin un gerente que me ayude con eso, siempre muero por causas políticas. Si tengo suerte, mi jefe me ayuda y protege para que pueda concentrarme en mi trabajo.

Tengo una pregunta para ti. ¿Por qué conseguiste este trabajo, en lugar de los otros chicos? ¿Qué justifica que su tiempo sea facturado al 150% por los demás? Si no sabes las respuestas, tienes que averiguarlo.

Aquí hay una pista. La programación es fácil en comparación con la gestión. Las computadoras son geniales, las personas son un dolor en el trasero. Estará lidiando con presiones económicas y de tiempo sobre las que los programadores no pueden hacer mucho. Siempre están trabajando duro y generalmente no pueden acelerar. Su proyecto estará bajo presión para tomar demasiado tiempo y costar demasiado. Alguien, con suerte usted, deberá decidir qué cambiar en los planes para que pueda reducir el trabajo y aún así cumplir con los objetivos críticos de sus clientes. Si no eres bueno en eso, serás reemplazado.

Para obtener lo mejor de su equipo, necesitarán estar inspirados por su proyecto, ya sea por la naturaleza del sistema, los objetivos respaldados por el sistema o el dinero que obtendrán al completar el trabajo. Para facilitar, debe estar entusiasmado con el trabajo o aceptar que el ambiente de trabajo y los objetivos no son tan buenos.

@antipattern Necesito aprender algo de lo que estás preguntando. Veo sanguijuelas en la gestión, pero ¿cómo puede ser sanguijuela un programador?
Quizás sanguijuela es una mala redacción. A lo que me refería era a ese tipo que parece trabajar muy rápido y siempre "termina" a tiempo. Si un gerente no es capaz de juzgar la calidad del trabajo, es posible que este tipo solo haya trabajado en la ruta del código principal y haya dejado una tonelada de errores / casos menores sin manejar allí. Es parte del trabajo de los gerentes asegurarse de que no solo haya una implementación, sino también que esta implementación funcione como se anuncia . ¿Te quedó más claro eso?

Creo que Andrew Berry ya dio en el clavo, esta respuesta es realmente un comentario extenso. No les diría que está ganando más dinero como resultado de las nuevas tareas gerenciales que realiza.

Una amiga me contó sobre algo similar que sucedió en su empresa. Los desarrolladores estaban felices de tener a alguien que se hiciera cargo del trabajo administrativo, algo que despreciaban. No veían a la persona como un jefe más como un colega que estaba a cargo de ejecutar el scrum y hacer algunos informes de PowerPoint para la gerencia, etc., y nada cambió realmente en su relación. Hasta que de alguna manera se filtró la información del dinero, y de repente hubo mucho resentimiento hacia la persona que ocupaba el puesto de 'gerencia'.

La moraleja de la historia, la información de su salario debe ser confidencial para sus compañeros de trabajo.

Este es un buen consejo. Aquí hay dos cosas: 1) el resto del equipo conoce muy bien mi aumento en la tarifa de facturación y 2) nuestros salarios no se ven afectados directamente por nuestras tarifas de facturación. Básicamente, no puedo ocultar que estoy facturando a una tarifa más alta, pero la información salarial no está disponible independientemente de lo que facture.

Los desarrolladores generalmente reconocerán que cualquier equipo necesita a alguien que se encargue de las tareas administrativas y de gestión. Si puede ser reconocido como el miembro del equipo que hace eso, habrá tenido éxito.

Para lograr esto, lo que necesitas hacer es: hacer el trabajo. Hacer planes. Ejecútalos. Asegúrese de que todas las cosas de las que es responsable sigan funcionando. Después de un tiempo, serás apreciado.

Como la mayoría de las respuestas son bastante largas, me gustaría agregar una simple.

No puedes esperar ser mejor en todo como tu equipo. Lo cual es obvio y podría ser algo bueno. Discuta los objetivos con su equipo, comprométase con ellos. Te dejarán claro lo que puedes y no puedes hacer. Si te aseguras de valorar sus opiniones pero también dejas en claro qué cosas no son importantes, debería estar perfectamente bien.

Por lo que sé como desarrollador, solo quiero que la gente sepa de lo que soy capaz y que me escuchen cuando creo que mi opinión tiene valor, creo que la mayoría de los desarrolladores son así.

Yo diría, relájate.

Fui consultor durante más de 20 años y he sido gerente y administrador, y es extremadamente raro que el gerente sea el mejor o el más inteligente desarrollador en un equipo.

El rol de un gerente de desarrollo es sacar lo mejor de su equipo, y hacer esto requiere un 20% de habilidades técnicas y un 80% de habilidades interpersonales. Tu trabajo es comprender las fortalezas relativas de cada miembro de tu equipo, fomentar una comunicación productiva, ayudarlos a prosperar y crecer en sus roles, protegerlos de las tormentas de mierda que generan la mayoría de las organizaciones y hacer que cada uno se sienta reconocido y reconocido. apreciado en su trabajo.

Todas estas son habilidades "blandas": sus habilidades técnicas lo ayudan a comprender el proceso de desarrollo y las opciones de diseño más amplias que implica su proyecto. Pero estos son realmente útiles solo en la medida en que puede ayudar a mantener a su equipo feliz, enfocado y productivo.

Solo por favor, por favor no pretenda tener conocimientos o habilidades que no tiene. Parece que estás un poco intimidado por el nivel de habilidad de tu equipo, pero tu papel no es ser el tipo más inteligente de la sala. Es para plantar las semillas, fertilizar el suelo y mantener alejadas a las langostas. Y si lo haces bien, te habrás ganado tu paga y el respeto de tu equipo.

@USER_8675309 - Puede ser un gran líder independientemente de cómo se comparen sus habilidades de desarrollador con las de su equipo. Lideras apoyando a tu equipo y liderando desde atrás en lugar de desde el frente. En este caso, en lugar de dar órdenes y adoptar un enfoque maquiavélico del liderazgo, debe centrarse en proporcionar al equipo los recursos y el tiempo suficientes para garantizar que los resultados obtenidos sean el resultado de un verdadero pensamiento colaborativo y creativo. Recuerde que cada miembro de su equipo tiene sus propias habilidades y talentos individuales. Depende de usted reconocer estos talentos e identificar a los líderes emergentes. ¡Haz lo correcto en lugar de hacer lo correcto! Buena suerte amigo... lo tienes!

Cómo liderar un grupo de desarrolladores que tienen mucho más talento que tú
RespuestasAquíPolítica de privacidad1y, 0v