¿Girar al desarrollador principal es una buena o mala idea?

Trabajo en un equipo que ha sido plano desde el punto de vista organizativo desde su creación hace varios meses. Mi gerente no es técnico y esto significa que todo nuestro equipo es responsable de la toma de decisiones.

Mi gerente está comenzando a darse cuenta de que hay varios beneficios de tener un desarrollador líder, tanto por su bien (un único punto de contacto y una única parte responsable de las tareas) como por el nuestro (resolución de disputas, orientación técnica organizada, etc.).

Debido a que el equipo ha sido plano, una preocupación es que elegir un desarrollador principal puede desalentar a los demás. Un no desarrollador sugirió a mi gerente que rotar al desarrollador principal es una forma posible de evitar este problema. Un desarrollador sería líder un mes, otro el siguiente, y así sucesivamente.

¿Es esta una buena idea? ¿Por qué o por qué no?

Tenga en cuenta que esto significa todos los desarrolladores: todos los desarrolladores son buenos, pero no necesariamente adecuados para el liderazgo.

Y si no es así , ¿cómo recomiendo que evitemos este enfoque sin que parezca simplemente por razones egoístas?

No rotar

No creo que nadie gane nada de la posición que se está rotando (aparte de los que no merecen ser el líder, podrían obtener más dinero del que están recibiendo actualmente).

Tener un desarrollador líder brillante que pueda hacer lo siguiente hace maravillas para el proceso de desarrollo:

1. Sabe delegar.
2. Está en control
3. Es un desarrollador experimentado.

Es una fuente única para que el resto del equipo admire y busque asesoramiento. También es el mediador entre la administración de nivel superior y el equipo central de desarrollo. No conozco ningún equipo directivo al que le guste lidiar con el cambio (a menos que sean ellos quienes lo instiguen).

Si realmente eres el más adecuado para el puesto, todos lo sabrían. Todo el mundo lo sabría (por ejemplo, la gerencia de nivel superior, su compañero de equipo, etc.) Indique que no cree que valga la pena rotar la posición (si lo cree). Luego, siéntese y déjelos hacer la designación: abstenerse de revelar nombres o de cualquier tipo de autopromoción, ya que esto lo haría parecer poco profesional

Hay dos partes para ser un desarrollador principal:

• Liderazgo técnico Para el liderazgo técnico, tiene sentido elegir un desarrollador líder diferente a nivel de proyecto. Haga que cada desarrollador sea un líder técnico para un proyecto diferente, rotando si es necesario a medida que los proyectos rotan. Este tipo de enfoque puede lidiar con la dinámica del equipo, y asegurarse de que todos sean desafiados adecuadamente

• Comunicación Un único punto de contacto para la comunicación con el mundo exterior es bueno para el mundo exterior y malo para el punto de contacto. Quien se quede atrapado con la pelota de comunicación tendrá menos tiempo para hacer un trabajo real y tendrá que correr para obtener información de todos para transmitir. Si eres el mejor comunicador y estás dispuesto a dejar de hacer la mayor parte del trabajo divertido a cambio de hablar, más poder para ti.

No es necesariamente una mala idea, siempre que los desarrolladores involucrados estén comprometidos y sean (idealmente) capaces.

Tengo problemas para encontrar referencias para esto (pero seguiré buscando), pero si recuerdo correctamente, algunas compañías ágiles hacen esto: rotan el título de "líder del equipo" en cada iteración o en otro momento predefinido período. Eso promueve la participación del desarrollador y les da a todos la oportunidad de hacer parte de la gestión del equipo / comunicación externa sin mover permanentemente a un desarrollador del desarrollo a ese rol.

Algunos inconvenientes incluyen la posible pérdida de información (esto puede mitigarse de varias maneras) y un mayor potencial de liderazgo "malo". También puede ser difícil mantener una visión / dirección para el equipo. Sin embargo, si todos están de acuerdo con este enfoque y los miembros del equipo están bien informados e interesados ​​en hacer que tal sistema funcione, puede valer la pena intentarlo.

