¿Cómo evitar la microgestión de un equipo de desarrollo de software? [cerrado]

He gestionado algunos proyectos en los últimos años y uno de los mayores desafíos que enfrento es evitar convertirme en un microgestor. Una vez trabajé con un equipo donde trabajé con un grupo de ingenieros de software, y yo estaba en el rol de PM.

Cuando me comunico con el equipo de marketing o el equipo de diseño, me resulta mucho más fácil confiar en sus opiniones y estimaciones que cuando trato con los ingenieros de mi equipo, principalmente porque he trabajado como desarrollador de software y tengo opiniones bastante sólidas sobre lo que es la respuesta correcta y lo que es incorrecto. Mirando hacia atrás, a veces pienso que las decisiones podrían haber sido una cuestión de opinión.

Con el equipo de ingeniería, encuentro que a menudo entramos en debates sobre el bien y el mal, y me pregunto si estoy cruzando la línea para microgestionar el proyecto.

  • ¿En qué situaciones has estado cuando has caído en la trampa de convertirte en un microgestor?

  • ¿Cómo puede uno saber si está microgestionando un proyecto que no sea alguien que sale y lo dice?

  • ¿Cuáles son algunas de las estrategias que ha utilizado para evitar convertirse en un microgerente?

ACTUALIZACIÓN : ¡Gracias a todos por sus maravillosas respuestas! ¡He votado a favor de cada uno! Cada respuesta tenía algunos consejos que encuentro extremadamente útiles. Si pudiera aceptarlos a todos, lo haría. Todo se redujo a las dos personas que respondieron "¿Cómo se puede saber si [s] está microgestionando?" y "¿Qué estrategias para evitar esto?" secciones de la pregunta. Fue difícil elegir entre las respuestas de Johnny y OrenD, pero al final, la lectura adicional que proporcionó Johnny fue muy útil; se centró en mi problema pero fuera del campo del software, lo que me ayudó a ver la perspectiva más como PM en lugar de programador.
Muy buena pregunta. ¡Gracias por preguntarla! Esto es algo bueno que cualquier líder de equipo o gerente debe tener en cuenta: convertirse en un microgerente accidental.
Tal como está escrito actualmente, esta publicación histórica es una encuesta de opinión. Las preguntas de la encuesta están actualmente fuera de tema en PMSE. Esta pregunta debería cerrarse, pero dejarse para la posteridad.
@CodeGnome Gracias por señalar esto y sus continuos esfuerzos para ayudar a mantener nuestro sitio actualizado y limpio a lo largo de los años. ¡Esperamos más de sus respuestas de Scrum y Agile de usted también! :)

Respuestas (14)

- ¿En qué situaciones has estado cuando has caído en la trampa de convertirte en un microgestor?

Estoy de acuerdo con Ashes en que esto sucede generalmente cuando hay falta de confianza entre los gerentes y el equipo. Además, esto puede ser un problema de la cultura organizacional de la empresa, como con una organización vertical y jerárquica.

- ¿Cómo puede uno saber si está microgestionando un proyecto de otra forma que no sea alguien que sale y lo dice?

Si usted, en un rol de gerente, encuesta a su equipo de desarrollo para saber cuál es la motivación o se da cuenta de que están dejando la empresa por la misma razón, es decir , "No hay esperanza de ascender" , entonces puede deberse a que los gerentes son dueños de cada parte de la empresa. proyecto y no dejar que la gente tome sus propias decisiones. El problema es que, a la hora de resolver conflictos, el gerente suele ser el que menos información tiene.

Si está tomando demasiadas decisiones para impulsar al equipo, entonces puede ser una advertencia de microgestión.

- ¿Cuáles son algunas de las estrategias que ha utilizado para evitar convertirse en un microgerente?

Me gusta el consejo de Joel sobre Command and Conquer y Herd of Coconuts :

  • todo el mundo es dueño de algún área. Cuando lo poseen, lo poseen . Si un gerente, o cualquier otra persona, desea brindar información sobre cómo se administra esa área, debe convencer al propietario. El propietario tiene la última palabra.

  • cada decisión la toma la persona que tiene más información.

  • la administración es extremadamente plana. Idealmente, los gerentes simplemente no tienen tiempo para meter los dedos en los pasteles de sus informes. Quizás le interese leer sobre una planta de GE en Carolina del Norte que tiene 170 empleados que reportan directamente al gerente de la planta.

Evite la gestión de "Ordenar y conquistar" o la gestión de "Golpear y correr", a menos que tenga una "Manada de cocos" en su equipo de desarrollo. En otras palabras, un administrador debe dejar en paz a los desarrolladores .

