¿Un equipo de desarrolladores necesita un gerente?

Fondo:

Actualmente formo parte de un equipo de cuatro personas: 1 gerente, 1 desarrollador senior y 2 desarrolladores. Realizamos una gama de sistemas / proyectos internos a medida (por ejemplo, 6-8 semanas) para una organización de alrededor de 3500 empleados, así como todo el mantenimiento y soporte requerido de los sistemas que se han creado anteriormente. No hay suficiente de nosotros para hacer todo el trabajo que se nos viene a la cabeza; tenemos poco personal. La gerencia reconoce esto, pero las restricciones presupuestarias limitan nuestra capacidad de reclutar miembros adicionales para el equipo (incluso si recuperamos el salario en ahorros).

El cambio

Esto nos deja donde estamos ahora. Nuestro gerente debe dejar su rol en pastos nuevos, dejando una vacante en el equipo. La gerencia está utilizando esta oportunidad para reestructurar nuestro equipo, lo que vería el rol de gerente del equipo reemplazado por otro desarrollador y otro desarrollador senior. Su lógica es que necesitamos más desarrolladores, así que aquí hay una forma de financiarlo (una de las funciones se financia parcialmente de otra publicación vacante).

El equipo no tendría un gerente de línea directa y los roles y responsabilidades se dividirían entre las personas mayores y el gerente de servicio (relativamente nuevo para publicar) (un rol no técnico con poco o ningún conocimiento / experiencia de desarrollo cuyo enfoque es compartido entre otros equipos e individuos), que sería nuestro próximo gerente real en la cadena alimentaria.

Supongo que la pregunta final es:

¿Es posible dirigir un equipo de desarrollo sin un gerente? ¿Has tenido experiencia en esto? ¿Y qué cosas podrían salir mal / podrían beneficiarnos?

Idealmente, me gustaría "ver la luz" y los beneficios de hacer las cosas de esta manera, o presentar algunos puntos para argumentar en su contra.

Cuanto mayores son los riesgos, más necesita "cobertura de aire". Esto es lo que realmente se supone que debe proporcionar un gerente. Mientras el equipo hace el trabajo, se supone que el gerente debe asegurarse de que no haya nada que evite que el equipo logre los objetivos del equipo. Ya sea que esté ajustando el cronograma, ejecutando interferencias entre el equipo y el personal de ventas, o simplemente asegurándose de que el equipo sea pagado a tiempo y que la máquina de café permanezca en funcionamiento. Un gerente realmente excelente permite que el equipo funcione casi como si el gerente no estuviera allí.

La realidad, por supuesto, es que la mayoría de los gerentes fallan completamente en esto. O bien microgestión, o se vuelven obsoletos para que los niveles superiores de la empresa puedan controlar las cosas más directamente, y los gerentes verdaderamente grandes son realmente un pájaro raro. En lo que respecta a un equipo de software, hay algunos pros y contras en ambos sentidos cuando se trata de tener una estructura de equipo jerárquica o plana. Si el equipo es muy pequeño y el trabajo realizado requiere muy poca superposición (y con eso quiero decir que todos tienen un proyecto independiente), entonces, según mi experiencia, una estructura de equipo plana (es decir, no administrada) puede funcionar muy bien si todos Los miembros del equipo son disciplinados. Sin embargo, también ha sido mi experiencia que donde hay una gran superposición en el trabajo que hacen los miembros del equipo, donde hay dos o más personalidades relativamente fuertes,

Hay muchos factores involucrados, sin embargo, todo se reduce a las personalidades involucradas, sus motivaciones individuales y objetivos de carrera, y el ejemplo y la orientación brindada por la alta gerencia que determinará cuán necesaria es la posición de un gerente o líder de equipo. En general, si hay algún caos, y cuando el equipo lo solicita, el equipo claramente necesita liderazgo. Si las cosas generalmente funcionan bien sin la participación de la administración, entonces quizás el equipo pueda administrar dentro de una estructura no jerárquica por un tiempo ... al menos hasta que la carga de trabajo y el cronograma se vuelvan demasiado difíciles de administrar.

Alguien debe ser el gerente, pero en el caso de su equipo, no creo que este sea un puesto de tiempo completo. Contratar a otro sr. dev y hacer uno de ellos el gerente. Idealmente, el que mejor se adapta a ser un gerente y no necesariamente el mejor programador.

El gerente debe tener la decisión final cuando no hay consenso, por lo que la persona debe estar técnicamente calificada. Evaluar a los otros programadores, las reuniones y defenderse de la alta gerencia es parte del trabajo.