Si gira, no lo haga durante un proyecto. No hay nada intrínsecamente malo en asignar diferentes roles a diferentes personas para diferentes proyectos, en función de quién es el más apropiado en cada posición para ese proyecto en particular. Pero no hagas que Joe sea el "programador principal" solo porque es su tiempo en la lista para realizar el trabajo. Es posible que no esté capacitado para ello, puede que ni siquiera quiera el trabajo.

Rotar al desarrollador principal en función del tiempo es una mala idea.

Todos somos buenos desarrolladores no significa que todos sean buenos líderes. Y uno es un buen líder no significa que sea adecuado para el líder de este programa.

Creo que la importancia de las misiones asignadas a los desarrolladores es diferente, y el liderazgo de cada desarrollador es diferente. Creo que puede aconsejar a su gerente para que vote. Cada uno vota a 2 personas por el mejor candidato, y la persona que obtiene más votos debe ser el desarrollador líder

Estoy dispuesto a estar de acuerdo con Jonathan Khoo en que rotar al desarrollador principal podría ser una mala idea. En general, para proyectos más grandes, hay un solo líder técnico que encabeza el proyecto y esa persona puede tener varios líderes de componentes que le informan para discutir varios problemas de todo el sistema.

Sin embargo, un punto importante que Jonathan no mencionó es que el líder técnico también desarrolla un alto grado de conocimiento institucional que otros en el proyecto podrían no tener. Al rotar el liderazgo técnico, se les exige que desarrollen ese conocimiento cada vez que se rota a alguien en la posición. Además, el líder desarrollará una relación con los clientes fuera del proyecto, ya que idealmente deberían estar presentes para algunas de las reuniones (más grandes) con los usuarios finales.

Tener un liderazgo técnico es bueno, pero si intenta rotarlos, puede encontrar que estaría mejor sin uno.

Creo que primero debe determinar cuál es el papel de esta persona, más que quién lo hace y por cuánto tiempo.

También debe determinar si esto va a cambiar significativamente la forma en que trabaja el resto y si reducirá su rendimiento. Hacer que una persona tenga que "aprobar" cada línea de su código en lugar de que lo haga un compañero puede tener un efecto grave.

Se pueden asignar diferentes roles específicos a diferentes miembros del equipo, sin que ninguno de ustedes sea "superior". Al que mejor se comunica entre el gerente y los demás se le puede asignar un papel específico para hacerlo, pero eso no significa que sea un "desarrollador principal", y que no sea la persona que sea mejor técnicamente o mejor haciendo revisiones de código.

Estaría dispuesto a apostar que si bien el equipo es aparentemente plano, ya hay un líder entre ellos, y todos ya lo saben.

Los organigramas rara vez reflejan cómo trabaja realmente la gente. Gráficos especialmente idealizados como "un equipo plano".

Si su organización es plana, haga que todos sus desarrolladores pasen por la capacitación de Análisis de requisitos y soluciones (RSA) para que sigan un proceso formal. Luego puede asignar múltiples expertos en la materia (SME) a ​​un proyecto y obtener un proceso documentado para todas las soluciones.

Además, como usted mencionó que el gerente no es técnico, esa persona aún puede manejar el proceso RSA y facilitar la comunicación. También puede asignar una PYME en particular como líder proyecto por proyecto para ayudar en la facilitación y desarrollar sus habilidades individuales.

¿Por qué el equipo de desarrollo no vota anónimamente? Usaría la votación preferencial.

1. Puede seleccionar a alguien de su equipo para dirigir su equipo.
2. Su jefe puede contratar a otra persona con experiencia para que tome esta posición.

PD: No creo que rotar sea una buena idea, la persona debe tener habilidad para comunicarse y tener una buena experiencia en la gestión de un equipo.

Como sugiere su pregunta, todo el equipo es responsable de la toma de decisiones, le sugiero que pueda mantenerlo de la misma manera. Sin embargo, para comunicarse e informar a las autoridades externas al equipo, puede tener un Coordinador del equipo seleccionado dentro del equipo. Sus responsabilidades incluirían todo lo no técnico. Para todos los aspectos técnicos, el equipo debe sentarse y debatir de la misma manera que usted en este momento. Cualquier decisión que tome, se comunicaría al mundo exterior a través del Coordinador . Esta posición se puede rotar fácilmente en función del tiempo.

