Trabajo en una empresa de ingeniería mediana (aproximadamente 2000 empleados en total) en los EE. UU. Uno de nuestros ingenieros más experimentados, llamémoslo John, ha estado en la empresa durante aproximadamente 4 años y aspira a ser ascendido de "Ingeniero sénior" a "Compañero de ingeniería" (EF). Solo tenemos 5 personas en el personal en cualquier momento en el rol de "Compañero de ingeniería", y es muy competitivo (y es básicamente el doble del salario para el candidato seleccionado).
Antecedentes: John se lleva bien con sus compañeros y la gerencia, junto con 2 de los EF existentes. Sin embargo, dos de los EF mayores y John no están exactamente de acuerdo. Sospecho que esto se debe principalmente a:
He estado alentando a John a que muestre más interés en los productos principales que ofrece nuestra empresa (los ingenieros senior tienen cierto grado de elección sobre los proyectos en los que trabajan; los EF obtienen un control total sobre los proyectos que inician o en los que trabajan, por lo que siempre que eventualmente pueda generar una buena ganancia; son básicamente investigadores y expertos de la industria). John ha luchado por aprender la mayoría de nuestros productos (es decir, los heredados de Windows) y, en cambio, hace todo lo posible para trabajar solo con nuestros productos Linux más nuevos. Incluso me dijo a mí y a la alta gerencia, en términos contundentes: "Prefiero aceptar un pequeño recorte salarial y trabajar en tecnología que mejore mi CV y mi conjunto de habilidades, que dominar algo que solo es útil en una división de una empresa. Si los accionistas alguna vez exigir despidos para asegurar un buen trimestre, al menos me puedo llevar las habilidades".Le dije a John que esto podría perjudicar sus posibilidades de futuras promociones, pero simplemente señaló que es un riesgo que está dispuesto a correr y que es mejor que correr el riesgo de quedarse sin trabajo" .
Problema : durante una reunión con la mayoría de los EF e ingenieros sénior, John propuso una solución de automatización (es decir, con Docker y Kubernetes), que casi con toda seguridad dejaría sin trabajo a más de 200 desarrolladores de Windows en 16 meses. Cuando Chan lo confrontó en la reunión, John simplemente señaló: "No estoy tratando de enlatar a nuestros colegas; pueden volver a capacitarse y usar sus años de experiencia interna en proyectos más grandes y mejores". Esto dejó a Chan indignado y exclamó: "Es fácil para ti decirlo: no todos tienen la juventud y el tiempo para volver a entrenar sus conjuntos de habilidades básicas. En lugar de intentar crear más formas para que podamos resolver el mismo problema, ¿por qué no subir a bordo con nuestros principales productos y contribuir a ellos en lugar de proponer alternativas escritas desde cero?".
Después de tomarse unos segundos (parecía que John estaba luchando por controlar su temperamento), John simplemente abre una sesión de escritorio remoto, demuestra que ya diseñó el sistema en su tiempo libre y (desafortunadamente) suelta "porque ya resolví este problema en mi tiempo libre, y deberíamos comenzar a utilizar enfoques de ingeniería modernos en lugar de los antiguos que pronto serán reemplazados".
Ahora me quedo con un problema grave: Chan está solicitando a la alta dirección que despidan a John, pero algunos miembros del equipo de gestión (y 2 de los EF) también quieren ver el proyecto paralelo de John. Varios ingenieros senior se han retirado de los proyectos basados en Windows y nadie quiere (de buena gana) unirse a ellos (todavía necesitamos enviar actualizaciones a los clientes cada 6 meses) y han admitido que no quieren trabajar en algo que podría estar terminando, dejándolos como los primeros candidatos potenciales al despido.
John no debería haber arremetido con tanta naturalidad, pero Chan nunca debería haber antagonizado o bloqueado a John. Tampoco podemos encontrar el trabajo de demostración de John (no tengo idea de dónde lo almacenó), por lo que no podemos simplemente despedirlo y recuperar sus copias de seguridad si encuentra una manera de ahorrar literalmente millones de dólares por año. Le pregunté si tenía una copia de este código, y simplemente dijo "no, eso fue una grabación de video. Hice todo el proyecto en tiempo personal con mi propia PC, sin recursos proporcionados por la empresa, etc. Podría hacer una demostración". de nuevo en el futuro cuando tenga el apoyo y el presupuesto adecuados ".
¿Cómo empiezo a abordar este lío? Me han dado autoridad para disciplinar/recompensar a cualquiera, incluso a los EF (pensé que generalmente tienen más antigüedad que yo, un "gerente intermedio"), por lo que esta es una posición realmente incómoda para estar. No estoy seguro si debería simplemente despide a Chan y asciende a John, o simplemente reprende a John y Chan. ¿O despido a John por sugerir que no está compartiendo su "idea del millón de dólares" a menos que lo asciendan primero?
ACTUALIZAR:
Alguien transmitió esta publicación al #randomcanal de nuestra empresa en Slack (que generalmente son solo publicaciones de r/programminghumorreddit todos los días), por lo que el problema se ha agravado. Los administradores pueden usar StackExchange Workplace para obtener ayuda (si los datos se anonimizan), así que estoy bien y el mensaje de Slack se eliminó, pero se ha causado más daño. Que semana tan mala.
Entonces, tiene una descripción del trabajo que básicamente dice "desarrollador de alto nivel con reinado libre para elegir los proyectos que elijan con el objetivo de mejorar y beneficiar a la empresa".
Y tienes un desarrollador que escogió un proyecto, lo mejoró hasta el punto en que le daría a la compañía una ganancia de ~10 millones de dólares al año e hizo la mayor parte de eso en horas extra no pagadas (es decir, como un proyecto de pasatiempo).
Entonces tienes a un tipo que se aferra a su trabajo y la única justificación para no hacer este cambio no es técnica, sino "pero personalmente me beneficio de este desperdicio de dinero, por favor no lo detengas".
¿Y consideras despedir al primero ?
Tal vez sea el gerente el que necesita ser despedido. No emplea a nadie que encienda sus lámparas de gas cuando oscurece, ¿verdad? tu no Fueron reemplazados por esos sofisticados sistemas eléctricos automatizados. No empleas a personas porque hayan sido empleadas anteriormente. Usted emplea a personas para obtener ganancias. Y entre los dos, el beneficio de uno está alineado con el beneficio de la empresa y el otro se beneficia directamente de que la empresa gane menos.
Sin embargo, una advertencia: solo porque un tipo con una buena idea hizo que funcionara en casa, en realidad no significa que puedan hacerlo a escala o en el lugar de trabajo. Pero la respuesta correcta es desafiarlo por motivos técnicos. Asegúrese de que haya requisitos claros, pruebas, prototipos y una supervisión adecuada. Pero los argumentos en contra parecen estar motivados puramente por el beneficio personal, no mencionaste ni a una sola persona que dijera que no iba a funcionar a nivel técnico.
Tu descripción del problema no halaga a Chan. Ni siquiera compro la línea de argumentación de que John no debería haber dejado que ocurriera esta confrontación, eso fue completamente obra de Chan.
Usted es una empresa y un ingeniero le acaba de hacer uno de los obsequios más maravillosos, una solución de prueba de concepto que se propone modernizar significativamente su pila tecnológica y ahorrarle literalmente millones de dólares. Con la parte más difícil del trabajo ya realizada en el tiempo libre de ese ingeniero.
¿Qué puedes ganar al despedir o disciplinar a John? Con su ambición, motivación y habilidades, seguramente hará que alguien cague toneladas de dinero. Tienes la oportunidad de decidir si eres tú o la siguiente mejor compañía a la que se traslada.
En resumen (basado en su "sabor en su publicación", a menos que lo haya leído mal...), John muestra la visión y el enfoque para tratar de hacer progresar a la empresa, mientras que Chan parece estar inmóvil apoyando los productos heredados.
Estaría apoyando a John con productos y tecnología que quizás sean más confiables en el futuro y 16 meses son suficientes para brindar capacitación relevante para esas personas de Windows para que puedan volver a implementarse.
John parece ser leal a la empresa (tratar de promover los productos de la empresa en su tiempo libre en lugar de hacer política de oficina), honesto (decirle directamente a su gerente que no trabaja en ciertas cosas es un riesgo, pero honesto) y define un conjunto de herramientas claras que él crea conveniente. Todo eso lo convertiría, en mi humilde opinión, en una buena ventaja técnica. El problema real es que parece ser más hábil y diverso que el empleado promedio de la empresa, y debe ser consciente de que puede malestimar la inversión de desarrollar nuevos métodos/utilizar nuevas cadenas de herramientas, y usted como su el gerente debe asegurarse de que las personas de menor rango puedan seguirlo hasta allí.
Esto dejó a Chan indignado y exclamó: "Es fácil para ti decirlo: no todos tienen la juventud y el tiempo para volver a entrenar sus habilidades básicas.
Lo cual, a menos que los empleados tengan más de 60 años (cuando el tiempo para volver a capacitarlos quizás no sea una buena inversión para la empresa) es claramente ridículo, especialmente porque en cada proyecto de desarrollo de SW hay muchos trabajos que en realidad no t requieren un amplio conocimiento de la plataforma que se utiliza. Incluso diría que esta sentencia descalifica a Chan porque contiene discriminación por edad .
En lugar de intentar crear más formas para que podamos resolver el mismo problema, ¿por qué no te sumas a nuestros principales productos y contribuyes a ellos en lugar de proponer alternativas escritas desde cero?".
Esta oración descalifica a Chan aún más, porque hay muchos factores en la reescritura de un producto que no tienen ninguna relación con el argumento de pseudo-lealtad de Chan, como:
que hay que equilibrar con
Al abrir la sesión, John demostró que la Inversión no es prohibitivamente alta. No es la parte de los propietarios de productos/QA/Administración la que debe verificar los puntos anteriores, y a John se le debe decir exactamente eso. Se le debe decir a Chan que no hizo ningún argumento válido y que puede contribuir demostrando que su equipo puede satisfacer mejor las necesidades de los clientes y las empresas.
Parece que tanto John como Chan necesitan una charla seria de "ajuste de actitud" al estilo militar.
Si John es tan inteligente como cree que es, debería idear planes de transición aceptables para la empresa: después de 4 años, conoce la empresa, su administración y sus compañeros lo suficientemente bien como para saber qué es aceptable, y como posible "Ingeniero Compañero", sin duda debe tener la habilidad y la experiencia suficientes para trabajar a ese nivel (estrategia técnica de la empresa y hoja de ruta). Debe saber cuáles son los problemas y trabajar para resolverlos, en lugar de simplemente decir: "Yo tengo razón, tú estás equivocado, colócate detrás de mí".
Mientras tanto, Chan, con sus 200 desarrolladores de Windows, puede muy bien estar hasta el cuello tratando de mantener los sistemas heredados en funcionamiento y/o vendibles, pero como un EF él mismo eso no lo excusa de dejar que su empresa se quede atrapada con costosos fuera de soluciones de fecha Debe estar al frente de sí mismo con un plan de transición que le permitirá a la empresa aprovechar y lograr algunos de los ahorros que la revolución de la ingeniería de software moderna en las operaciones está poniendo a disposición. Tenga en cuenta que esto no significa abandonar Windows. Las técnicas modernas de nube/devops/operaciones/lo que sea se aplican a Windows tanto como a Linux. Pero él tiene que liderar el esfuerzo de mover su empresa, a través de su departamento existente, hacia esos ahorros y mejoras.
Dios, tal vez podrían trabajar juntos para lograr estos objetivos. Ganar-ganar-ganar (para John, Chan y su empresa).
O despídelos a ambos y encuentra dos nuevos FE para que formen parte de tu grupo de 5. Porque quien "gane" esta ronda, la compañía pierde porque la pelea está ocurriendo.
(Por cierto, antes de seguir este consejo: tenga en cuenta que, aunque he estado en la industria durante más de 40 años, nunca he manejado un presupuesto mayor que mi cuenta corriente personal. Veamos qué tienen que decir los demás...)
Diría que esto no se trata de disciplinar a alguien y definitivamente no es una decisión de un gerente de nivel medio, especialmente, si no es responsable de administrar ingenieros senior de manera normal.
Su empresa necesita sopesar los pros y los contras de cambiar a nuevas tecnologías. Tiene al menos un ingeniero que promueve nuevas tecnologías y que posiblemente ha demostrado potencial para una gran mejora en la reducción de la necesidad de trabajo humano para hacer lo que se está haciendo actualmente .
Decisiones como estas generalmente se toman a nivel de CTO. Deberían, como indican otras respuestas, tener en cuenta la empleabilidad del personal calificado existente, que podría necesitar dominar estas u otras nuevas tecnologías, así como muchas otras cosas.
Como nota al margen, si bien estoy totalmente a favor de mantener una actitud positiva y tener en cuenta tanto el potencial como la experiencia de los empleados existentes, esta cita: "Es fácil para usted decir: no todos tienen juventud y tiempo para volver a capacitar sus conjuntos de habilidades básicas". . En lugar de intentar crear más formas para que podamos resolver el mismo problema, ¿por qué no te sumas a nuestros principales productos y contribuyes a ellos en lugar de proponer alternativas escritas desde cero?"
va más allá de pálido. Esto no es solo "proteger mi futuro aquí, porque he trabajado duro aquí antes", sino "proteger mi futuro aquí, incluso si ambos sabemos que sería mucho mejor [ 200 programadores son muchos] que no lo hicieras".
Alguien debe ver esto no solo desde el punto de vista de los egos heridos y la antigüedad, sino desde el punto de vista de lo que es mejor para la empresa . Claro, si a la compañía le está yendo bien, puede darse el lujo de continuar con el estado actual de las cosas y simplemente despedir a John, por traer las noticias desagradables.
Sin embargo, le pediría que considere lo que sucederá si simplemente despide a John (en lugar de resolver este problema a nivel de empresa). En su lugar, sabiendo muy bien la cantidad de optimización posible en un solo lugar diminuto de la empresa, establecería mi propio negocio o me uniría a una empresa rival, que entiende que 200 desarrolladores de Windows son un gran recurso, mucho mejor empleado para nuevos proyectos y fuentes de ingresos en lugar de mantener algo que se puede mantener mediante una serie de scripts automatizados.
Parece que su empresa tiene un problema de actitud, que Chan expresó muy claramente:
Es fácil decirlo: no todos tienen la juventud y el tiempo para volver a entrenar sus conjuntos de habilidades básicas.
Esta es una excusa para justificar apegarse a las viejas rutinas, en lugar de esforzarse por desarrollar más allá de las habilidades actuales. Las empresas tienen presupuestos de capacitación para que sus empleados puedan dedicar tiempo a actualizar su conjunto de habilidades para lo que se requiere.
Confiar en métodos antiguos puede ser más barato y seguro a corto plazo, pero tiene como contrapartida la pérdida de eficiencia y competitividad. En una empresa de ingeniería, aprender nuevas habilidades y mantenerse al día con los estándares tecnológicos suele ser parte de las responsabilidades de un desarrollador. De lo contrario, ellos (y la empresa) corren el riesgo de volverse obsoletos, mientras que el resto de la industria avanza hacia soluciones más avanzadas.
Como su gerente, efectivamente tiene 3 opciones:
Ponte del lado de Juan. Dejando a un lado el ego, parece un ingeniero inteligente, leal y honesto cuyas sugerencias podrían mejorar la eficiencia de la empresa. Al crear una demostración con sus propios recursos y tiempo, no ha hecho daño a la empresa. Con el aporte de John, usted y sus superiores pueden planificar cómo migrar del soporte heredado a la tecnología actualizada. Reserve presupuestos de capacitación para que los empleados senior puedan investigar y aprender los nuevos conjuntos de habilidades.
Del lado de Chan et al. Probar ideas innovadoras y volver a capacitar a los empleados puede resultar costoso, y tal vez la empresa no pueda permitirse implementar las soluciones de John. Además, es posible que su empresa no sea una buena opción, porque una cultura que favorece la antigüedad puede no proporcionar a John (o empleados similares) espacio para crecer. Si los ingenieros superiores siguen obstruyendo a John, es posible que eventualmente decida llevar sus habilidades a otra parte, a un competidor que aprecie más su aporte.
Haz que cooperen. Esta es quizás la opción más difícil, debido a posibles conflictos de personalidad entre John y Chan. Como su gerente, debe vigilar de cerca para asegurarse de que estén cooperando de manera efectiva. Pídales que coordinen los planes para migrar la tecnología de la empresa y capacitar a los ingenieros, mientras mantienen el soporte para los productos heredados. De esta manera, la empresa puede utilizar mejores enfoques, sin revisar por completo ni abandonar el flujo de trabajo actual.
No puede ignorar las mejoras potenciales (y los consiguientes ahorros de costos) de las sugerencias de John. John también está motivado y dispuesto a dejar que la empresa se beneficie del trabajo que ha realizado en su tiempo libre. Incluso cuando no quiere entregar incondicionalmente los resultados de su trabajo (¿quién lo haría?), tampoco lo vería como una señal de falta de lealtad.
Sin embargo, tampoco deberías ignorar las preocupaciones de Chan. Tecnológicamente, el caso parece estar bastante claro, pero no es prudente ignorar aquí el factor humano. Tanto la comunicación de John como la de Chan en este número puede mejorarse. Pero especialmente el comportamiento de Chan tiene una razón. Estamos hablando de más de 200 personas (¡eso es el 10% de toda su fuerza laboral!) aquí que ven estos cambios como una amenaza para su sustento. Muchos tienen familias que alimentar e hipotecas que pagar y cuando se enfrentan a un cambio, la reacción a la que se enfrentan no debería sorprenderles. Un simple "Pueden hacer otra cosa" no les ayudará.
Hay expertos para hacer frente a estas situaciones (gestores de cambio, psicólogos organizacionales, etc.), por lo que es natural que no sepas cómo afrontarlo. Un cambio de esta magnitud justificaría la contratación de algunos expertos externos que puedan ayudarlo con este problema. Eso le costará solo una fracción de los ahorros que puede esperar. Y definitivamente le costará menos que el impacto en la productividad de una fuerza laboral que teme por su sustento.
Parece que tienes dos soluciones.
Aproveche la oportunidad para modernizar sus soluciones según la propuesta de John, gane mucho dinero, vuelva a capacitar a los ingenieros que trabajan con tecnologías heredadas y despida a aquellos que no estén dispuestos a actualizar sus habilidades.
Despida a John porque no encaja en la cultura de su empresa. Venda su producto heredado mientras pueda. Pague los salarios de los ingenieros heredados mientras pueda pagarlos. Espere hasta que una empresa más moderna se haga cargo de todos sus clientes (tal vez la empresa a la que se unió John). Cerrar la empresa. Espero que la mayoría de los más de 200 desarrolladores heredados hayan encontrado otros trabajos o estén listos para jubilarse en ese momento.
No puedo decirte qué elegir.
Según tengo entendido, creo que necesita más información. Mencionaste "reuniones" y "una demostración", pero al final lo que más importa son los planes de John y Chan para el futuro: futuro personal y de la empresa:
El enfoque de la empresa sobre el software cambiará con seguridad (no hoy, no con John o Chan, pero el mercado forzará este cambio), pero digamos que elegir el "lado" equivocado aquí es un gran riesgo.
Si un proyecto de pasatiempo en el tiempo libre puede ahorrar millones, despediré a John en riesgo medio, porque puede contratar a un consultor para que le brinde información sobre la mejora potencial en el desarrollo de software o utilizar su enorme fuerza laboral (¡200 empleados! Seguro que hay otro con habilidades comparables a las de John, ¿verdad?) y recursos para mejorar sus procesos. El mejor consejo para mí aquí es crear un equipo de al menos tres personas (1 desarrollador, 1 gerente de producto, 1 atención al cliente) y analizar todos sus procesos internos para descubrir dónde puede mejorar. ¡Empieza ahora mismo!
Por otro lado, existe un gran riesgo de estar detrás del mercado, por lo que la posición de Chan es comprensible, pero no es algo que él o la empresa puedan hacer para siempre. El gerente de la empresa debe comprender esto tan pronto como sea posible y crear un plan de respaldo para el futuro de la empresa.
En conclusión, mi elección aquí es:
Caramba, John es arrogante. Tiene razón, pero la forma en que se expresa y antagoniza a sus colegas sugiere que necesita algo de capacitación en sus habilidades personales antes de que se le considere un buen candidato para un ascenso.
En la mayoría de los contratos de ingeniería (de software) en el Reino Unido, hay alguna letra pequeña sobre la propiedad intelectual que sugiere que todos los proyectos en los que trabaja, incluso los que realiza en su tiempo libre, son propiedad de la empresa. Juan debería pensar en esto.
engineering contracts in the UK, there is some small print about intellectual property (...) you work on (...) in your spare time, are owned by the company. - a menos que esté desesperado por dinero, o el salario sea realmente bueno, no hay forma de firmar esoCowboy John está seguro de hacer grandes afirmaciones. Pareces estar de su lado, y creo que por eso Chan está molesto.
¿Está teniendo en cuenta que sus miembros más antiguos son los que más saben sobre cómo funciona su empresa, saben mejor dónde van las cosas lentas, pero también cómo lograr resultados?
Esto es lo que la experiencia da a todos.
Los empujaría.
Si ha venido alguien nuevo y ha presentado esta idea, eso significa que sus equipos experimentados pueden duplicar y mejorar esta idea.
Con este proyecto también puede significar que sus miembros experimentados también tendrán la oportunidad de aprender cosas nuevas.
La clave es: ¿ Qué es beneficioso para su organización?
¿Que implementa 1 idea de vaqueros para una victoria rápida?
¿O mejorará la organización como un todo, para lograr muchas victorias en el futuro?
Neo
esquizoide04
Nube