Lectura sugerida: El año sin pantalones . Incluso un gran proyecto de software (WordPress) puede pasar sin administradores directos, pero hay algunas tareas (nadie quiere hacer / son muy difíciles) o requieren la integración de una gran cantidad de desarrolladores para la misma tarea, puede ser muy difícil sin algunas Control central.

La respuesta simple a su pregunta es sí, como lo han indicado otras personas.

Una respuesta más completa pero más compleja a su pregunta es abordar:

"La gerencia reconoce esto, pero las restricciones presupuestarias limitan nuestra capacidad de reclutar miembros adicionales para el equipo"

La gerencia dice "sí, reconocemos eso, reconocemos que" son solo "palabras" para hacerte sentir mejor. ¡ No lo consideran crítico para el éxito de la organización, o realmente apoyarían realmente conseguir a alguien!

Otras cosas a tener en cuenta (ya que hay mucha psicología en esto) es cuando la gerencia te da malas noticias, pero mezcla algún tipo de broma, tal vez mencionando el problema directamente, tal vez no, pero lo que básicamente hace que sea imposible cuestionarlo ( es una técnica sutil e inteligente). Otra para observar es una reunión de 3 horas donde se le presenta el plan y a las 2 horas y 55 minutos se les pide su opinión.

Tenga cuidado con la administración que "dice" lo correcto en comparación con la administración que "hace" lo correcto.

Sin gerente = Sin responsabilidad = Desorden a largo plazo al menos. Todos harán las cosas que quieran y los mandos intermedios no estarán seguros de con quién hablar o quién tiene la razón y quién está equivocado para un problema o solicitud determinada. A menos que las tareas estén tan segregadas y tengan poca o ninguna relación, tener muchos 'pequeños administradores' no funciona en el desarrollo porque hay muchas maneras de hacer una tarea determinada y porque la administración requiere experiencia que un desarrollador ocupado no siempre ha adquirido. Es necesario que alguien vea la imagen completa. El estilo sugerido puede funcionar para equipos que brindan soporte de aplicaciones heredadas o actuales pero no en desarrollo. Para ser optimista, tomará su organización y algunas pruebas y fallas antes de que esto funcione razonablemente bien.

Estoy de acuerdo con las respuestas anteriores, pero hay una consideración importante.

Un "gerente" es un puesto, pero piense en términos de roles , un gerente es alguien que tiene ciertas responsabilidades . Independientemente de cuáles sean estas responsabilidades, negociaciones con CxO, redacción de informes, gestión de vacaciones o incluso llenar una máquina de café: su equipo necesita a alguien responsable de esto.

Profesionales : puede ser uno de ustedes, y esto podría convertirse en un gran impulso para su carrera. El resto del equipo obtendrá a alguien que no esté "asignado desde arriba", pero que comprenda profundamente las necesidades del equipo.
Por supuesto, no olvides negociar cuánto tiempo pasaría para tareas administrativas y qué queda para lo que solía hacer antes.

Contras : también es posible que ninguno de ustedes desee ser gerente. No hay nada malo en esto. Muchos desarrolladores prefieren disfrutar con el teclado y otros desarrolladores, que "perder el tiempo" con informes, diagramas y reuniones. Confía en mí, ¡cinco minutos con un jefe que grita cada mañana es extremadamente desmotivador! :)

Entonces, volvería a formular su pregunta de esta manera:
¿Es posible dirigir un equipo de desarrollo sin un gerente dedicado ? - si .
¿Está tu equipo listo para ese cambio? No puedo decirlo.
Intentalo. Vale la pena intentarlo.

Actualmente estoy trabajando en un equipo pequeño sin un gerente. Pequeña empresa. Funciona bien.

Su experiencia puede ser diferente.

Necesita un líder técnico y un gerente, sí. Sin embargo, personalmente creo que el liderazgo técnico es mucho más importante. (Si no está seguro de qué es eso, es básicamente la persona que reparte el trabajo y se asegura de que todos hagan lo que deberían hacer).

Un equipo de desarrolladores no necesita un gerente si cada persona es lo suficientemente madura como para trabajar en equipo y cumplir con las expectativas de las partes interesadas.

Hay ciertos roles (digamos desarrolladores) que requieren enfocarse en un problema que debe resolverse y no preocuparse por otros factores ambientales. Ahí es donde ayuda tener un gerente.

Habiendo dicho eso, alguien mayor que puede agregar valor siempre ayuda. Incluso un CEO reporta a un equipo de gerentes (junta directiva).