El otro enfoque puede ser tener un desarrollador líder basado en el nivel de experiencia> experiencia en el mismo proyecto> experiencia en la misma compañía. Y si es necesario, la posición puede rotarse fase a fase. Idealmente, cada fase de desarrollo tiene su propio conjunto de requisitos y entregables, que se pueden planificar y trabajar como un mini proyecto. Tener una ventaja diferente para cada fase minimizaría casi todos los impactos negativos de la rotación.

En lugar de tener un desarrollador líder rotativo, tenga un líder rotativo de proyecto, alguien que tenga el mayor conocimiento y comprensión para lograr que x proyecto se complete.

El desarrollador principal suele ser una promoción y debe ganarse

Pero para ayudar a capacitar y desarrollar habilidades de liderazgo, rotar quién está a cargo de los diferentes proyectos y luego tener una medición clara de qué tan bien lo hicieron o no.

Debe haber un líder de equipo de la misma manera que hay un capitán en un barco suficientemente grande.

Si el gerente no cumple o no puede cumplir ese rol, se debe designar a uno de los desarrolladores para que lo cumpla.

Creo que primero debes darte cuenta de la suerte que tienes de tener el poder de tomar todas las decisiones técnicas dentro del equipo de desarrollo. ¿Cuántos equipos sufren la carga de una jerarquía de microgestión que les impone sus caprichos técnicos, a menudo resultando en elecciones inconsistentes, pesadillas de compatibilidad y frustración del desarrollador ...

En los beneficios de un líder de desarrollo que mencionas, algunos de ellos (orientación técnica organizada ...) ya deberían estar sucediendo si realmente hubiera una persona sobresaliente en términos de habilidades técnicas. Si este es el caso, no puedo ver cómo hacer oficialmente que esa persona sea un desarrollador líder daría mejores resultados que los que obtienes ahora. Si tal miembro del equipo no existe en su equipo, entonces no puedo ver cómo otorgar oficialmente la autoridad técnica a cualquier persona conduciría a mejores resultados que la discusión y la decisión colectiva.

Veo mucho más valor en establecer un líder organizacional, un coordinador como lo expresó el danés. No un gerente, no un jefe, sino alguien que organizaría el proceso de toma de decisiones colectivas y actuaría como portavoz del equipo, una interfaz con el exterior. Si sigue ese camino, rotar puede ser una buena idea para evitar los problemas mencionados anteriormente: diferencias salariales, celos ...

En algún momento, ser un líder es una responsabilidad más pesada que otra cosa. Alguien TIENE que asumir la responsabilidad de las elecciones, así es como funciona la sociedad cuando nadie más quiere hacerlo.

El hecho de que un equipo quiera rotar al líder puede significar que todos sienten que pueden asumir la responsabilidad de lo que hacen, y que no quieren favorecer a nadie, y parece ser algo bueno: no hay resentimientos, y Todos quieren que el equipo tenga éxito.

En esos casos, cuando hay que tomar decisiones difíciles, simplemente vote por esas decisiones y cuando necesite un representante para hablar con otras personas, simplemente elija a alguien que tenga las mejores habilidades de comunicación.

En primer lugar, creo que debes separar los roles. No hay razón para que la persona que actúa como el punto de contacto entre el equipo y el resto de la compañía deba necesariamente ser también la persona que toma las decisiones técnicas finales.

Actuar como punto de contacto no debería conferir ninguna autoridad, por lo que no debería ser necesario rotar esa responsabilidad en un horario fijo. Yo diría que el equipo se siente, todos dicen cuánto les importaría hacer el trabajo (a algunas personas les gustaría, otras podrían oponerse a hacerlo), y luego votar a alguien para que ocupe el puesto. Haz que se entienda que pueden entregárselo a alguien cada vez que se cansen de hacerlo.

En cuanto al lado técnico principal. Si todos tienen el mismo conjunto de habilidades y aproximadamente el mismo nivel de experiencia, entonces, claro, que todos intenten ser líderes. Lo importante es no cambiar absolutamente a mitad del proyecto. Espere hasta el comienzo de un nuevo proyecto y luego elija el líder que tenga más experiencia en esa área o al azar.