Gracias por los enlaces a Joel y el artículo de GE Plant. ¡Realmente me gusta el hecho de que incluyeste ejemplos de desarrollo de software externo! +1 Realmente disfruté el artículo de GE Plant.
Gracias de nuevo por el ejemplo de no programación. Necesitamos más de esos aquí, especialmente para ayudar a aquellos de nosotros que éramos desarrolladores anteriores. Los recursos de otros campos nos ayudan a ver cómo un PM no necesita el conocimiento técnico para crear equipos exitosos y demuestra cómo es posible confiar en los ingenieros para tomar las decisiones correctas.
@jmort253: ¡De nada! Me alegra que esta respuesta (y también su pregunta) lo ayude a usted y a muchos otros que podrían tener problemas similares. Felicitaciones a Joel Spolsky, quien proporcionó el artículo de GE en primer lugar.

Uno de los mejores métodos que he encontrado para evitar la microgestión de mi equipo es hacer preguntas en lugar de afirmar afirmaciones .

Los gerentes con antecedentes técnicos tienden a sentir que pueden resolver los problemas de sus equipos, evitar que cometan errores y decirles cuál es el camino correcto a seguir. Este comportamiento provoca una microgestión, lo que impide que el equipo crezca y aprenda, además de introducir un impacto en el compromiso del equipo.

Siempre que desee tomar una decisión o hacer una declaración y, por lo tanto, prácticamente establecer su opinión como la decisión a tomar, simplemente deténgase y haga una pregunta a su equipo . Podría ser una pregunta capciosa, pero déjelos pensar y encontrar una respuesta . A veces, la respuesta no estará alineada con su punto de vista. Puede optar por dejar que cometan un error y comentarlo con el equipo más adelante, para que aprendan de él .

Al hacer preguntas, el equipo toma sus propias decisiones y siente que tiene el espacio y la propiedad en su dominio. No sienten que están siendo micro-gestionados.

Las preguntas que podrían hacerse para ayudar a los equipos a tomar decisiones de alta calidad podrían ser:

  • ¿Pensó en las implicaciones de rendimiento de implementarlo de esa manera?
  • ¿Recuerdas lo que pasó la última vez que hicimos esto y aquello? ¿Cómo lidiaría con que este escenario vuelva a ocurrir?
  • ¿Cómo planea llegar a tiempo al punto de integración con el otro equipo? ¿Cómo lidiaría con la configuración de laboratorio inestable que tenemos ahora?
Una vez un compañero de trabajo me dio el mismo consejo. Hacer preguntas. Y tengo gerentes que hacen lo mismo. ¡Es muy efectivo! +1
Uno de mis gerentes actuales abusa de esto. Casi nunca hace una declaración declarativa. Entiendo por qué lo está haciendo, pero ahora que reconozco la técnica, he aprendido a ignorar las preguntas individuales y escuchar la línea de preguntas. @OrenD tiene razón en que, si se hace correctamente, los empleados "no sienten que están siendo microgestionados", pero si se usa en exceso, la microgestión sigue siendo evidente y la indirección es molesta.

La microgestión suele deberse a problemas más profundos, en particular, la falta de confianza entre los desarrolladores y sus administradores. Tal vez esta falta de confianza esté justificada y tal vez no; pero necesita ser resuelto si es posible.

Trabajando tanto como desarrollador de software como administrador, puedo decir honestamente que ambas partes están más felices cuando la microadministración no es un problema. Como PM, solo le dices a la gente que haga las cosas y ellos asumen la responsabilidad de hacerlo. (Aunque, la microgestión es una forma efectiva pero a menudo desmoralizadora de garantizar una calidad extremadamente alta).

Si solo está debatiendo estimaciones, no consideraría esa microgestión. Diría que la microgestión es cuando recuperas y haces el trabajo que has asignado a otras personas tú mismo. Como PM experto y ex-desarrollador de software, debe proporcionar su opinión experta en la estimación.

Estoy de acuerdo con lo que has dicho, pero no ignores el problema de debatir las estimaciones. Si solicita un presupuesto, debe haber respeto mutuo de que el presupuesto será justo y que no se modificará para adaptarse a ningún otro propósito. Si encuentra que una persona/equipo determinado sobreestima constantemente su esfuerzo de trabajo, tal vez sea porque no confía en usted para no reducir sus estimaciones.
Creo que los gerentes deben especializarse en la gestión de proyectos, no en su dominio de aplicación. He trabajado con gerentes que eran tanto expertos en software como inexpertos. La persona que hace el trabajo suele tener la mejor idea de cuánto tiempo llevará; confiar en ellos es vital.
Totalmente de acuerdo con la parte sobre el uso del conocimiento experto de PM para estimar en lugar de realizar tareas reales.