Mis 2 centavos ...

Sugeriría que depende de las batallas que deben librarse para el equipo de la organización. Si hay problemas que le impiden hacer su trabajo, entonces el gerente debería resolverlos.

Eso puede ser cosas como garantizar que las prioridades se controlen y establezcan de manera sensata, asegurando que tiene el equipo, el software, etc. que necesita para hacer su trabajo. Deben ser los defensores del equipo en la organización.

¿Cómo se relaciona con el negocio? ¿Cómo determina en qué debe trabajar? ¿Quién determina cuándo ha terminado? Si la organización se ocupa de estas cosas sin que su gerente tenga que hacer mucho, entonces genial. Pero luego puede haber cambios fuera de su equipo y tal vez si una o dos personas clave en el negocio cambian de roles pueden encontrarse en una situación difícil.

Tal vez podría elegir un líder fuerte en la organización que pueda ser su defensor, pero no necesita participar en su gestión diaria, abordarlos y ver si están dispuestos a poner a su equipo bajo ellos. (Quizás ya hiciste eso con tu 'gerente de servicio' que mencionas).

respuesta corta: sí se puede.

Respuesta larga: depende de las personalidades del equipo. Obviamente, alguien tiene que decidir lo que está haciendo y, por lo tanto, necesita a alguien a quien informar: puede que no sea necesario que sea el gerente de su equipo, pero alguien tiene que darle trabajo para hacer. Dentro del equipo, es posible que necesite a alguien para decidir prioridades y / o problemas técnicos, pero eso puede hacerlo fácilmente un líder del equipo.

Tal vez necesites fusionar tu equipo de desarrollo con otro, ¿tienes un equipo de prueba? ¿Sería mejor usar el mismo administrador para ambos, mientras mantienes el equipo de desarrollo semi-autónomo?

Me parece que el gerente de servicio puede proporcionarle con mucho gusto el trabajo que necesita realizar y también verificar que se ajuste a la calidad necesaria, y no necesita ninguna experiencia de desarrollo para realizar esta tarea: el software es una herramienta de negocios, ya sea cumple con los requisitos o no, y generalmente las mejores personas para determinar que son los usuarios. El gerente de servicio actuará como un enlace entre usted y ellos, y con suerte lo mantendrá trabajando correctamente. Solo me preocuparía que no tuviera suficiente control sobre las responsabilidades de su equipo, ya que si las cosas empezaran a salir mal, terminaría en un estado infeliz hasta que la gerencia lo hiciera (o, peor aún, a alguien más) responsable de tú.

Los equipos autogestionados no son tan extraordinarios. Por lo general, requieren métricas de rendimiento claras para crear una responsabilidad generada internamente. Su organización podría tener esto, pero si no puede generar personal adicional basado en ahorros de costos, entonces quizás esto no funcione. El otro desafío es que tu nuevo jefe no suena como alguien que supiera cómo recompensar el talento.

Para bien o para mal, parece que necesitas un entrenador de jugadores. Alguien que pueda administrar el equipo y desempeñarse en él. En un grupo de 4, esto es ciertamente factible. En un grupo de 8 o 10, no lo sería. El desafío es identificar quién debe ser este entrenador de jugadores. El valor predeterminado es convertirlo en su mejor programador, pero ¿desea vincularlo necesariamente con el administrador? No hay una respuesta rápida y difícil, aparte de decir que las organizaciones de alto rendimiento encuentran formas de no obligar a todos sus mejores técnicos a convertirse en gerentes.

El gerente tiende a ser el eslabón perdido entre la organización y su equipo de desarrollo.

• Se aseguran de que su trabajo sea relevante y satisfaga las necesidades de la organización.
• Respuesta a la alta gerencia
• Administre el cronograma para que el proyecto llegue a tiempo
• Asegúrese de que sus necesidades para el proyecto sean atendidas.

Los equipos más pequeños, con pequeñas responsabilidades, podrían funcionar sin un gerente designado. Pero a medida que las responsabilidades se hacen más grandes, necesitará a alguien que gestione todos esos riesgos y problemas.

Y dada su configuración, alguien en su equipo terminará haciendo el rol de gerente a pesar de que no están designados como tales. Por lo general, las responsabilidades distribuidas no funcionan bien. Depende mucho de cómo se distribuye y del tipo de personas involucradas.

Los beneficios de tener un gerente dependen del papel que estén jugando para su equipo. Entonces, realmente se reduce al papel necesario para el equipo:

• ¿Necesita a alguien que tenga la autoridad para resolver disputas entre los miembros del equipo y mantener al equipo enfocado en entregar un trabajo de buena calidad a tiempo?
• ¿O necesita a alguien que proporcione cobertura de aire como se menciona en una respuesta superior? Gestione horarios, decida prioridades, intervenga entre la alta dirección y el equipo, etc.

Entonces, ¿necesitas eso? ¿Pueden las personas en los puestos que anotaste hacer esto por ti? Si es así, entonces estás bien. Si no, probablemente te diriges al desastre.

Fuente: experiencia personal con proyectos grupales y equipos gestionados y no gestionados.

Creo que los equipos planos siempre son un problema, a menos que pongas a un tipo a cargo de un grupo de ingenieros de grado similar o similar.

Como mencionó S.Robins, SI todos los miembros del equipo están bien disciplinados, poner un gerente puede ser un cuello de botella innecesario aquí. Algunas de las pequeñas empresas en las que he trabajado tienen restricciones de mano de obra (debido a restricciones presupuestarias, entre otras razones) y, por lo tanto, tienden a poner a un grupo de pocos estudiantes de primer año / junior en un equipo plano con un chico un peldaño por encima de ellos administrándolos .

Si el administrador de "1 nivel superior" no puede administrar personas, esto fracasará. Los estudiantes de primer año / junior que comienzan sus carreras serán muy competitivos: intente establecerse firmemente lo antes posible en el equipo y alguien necesita controlar a las personas a veces para que su competitividad no perjudique la cooperación.

El problema con tener un equipo plano es que con la escala del proyecto inevitablemente tendrás que dejar que uno o dos muchachos hagan un poco más, asumir un poco más de responsabilidad. En este punto, tendrá que crear una jerarquía bien definida y, definitivamente, establecer un gerente adecuado para atender llamadas y administrar personas, porque muy a menudo cuando hay promociones dentro del mismo grupo, siempre hay un grupo infeliz.

La otra mala idea que veo en muchos Cos más pequeños es simplemente poner al tipo más alto en términos de designación o experiencia como gerente. O el tipo más experto técnicamente en el grupo es ascendido al rol de gerente. Nunca he visto que esto funcione.

Siento que cualquier equipo de más de 4 personas definitivamente necesitará un Gerente al inicio de su cronograma si el proyecto tiene una buena escala. Idealmente, una persona técnica con habilidades de gestión del hombre, la buena comunicación debe estar a cargo de ciertas decisiones.

Trabajo para una empresa donde adoptamos prácticas ágiles, en particular Scrum. Funciona muy bien en todos los ámbitos: los equipos de desarrollo y la gerencia ejecutiva están contentos. Consiguen lo que quieren.

1. Todos los ingenieros reportan al Gerente de Ingeniería. El Gerente de Ingeniería es un rol extremadamente técnico y funcional, y el rol requiere llevar más negocios a la división. Este rol es equivalente al propietario del producto.
2. El gerente de proyecto es un rol separado, similar a un maestro scrum, y generalmente es un contratista por un tiempo fijo (12 meses a 18 meses, sin extensiones de contrato)
3. El gerente de proyecto, scrum master, es completamente responsable de las actividades no funcionales y no de ingeniería.

Esto ha funcionado maravillosamente, ya que el equipo de desarrollo se enfoca en los aspectos de ingeniería, los analistas de negocios / propietarios de productos se enfocan en los aspectos de negocios. El gerente del proyecto es responsable del seguimiento de tareas, informes y otras tareas típicas de Scrum Master.

La gerencia media se subcontrata, y no hay una ruta de crecimiento desde la gerencia media hasta la alta gerencia. La oportunidad de crecimiento es desde el equipo de desarrollo o el rol de analistas de negocios hasta el gerente de ingeniería, y no desde los roles de supervisión.

Nuestra compañía cree firmemente que la gerencia media no es un valor agregado importante para una compañía, y es mejor dejarla a compañías de consultoría externas.

Un punto que vale la pena señalar es que, independientemente de si designan a una persona como gerente, es probable que uno de ustedes se convierta en el gerente 'de facto', probablemente la persona con más experiencia / tiempo servido.

Particularmente, ya que esto se está haciendo como una medida de reducción de costos (es decir, no le pague a un gerente, contrate a un desarrollador) en lugar de como un pensamiento a través de la reestructuración, parece probable que la alta gerencia continuará trabajando como lo han hecho. anteriormente, solo trataba con las personas que conocen mejor (es decir, la porción más larga).