Soy un administrador de Linux gruñón que hace muchos scripts y se ha notado que tengo pocas habilidades de comunicación. Me parezco mucho a tu chico. De hecho, esa es la única área en la que me critican en las evaluaciones de rendimiento. Por otro lado, estoy continuamente liderando a mi equipo en innovación y resolución de problemas, y he creado y liderado el camino hacia la nueva plataforma que estamos implementando y le hemos ahorrado mucho tiempo a mi equipo y a mi empresa mucho dinero al ser permitido ser yo mismo.
A mi ex jefe se le pidió a su familia / esposa Y a la alta gerencia de nuestra compañía que dejaran su puesto ... simultáneamente. Trabajó incansablemente para equilibrar las responsabilidades de manera justa y asumió mucha carga. Durante cualquier interacción con alguien fuera del departamento, si hubo un malentendido en la comunicación que le respondió, él fue rápido para, ah, corregirlo punitivamente. Era pobre en "administrar hacia arriba", por lo que nuestro equipo fue el último en obtener recursos hasta que fue una emergencia, y luego la compañía pagó de más a los vendedores con argumentos de venta ingeniosos para hardware no probado sin consultar al equipo que usaría esas herramientas. En un esfuerzo por crear un equipo "bien equilibrado", administró nuestras listas de tareas y trató de equilibrar las tareas para que los miembros del equipo pudieran mejorar sus habilidades en áreas donde no eran geniales, lo que resultó en MUCHO código roto o implementaciones mal diseñadas. Mientras que otras personas además del autor fueron asignadas específicamente a tareas de soporte para ese código roto para que pudieran "aprender", las implementaciones, el código y las pruebas mal diseñadas crearon mucha mala voluntad entre los miembros del equipo y, de hecho,aumento de las ocurrencias del "juego de la culpa", que es una ruta rápida hacia un estado de equipo tóxico.
Mi jefe actual es un individuo tranquilo y sereno que llegó desde el puesto de administrador junior y ha trabajado para ascender. Toma buenas decisiones y depende en gran medida de los miembros del equipo para establecer sus propias prioridades. Es un excelente comunicador y reacciona con calma y en concierto con su supervisor ante cualquier problema de comunicación, ideas o necesidades expresadas por mi equipo. Él "trabaja hacia arriba" incansablemente. Es lento para realizar cambios arquitectónicos importantes, y consulta a fondo con todo el equipo antes de realizar cambios en nuestro entorno y se siente cómodo al confiar en las especialidades de los miembros de nuestro equipo.
Bajo el nuevo gerente, nuestro tiempo de inactividad se ha reducido a casi cero (que también ha reducido el porcentaje de tiempo que pasamos en tareas de soporte de aproximadamente 40% a aproximadamente 10%), la satisfacción de nuestro equipo se ha disparado, y estamos en camino de pasar de un 'quiebre bancario en hardware nuevo cada tres a cinco años' a un plan de adquisición continua que debería ahorrarle a la compañía alrededor de un millón por año durante cinco años. Ese plan era un programa de base que nunca hubiera sucedido bajo el gerente anterior, pero el nuevo gerente lo impulsó activamente a la alta gerencia y dependía de encontrar MUCHAS sinergias en las habilidades del equipo. El CIO nos ha dicho informalmente que ahora somos el único equipo en la compañía que realmente "tiene su mierda junta" y que él ' s interferirá con nuestro entorno de trabajo lo menos posible y barajará tantos recursos hacia áreas problemáticas que identifiquemos como sea posible. Esto ha sido cierto, y está haciendo que nuestro "costo" de soporte sea aún más bajo, aunque ha interrumpido las cargas de trabajo de otros equipos, pero también ha reducido el "costo" de soporte de esos equipos.
Mira, el lugar para que los desarrolladores mejoren sus habilidades es en la escuela o en su propio tiempo. El lugar para que produzcan cosas es en el tiempo de su empresa. La mejor manera de producir cosas es produciendo lo que mejor saben. Cuando trabajen en áreas donde un desarrollador no se sienta cómodo, deberían atraer a un segundo desarrollador especializado y trabajar en equipo, o el desarrollador especializado debería escribir el código y producir documentación y diagramas. Dirija las tareas de soporte a las personas que escribieron el código. Sí, esto aumenta lo que llamamos su "factor de autobús": la probabilidad de que su departamento golpee un bache de velocidad si el especialista es atropellado por un autobús. (O despedido, o cambiar de trabajo, o ...) La verdad es que su pérdida de productividad de ese miedo es de órdenes de magnitud mayor que la pérdida real cuando un "evento de autobús" sucede Lo que generalmente sucede durante un "evento de autobús" es que el heredero del trabajo del especialista lo rehace a su propia imagen para que pueda apoyarlo de manera más efectiva, generalmente resolviendo un montón de problemas y reduciendo aún más el tiempo dedicado al soporte, y la vida continúa en.
Asigne cosas a las personas que puedan hacerlas mejor. Haz que apoyen y documenten su trabajo. Fomenta su creatividad y permíteles concentrarse sin distracciones ni microgestiones. Todo lo demás es BS de la escuela de administración, que desafortunadamente parece que su empresa está nadando. Eso no significa que su equipo también necesite nadar en ella.
Desde el punto de vista de una empresa, un buen gerente promueve los valores de la empresa mientras ejecuta tareas de acuerdo con esos valores. Desde el punto de vista de un empleado de TI, un buen gerente le permite al equipo hacer lo correcto para hacer lo más rápido y limpio posible y actúa como una barrera fecal contra la alta gerencia que empuja los valores que aprendieron en las clases de MBA de fin de semana por las gargantas de los subordinados. Estás siendo un hombre de compañía, y eso podría no ser lo mejor para tu equipo. Los que tienen "buenas" habilidades de comunicación son demasiado educados para decirlo.