Si cree que podría estar microgestionando, entonces probablemente lo esté.

Si te involucras en los debates técnicos entre el equipo técnico, estás microgestionando. El director del proyecto debe estar haciendo gestión de proyectos .

Si usted está tomando todas las decisiones, está microgestionando. Deje que su gente que está más informada sobre los temas tome al menos algunas de las decisiones.

Si le dices a la gente cómo hacer las cosas además de qué hacer, estás microgestionando.

Si en las reuniones de equipo eres tú quien habla más, estás microgestionando.

La mejor estrategia es comprender que la microgestión no beneficia a nadie.

La mejor manera de superar la microgestión es detenerse. Es más fácil decirlo que hacerlo, pero si quiere ser un gerente exitoso a largo plazo, eso es lo que debe hacer. Esté preparado, si su gente está acostumbrada a que usted intervenga para limpiar sus desastres, es posible que se caigan de bruces varias veces porque los ha entrenado para que no se cuiden a sí mismos. Déjelos limpiar después de ellos mismos. Es la única forma en que desarrollarán las habilidades necesarias que usted necesita de ellos. Si no pueden hacerlo, contrate a otra persona. Es dolor a corto plazo para ganancia a largo plazo. Su familia lo apreciará cuando no se vea obligado a trabajar 70 horas a la semana porque no ha capacitado a su equipo adecuadamente.

Cada mal gerente que he tenido ha sido un ex desarrollador que se negó a renunciar al rol de desarrollador. Ser gerente es un trabajo de tiempo completo+. No tienes tiempo para ser un desarrollador también.

Me topé con este artículo de blog que tiene algunos consejos realmente buenos sobre cómo evitar la microgestión de un equipo y describe cómo hacer un mejor seguimiento de las tareas que delega a otros .

El artículo incluye consejos útiles, como asignar una tarea a una persona y asegurarse de que quede claro cuál es la expectativa. Además, es importante asegurarse de que la línea de tiempo sea clara para que no haya sorpresas.

Además, es bueno tener una fecha de registro para poder medir el progreso hacia la meta.

El autor de este artículo padecía lo contrario de la microgestión, no dar seguimiento a las tareas. Su consejo no solo puede ayudar a un PM a hacer un seguimiento, sino que también creo que puede ayudar a evitar que uno se convierta en un microgerente. Según el autor, la mejor manera de evitar la microgestión del proyecto es estar disponible para consultas si es necesario, pero permanecer enfocado en el resultado y no en el proceso.

Parece que está bien encaminado para evitar la microgestión. Como dicen, saber es la mitad de la solución. Como dice Dunk, la otra mitad de la solución es dejar de hacerlo.

Confíe en su equipo y déjelos cometer sus propios errores. --Y construya un búfer en el cronograma para dar cabida a esos errores. Aquí es donde debe entrar su experiencia, al saber cuál será el cronograma a pesar de sus estimaciones.

Parte de su rol como gerente de proyecto es ser un líder. Eso significa guiarlos para que puedan ser su propia unidad independiente de resolución de problemas. Al tratar de resolver sus problemas por ellos o al argumentar que deberían adoptar su solución, está siendo un dolor para ellos o, lo que es peor, parece que usa su posición para salirse con la suya, en lugar de usarla para guiarlos a convertirse en un mejor proyecto. equipo.

La microgestión es un indicador de problemas en la planificación de la calidad . No logró institucionalizar objetivos de calidad claros. Es por eso que muy a menudo tienes que intervenir y discutirlos nuevamente.

Tan pronto como vea la necesidad de discutir "lo que está mal y lo que está bien" en las decisiones técnicas tomadas por los ingenieros, vuelva a los objetivos de calidad. ¿Están especificados por escrito? ¿Son realmente objetivos?

Un poco más sobre la microgestión: http://www.yegor256.com/2015/09/22/micromanagement.html

Una de las mejores maneras de evitar la microgestión es primero darse cuenta de que al microgestionar se está convirtiendo en un cuello de botella humano. Nada sucederá sin ti, y tu tiempo productivo se perderá haciendo cosas y resolviendo problemas para otros que deberían haber aprendido a resolver por su cuenta hace mucho tiempo.

