¿Cómo agrega valor un gerente no técnico al equipo de desarrolladores de software motivados?


63

Veo a muchos programadores alejarse de los roles de administración y administración. Quieren construir cosas. Y como resultado, muchos de estos puestos son ocupados por personas no técnicas. No veo cómo agregan valor. ¿La programación de reuniones, la reserva de sitios externos y otros trabajos administrativos son suficientes para justificar su función?


10
¿Qué porcentaje de todos los equipos de software cree que podría funcionar así sin que se interpongan egos y agendas?
ozz

30
Desde el Tao de la Programación : Un novato preguntó: "En el este hay una gran estructura de árbol que los hombres llaman 'Sede Corporativa'. Está hinchada fuera de forma con los vicepresidentes y contadores. Emite una multitud de memorandos ... ¿Cómo puede ser una entidad tan antinatural? / El maestro respondió: "Percibes esta estructura inmensa y te molesta que no tenga un propósito racional ... ¿No disfrutas de la facilidad de programación sin problemas debajo de sus ramas protectoras? ¿Por qué te molesta su inutilidad?"
apsillers


2
Más bien, los escritos recientes de Rands giran en torno a algunos de estos temas; Le doy un sello de recomendación. (¡Sin mencionar que también tiene muchos otros escritos excelentes sobre gestión!)
Jari Keinänen

Respuestas:


112

¿No veo cómo agregan valor actualmente y la programación de reuniones, reservas fuera del sitio y otra administración funciona lo suficiente para su función?

No subestimes la cantidad de interacción que hace tu gerente con otros departamentos. Manejan presupuestos, planes de capacitación, documentación de recursos humanos. Protegen a los desarrolladores de quedar atrapados en reuniones con otros departamentos y proporcionan un frente unificado para su grupo.

En resumen, su trabajo es proteger a los desarrolladores automotivados de todas las demás cosas desmotivadoras que existen en los negocios.


44
Y harán un trabajo mucho mejor defendiendo un salario / aumento.
JeffO

20
Muy +1. Ocasionalmente, obtenemos "fugas" a través del sistema y una pequeña idea de lo que atraviesan nuestros gerentes y especialmente nuestro Propietario del producto. Yo no quiero que lidiar con eso todos los días.
Izkata

1
Sé que estos son importantes, pero no obtengo la importancia relativa en el equipo de desarrollo de software y el valor de estos.
Senthil Kumaran

17
@SenthilKumaran Como desarrollador, ¿preferiría pasar dos horas con un gerente de otro departamento discutiendo por qué el software no está completo, o prefiere pasar esas dos horas escribiendo código? Usted sabe lo difícil que es explicar los problemas técnicos a su gerente. Imagine tratar de explicárselo a alguien que sabe incluso menos que su gerente no técnico. Los mejores gerentes no técnicos evitan que sus desarrolladores hagan todo lo que desperdiciaría el tiempo de los desarrolladores que mejor se dedica a la codificación y las pruebas.
David Navarre

55
Esto una y otra vez. Incluso para un gerente técnico, esta sigue siendo la mayor parte de su trabajo.
Earlz

36

Los mejores gerentes son magos. Hacen desaparecer al resto de la compañía para sus desarrolladores. No puedo recordar la cita exacta de Joel, pero fue algo en el sentido de que el trabajo de la gerencia es asegurarse de que haya una gran pipa de Internet, una bestia de máquina y mucha cafeína, por lo que todos los desarrolladores tienen que preocuparse por qué Lo hacen mejor.

Un buen gerente es la voz de su grupo para el resto de la empresa.



29

Como se aplica específicamente al desarrollo de software, existen dos tipos de roles de valor agregado para los gerentes: gestión de proyectos y liderazgo de equipos.

Un gerente de proyecto interactúa con los clientes y la gerencia media, lo que ahorra tiempo a los desarrolladores. A menudo hay aclaraciones o cambios en el alcance que surgen en los proyectos, y es útil para los clientes y el gerente intermedio tener un único punto de contacto. Tratar de responder las preguntas de cada miembro de un equipo de desarrollo conduce a decisiones de proyectos no documentados y compromisos indocumentados, la ruina de la gestión del alcance.

Por otro lado, un líder de equipo está involucrado en el desarrollo de la carrera / habilidades, asegurándose de que la carga de trabajo se distribuya adecuadamente entre los miembros del equipo y proporcionando recursos y recompensas acordes con las contribuciones y necesidades individuales.

Ninguno de estos roles requiere un programador directo, de hecho, todo lo contrario. Un programador a menudo saltará a una tarea de escritura de código como la primera respuesta a una pregunta o crisis, y es útil tener a alguien cuyo trabajo sea preguntar si esa tarea realmente debe hacerse.


66
Los desarrolladores ven árboles. Sus gerentes ven el bosque.
David Navarre

99
@DavidNavarre - Los gerentes no técnicos de la OMI tienen problemas para ver algo ...
Vector

13
@Vector: a lo que parece referirse no son gerentes no técnicos, sino gerentes incompetentes.
Lie Ryan

@Vector: Me recuerda el PHB de Dilbert , pero no creo que sea lo mismo que un gerente no técnico.
hardmath