Una vez que te das cuenta de esto, la pregunta "¿cómo puedo hacer que otros aprendan a resolver sus propios problemas? " se convierte en la pregunta principal. A partir de ese momento, necesitas dedicarle tiempo a tu gente para que aprenda nuevas habilidades, y eso, sumado a una actitud de "yo te entreno para que resuelvas tus propios problemas", es lo que los capacitará para resolver sus propios problemas ( también conocido como "autoorganización"). En el camino, tendrá que enfrentarse a plazos poco realistas, eliminar compromisos y enfrentarse a problemas que podría haber estado evitando mediante la microgestión.

Jerry Weinberg escribió

"La gestión, bien hecha, es un trabajo muy duro".

Tenía toda la razón. Leería su libro " Manejando Equipos Congruentemente ".

También añadiré descaradamente que he escrito sobre este proceso en el libro Notes to a Software Team Leader . Escribí el libro que desearía tener cuando recién comenzaba a liderar equipos.

Espero que esto ayude.

Reconocer el problema es el primer paso.

Ahora, vaya a la causa raíz... pregúntese por qué, luego pregúntese por qué hace eso y así sucesivamente hasta que comprenda cuál es el problema central que lo lleva a la microgestión.

La mayoría de las veces necesita dejarse llevar, permitir que personas calificadas hagan su trabajo y necesita trabajar más duro para asegurarse de que tengan todo lo que necesitan [justo antes de que lo necesiten] para que tengan éxito... en otros casos, aunque Por lo general, este no es el caso, la microgestión es en realidad lo apropiado [porque alguien no es lo suficientemente maduro o calificado para la tarea que se le ha asignado].

Reconocer el problema y luego comprender la causa raíz le permitirá discernir la diferencia.

Buen consejo. ¡Gracias! +1

De ninguna manera pretende ser una crítica, pero quizás la solución más fácil sea encontrar más trabajo por sí mismo.

La microgestión requiere mucho tiempo para el gerente, y si reduce su tiempo disponible, tendrá que concentrarse más en lo que necesita o no controlar.

No se recomienda para los adictos al trabajo, ya que tienden a tomar prestado el tiempo del lado equivocado de la división trabajo/vida (o trabajo/familia, trabajo/bar).

Nuevamente, como gerente de proyecto, debe liderar, no hacer.

Liderar significa que debe iniciar la pasión y la experiencia de sus compañeros de equipo haciendo preguntas y estableciendo metas. Lo más importante es comprometer el marco de tiempo para cada fase del proyecto.

Luego, solo necesita realizar la gestión del proyecto y anticipar los riesgos involucrados mediante el uso de la matriz de riesgo durante la fase del proyecto.

Le recomiendo que reconozca que, ya sea que sea un experto en la materia o no, ya no es un colaborador técnico. Usted no es dueño de esas estimaciones ni puede decidir qué técnica usar. Seguir tratando de definir los aspectos técnicos del proyecto solo conducirá a la frustración de su parte porque ya no tiene autoridad sobre esas decisiones. Cambiar sombreros.

Uno de los mejores consejos que he recibido, como nuevo gerente de desarrollo de aplicaciones, fue cuando mi gerente me dijo que ahora me evaluaba por el éxito de mi equipo, ya no por mis habilidades de desarrollo de programas.

Soy Dana y trabajo como directora de proyectos en un estudio digital. Tengo 3 años de experiencia en el campo, en los que he ayudado a crear varias aplicaciones web y móviles.

Aquí están mis respuestas, espero que esto ayude:

¿En qué situaciones has estado cuando has caído en la trampa de convertirte en un microgestor?

Especialmente cuando trabajo con diseñadores o desarrolladores principiantes o de nivel medio, me doy cuenta de que confío menos de lo que debería. Comienzo a tomar decisiones de diseño o codificación solo para asegurarme de que nos estamos moviendo lo suficientemente rápido o en la dirección correcta con el proyecto.

¿Cuáles son algunas de las estrategias que ha utilizado para evitar convertirse en un microgerente?

¡Confía en tu equipo! Déles la responsabilidad de la tarea: todos intentarán comportarse lo mejor posible si saben que el cliente ve su trabajo directamente y que usted no está allí para limpiarlo. Definitivamente revisarán todo dos veces y serán más conscientes de la calidad del diseño/código que producen. Ten paciencia, ellos también llegarán a las conclusiones correctas, incluso si son más lentos que tú :). ¡Y tal vez lo sorprendan y presenten soluciones aún mejores! Solo asegúrese de indicar los requisitos en voz alta y clara, proporcione especificaciones exactas y claras para comenzar. Luego, simplemente "inspeccione lo que espera" y brinde comentarios constructivos. Al permitir que su equipo cometa errores y aprenda de ellos, también les permite crecer y tener más y más confianza.