@hardmath - Entiendo :-) Su respuesta está realmente incluida en lo que otorgó el OP, según la edición. El punto que estoy tratando de aclarar es que, en lo que respecta a las cuestiones técnicas, es necesario que interrumpan. Tengo una experiencia amarga en estos asuntos ... "Un poco de conocimiento es algo peligroso" - Estoy seguro de que me entiendes. Mira mi respuesta.
Vector

12

Junto con los otros beneficios mencionados, el gerente no técnico puede hacer un mejor trabajo al tomar decisiones finales cuando hay un punto muerto entre los expertos. Sé que esto suena contra-intuitivo, pero los buenos gerentes no técnicos entienden las fortalezas y debilidades de su gente.

Ejemplo: dos programadores debaten sobre qué servidor usar para una aplicación. En algún tipo de democracia ficticia, ambos obtienen su único voto, por lo que no se toma una decisión. Esta guerra podría continuar para siempre (y con algunas personas técnicas lo hará). Alguien tiene que intervenir y arbitrar este desacuerdo y poner en marcha el proyecto. Un buen juez se apoyará en la opinión del que tenga más experiencia en esta área.

El hecho de que alguien carezca de talento, habilidad o conocimiento en un área no significa que no pueda identificar a quienes sí lo hacen. Reconocer el talento es un talento.


1
Además, un gerente no técnico está disponible para atender las necesidades del equipo en lugar de escribir código.
JeffO

1
"Junto con los otros beneficios mencionados, el gerente no técnico puede hacer un mejor trabajo al tomar decisiones finales cuando hay un punto muerto entre los expertos". Los no expertos tienen la menor cantidad de información sobre un tema específico. Solo puede ponerse del lado de uno con la mayor experiencia en esta área (o elegir una solución que crea que es la mejor). Pero eso no significa que su decisión sea correcta. La solución de un programador con menos experiencia puede ser mejor, pero el no experto no podría saberlo. joelonsoftware.com/items/2006/08/08.html
Christian P

En tal situación, una parte a menudo subestimada de la administración no siempre es dejar que las mejores personas se salgan con la suya. Un buen gerente leerá bien la situación y hará un juicio que puede no ser técnicamente correcto, pero será políticamente correcto. Si la discusión no se basa en algo importante, el gerente puede preferir a la persona que necesita más aliento o está siendo intimidada por los otros desarrolladores. Es una decisión de juicio y difícil a veces, pero es por eso que se les paga mucho dinero.
Stephen

@Stephen estuvo de acuerdo: un buen gerente sabrá cómo manejar a su gente (por ejemplo, como dijiste, alentando a la gente, etc.) Pero si estamos hablando estrictamente de tomar decisiones (importantes) técnicas, el gerente tiene la menor cantidad de información sobre el problema y es probablemente persona equivocada para tomar esa decisión.
Christian P

@Stephen: pero será políticamente correcto , esa es a menudo una muy buena manera para que un gerente no técnico pierda toda credibilidad con el personal técnico. Muy arriesgado OMI.
Vector

2

¿La programación de reuniones, la reserva de sitios externos y otros trabajos administrativos son suficientes para su función?

Si. Perfectamente suficiente. También son buenos para llamar a la administración del edificio cuando hay un problema con calor, aire acondicionado, etc. asegurarse de que las máquinas expendedoras y los enfriadores de agua estén bien abastecidos y mantenidos; traer golosinas especiales para comer; mantener la oficina limpia y ordenada ...

Haz tu mejor esfuerzo para pensar en otras tareas para mantenerlos ocupados y fuera de problemas ...

¿Su papel más importante? Mantenerse fuera del camino y no mezclarse con los programadores, y asegurarse de que otras personas no técnicas hagan lo mismo.

Considere un equipo de desarrollo como un MLB ballclub (la analogía es bastante buena en mi opinión): los gerentes siempre son ex jugadores, solo ellos saben cómo manejar la 'gestión práctica' de un equipo de profesionales altamente calificados, nerd, idiosincrásicos, que hacen cosas que la mayoría de las "personas normales" no pueden hacer.


También obtienes muchos Gerentes en Deportes que no fueron ex jugadores, o no fueron muy buenos ex jugadores: ¿Arsene Wenger, Jose Mourinho, Andre Villas-Boas, alguien? que resultan ser excelentes gerentes. Necesitas fuertes habilidades interpersonales y de organización para ser un buen PM que NO esté codificando.
bobo2000

@ bobo2000: mencioné MLB , no deportes en general.
Vector

-1

En mi experiencia, los gerentes no técnicos son los más adecuados para este papel, además de agregar valor al evitar que la empresa interfiera con el trabajo de los desarrolladores, fomentan la asociación entre desarrolladores (porque es bien sabido que los desarrolladores son introvertidos http://www.unwesen.de/ 2012/03/16 / introversión-productividad-entornos de trabajo / ), los buenos permiten que el equipo trabaje a su ritmo pero que se preocupe por la visibilidad.


2
Su respuesta sería más fuerte si citara algunas referencias externas o expandiera sus principios. Afirmar cause it's well know[n]es una forma débil de evidencia.
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.