El ingeniero sénior que se marcha se niega a presentar un reemplazo a la comunidad/compañeros de código abierto

Teníamos un ingeniero senior, muy capaz (es decir, 5x), "Gust", que ha entregado su aviso (4 semanas) y se irá. A nuestra empresa le gusta "probar" a las personas en sus nuevos roles cuando son promovidas hasta 6 meses antes de que las promovamos oficialmente. Debido a la incompetencia del exgerente de Gust, Gust estuvo básicamente trabajando 2 niveles por encima de su nivel salarial durante 18 meses y capacitando a nuevos ingenieros en niveles más altos de los que le pagan (es decir, Gust es un "ingeniero senior I" y ha estado capacitando a nuevos " puestos de ingeniero superior II/III" durante más de un año).

Disciplinamos severamente al gerente que permitió que esto se prolongue durante 18 meses en lugar de solo 6. El verdadero error (no mío) es que estaba capacitando a personas mucho más importantes que él.

Estoy trabajando con recursos limitados para corregir el desorden que alguien más creó. Traté de aliviar esto con un ascenso a "Ingeniero sénior II" y una bonificación para compensar el "pago perdido" durante los últimos 12 meses (el período de prueba nunca debe exceder los 6 meses), pero Gust quería 2-3 promociones directamente ( la alta gerencia declinó debido a la "óptica") y una bonificación aún mayor, es decir, "si estoy capacitando a personas 2 niveles por encima de mí, se me debe pagar al menos 3 niveles por encima de mi nivel salarial actual".

La autoevaluación de Gust parece justa, ya que ha estado entrenando a personas en niveles más altos. Sin embargo, el nivel al que necesita crecer requiere habilidades blandas adicionales que aún no posee. Sin embargo, dado que puede capacitar a otros en funciones técnicas mucho más importantes, está convencido de que ya posee todas las habilidades técnicas + blandas necesarias.

Gust esperó hasta que se liquidaran las bonificaciones anuales y los pagos de acciones, y entregó su aviso.

Mi problema es que, si bien Gust proporciona documentación y materiales de capacitación para sus eventuales reemplazos (tuvo que contratar a 3 ingenieros intermedios en su lugar), gran parte de su trabajo depende de los cambios en las tecnologías de código abierto (numerosos proyectos de código abierto en GitHub). A pesar de que podemos capacitar gradualmente a sus reemplazos en estos proyectos (después de todo, es solo código), una gran parte de tener éxito con estos proyectos implica tener a alguien con la relación necesaria con los mantenedores/colaboradores de estos proyectos. Los proyectos de código abierto tienen entre 5 y 10 mantenedores que hacen la mayor parte del trabajo, y Gust es el mantenedor de cada proyecto.

No sé qué hizo/dijo Gust, pero la mayoría de los desarrolladores de estos proyectos (al menos aquellos a quienes contactamos por correo electrónico) básicamente nos reprendieron y trataron a los ingenieros intermedios con desprecio (y en algunos casos, lenguaje muy soez). ¿Cómo nos relacionamos mejor con estos equipos de código abierto y "pasamos la antorcha" de Gust a nuestros ingenieros intermedios, para que podamos continuar obteniendo las funciones que necesitamos en estos proyectos?Directamente le pedimos ayuda a Gust con esto, y él nos dijo rotundamente: "Váyanse a la mierda; presentarles a mis amigos para mis pasatiempos fuera del horario laboral no está en mi descripción de trabajo". No veo nada publicado en las listas de correo o en las páginas de GitHub que indique que Gust está alentando a estos equipos a que nos maltraten, pero dudo que esas personas sean tan groseras con los recién llegados que participan en el proyecto a menos que se les indique que actúen de esta manera con nosotros. .

Requerimos funciones que solo pueden implementar personas con experiencia (es decir, los mantenedores). No podemos bifurcar el proyecto por razones legales que no puedo abordar aquí. Este mandato vino de nuestro equipo legal. Lo que dicen son básicamente órdenes de marcha para nosotros (es decir, cualquier cosa que GPL se trate con desprecio; Apache/BSD es un "quizás" si tenemos suerte).

Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .
Es lamentable que los comentarios se hayan movido. Parece que los comentarios proporcionaron una aclaración. Consulte los comentarios en las respuestas, por ejemplo, "el OP aclaró en los comentarios (ahora movido al chat) que "Requerimos características que solo pueden implementar personas con experiencia (es decir, los mantenedores)". Workplace.stackexchange.com/questions/166317/ …
@SybillePeters He editado en los comentarios del OP donde creo que tienen sentido. Agregar información adicional del OP es una razón de edición válida para sugerir una edición si desea hacerla usted mismo (aunque su resumen de edición debe explicar de dónde proviene la información para que quien revise su sugerencia no se confunda en cuanto a dónde vino el texto) de).
@BSMP Gracias. Te lo agradezco. Genial que "el lugar de trabajo" mantenga las cosas limpias.
¿Cómo llegaste al punto en que dependes de algo que "Gust" hace en su tiempo libre? ¿Por qué nadie hizo este trabajo esencial como parte de la descripción de su trabajo?
Parece que la empresa confiaba en las conexiones de Gust con ciertas comunidades de software GPL de código abierto para mantener y/o introducir características importantes para la empresa en las bases de código de los proyectos de código abierto y, por lo tanto, "aliviar" o ayudar a solucionar las obligaciones de la empresa. de lo contrario bajo la GPL. Pero ahora que Gust se ha ido con el viento (juego de palabras intencionado), tal vez una mejor tarea para dichos ingenieros intermedios sea eliminar dicha dependencia del software GPL, ya sea encontrando alternativas adecuadas que no sean GPL o escribiendo algo nuevo/propietario desde cero. .

Respuestas (10)

Estoy un poco sorprendido de que te sorprenda esto.

Gust tiene relaciones laborales personales con personas que mantienen ese software de código abierto. ¿No crees que Gust se ha desahogado sobre el manejo de su trabajo y deberes por parte de su empresa? ¿No crees que cada uno de esos colaboradores ha escuchado las quejas de Gust sobre cómo admitiste que pagaste mal y lo desnivelaste? ¿Que te negaste a ascenderlo al trabajo que ya estaba haciendo ? ¿Que se necesitaron 3 contrataciones para hacer el trabajo que una persona mal pagada había estado haciendo antes?

No, han oído todas sus quejas sobre ti. Se han empatizado con ellos, y ahora están molestos contigo. Y Gust tiene toda la razón: definitivamente no es su responsabilidad ayudarte con esas conexiones de ninguna manera.

Para ser honesto, no estás simplemente en el punto de partida. Un extraño estaría en una mejor posición que tú. En cambio, es probable que tenga una antipatía activa hacia usted y su empresa.

Entonces, su mejor camino hacia adelante sería algo como esto:

Hola,

Escucha, sé que lo que pasó con Gust apestó, pero solo soy uno de los tipos que contrataron para tratar de llenar sus zapatos. Sé que probablemente esté molesto con nuestra compañía, y puedo entender eso (no estaba feliz cuando me enteré de lo que pasó).

Tengo un problema con X. No sé si podría echarle un vistazo. Sé que trabajó mucho en esos módulos a lo largo de los años. Si no puedes, definitivamente lo entiendo, solo házmelo saber de cualquier manera.

  • Tim

También conocido como, en otras palabras, uno de esos 3 técnicos tratando de dar un poco de separación entre ellos y el manejo de Gust por parte de su empresa. Tal vez el actor de la tercera parte tenga un poco de lástima/simpatía por ellos ( no son los que jodieron a Gust).

Recuerde que las personas que hacen proyectos de código abierto lo hacen por diversión (o por alguna otra razón) de forma gratuita. Cuando aparece alguien a quien se le paga por hacer cosas y sugiere implementar algo que el proyecto de código abierto no necesita, pero que ayudará a una empresa X a generar dinero (y a alguien a demostrar liderazgo/habilidades blandas), esto no es necesariamente miró con una actitud positiva. Especialmente cuando esas personas saben que su empresa acaba de arruinar gravemente a uno de sus mantenedores.
Cualesquiera que sean los aciertos y errores de la situación, cualquier evaluación de la misma por parte del OP a los mantenedores de código abierto debe redactarse con mucho cuidado, ya que la empresa puede tener una opinión diferente y tendrá un motivo justificado para una queja/acción disciplinaria en caso de crítica escrita por uno de sus empleados de sus acciones wrt otro a un tercero.
Esta es una buena respuesta, pero creo que a la carta de muestra le vendría bien un lenguaje más cortés. (Puede ser regional, pero si recibo un correo electrónico con imperativos ("Escucha", "Solo házmelo saber") y sin "por favor" o "gracias", entonces personalmente estaría menos inclinado a responder de manera útil)
@SalvadorDali Eso no es necesariamente cierto. La mayoría de los grandes proyectos son ejecutados profesionalmente por desarrolladores dedicados, ya sea empleados directamente por fundaciones o por empresas que ofrecen voluntariamente el tiempo de sus empleados.
Agregaría que muchas personas en la comunidad de código abierto leen StackExchange y probablemente reconocerán esta historia, lo que podría o no resultar en simpatía por los ingenieros recién contratados. Y no me sorprendería si mucha gente en los inversores institucionales minan StackExchange en busca de historias como esta, y es justo suponer que esto resultará en muy poca simpatía por los gerentes/ejecutivos/juntas que han cometido un error tan grave.
Por supuesto, Gust se lo hizo saber a los mantenedores del proyecto. Gust necesitaba un nuevo trabajo, ¿y quién mejor para pedírselo que sus compañeros de mantenimiento? Trabajan con la misma tecnología, probablemente conozcan los puestos vacantes y pueden garantizar la experiencia de Gust.
Sorprendentemente, los desarrolladores no son como esos cónyuges golpeados que regresan con su supuesto esposo, especialmente porque tienen muchas otras oportunidades para ser tratados mucho mejor.
Me sorprende que estés sorprendido, @Kevin. Muchos gerentes son psicópatas que se contentan con maltratar a otros hasta que se rompen; solo se molestan cuando las consecuencias de romper a un empleado tienen repercusiones para ese gerente (es decir, el hecho de que alguien se rompa es irrelevante para ellos). Esta pregunta se lee como si la hubiera escrito un gerente de este tipo.
@DiegoSánchez y en este caso, esos desarrolladores tienen sus propios errores y prioridades, que les impone la organización que realmente les paga. No les importaría menos la 'nueva característica' que se necesita de alguna otra compañía.
@AaronF, si alguien te insulta, no debes ser demasiado formal o demasiado educado cuando respondes. Responder demasiado cortésmente solo indica que todavía tienes a tu jefe mirándote por encima del hombro o que alguien de recursos humanos/relaciones públicas te está ayudando a elaborar tu respuesta, esa no es la impresión que quieres dar (incluso si es verdad). Dicho esto, estoy de acuerdo en que podría haber diferencias regionales que desconozco.
Creo que esta respuesta podría beneficiarse de una mención de que no importa en este momento quién participa en el proyecto de código abierto ahora. Cualquier persona de esta empresa que lo haga llevará la máscara "E-Corp". Podrían ser la persona más agradable con algunos de los mejores códigos que existen, y a nadie le importará porque representan a esta empresa.
@AlanDev Preste atención a lo que está editando y al contexto de la publicación. Gust no fue despedido. El que respondió decía que la situación era desafortunada.

Si necesita funciones, debe financiarlas

Si necesita incluir características particulares en "estos proyectos", deberá desarrollarlas usted mismo o contratar a alguien externo para que lo haga. En lugar de "construir una relación" con los mantenedores, debe asignar el tiempo y el esfuerzo adecuados de sus "ingenieros intermedios" para que puedan contribuir directamente a ese proyecto. Parece que pueden estar teniendo una mala reacción porque llegan a ese proyecto y comienzan a pedir cosas, eso no es apropiado, ¿qué le han dado a ese proyecto? ¿Han contribuido con mucho código de alta calidad que ayude a los objetivos de los mantenedores? Esoes lo que se requiere para ganarse el respeto, no un "traspaso de conexiones". Si no son capaces de hacer eso porque se requiere cierta experiencia única (es más probable que solo haya una curva de aprendizaje, que puede resolverse asignando suficiente tiempo para sus ingenieros), entonces puede acercarse a los mantenedores particulares ("Gust" mismo podría ser una opción, pero probablemente no querrá hacerlo) e intente contratarlos como contratistas para trabajar en sus características.

Parece que antes tuviste mucha suerte al poder realizar tus funciones de forma gratuita, principalmente como un beneficio secundario accidental de las habilidades blandas de alguien cuya carrera estaba limitada por una "falta de habilidades blandas". Esa situación es rara y no se debe esperar que continúe en el futuro, tal vez recupere esa habilidad en algún momento, pero no a corto plazo. Tuvo una buena racha allí, pero ahora se acabó, ha vuelto a la normalidad, y esto requerirá que financie el desarrollo de estas características; ya sea con dinero o con el tiempo de los ingenieros en tu nómina.

Estoy de acuerdo con esto, la empresa necesita una estrategia de código abierto que implique contribuciones regulares a los proyectos en los que se basan. Aquí, la raíz del problema parece ser el departamento legal que todavía cree en el FUD "GPL = cáncer".
@amon: Apuesto a que el verdadero problema es que el departamento legal fue contratado por el mismo departamento de recursos humanos que también fue responsable de los problemas con Gust. Ese problema suele ser peor, porque Recursos Humanos necesita lidiar con la legislación laboral y, por lo tanto, es aún más probable que asuma que ellos mismos pueden juzgar el nivel de habilidad de los candidatos. Pero la ley de PI es bastante diferente de la ley laboral.
No me queda claro desde el OP si están pidiendo a los mantenedores de OSS que creen las funciones. Incluso si implementa y prueba las funciones usted mismo, podría encontrarse fácilmente con los mismos problemas cuando los mantenedores no quieran aceptar sus cambios.
@Paul the OP aclaró en los comentarios (ahora movido al chat) que "Requerimos funciones que solo pueden implementar personas con experiencia (es decir, los mantenedores)".

Tienes varios problemas:

Has jodido a Gust. Con razón está enojado contigo. Es irrelevante para él qué tan severamente fue o no "disciplinado" el gerente que lo bajó de nivel, y para ser honesto, si yo estuviera en su lugar, sería un insulto para mí si siquiera mencionaras ese tema, como si pensaras que debería hacerlo. me importa.

De hecho, no creo que siquiera entiendas lo mal que jodiste a Gust. Es en parte por el dinero, sí, pero también por muchas otras cosas. Digamos, por ejemplo, que Gust, como Ingeniero I, estaba capacitando a un Ingeniero II que era un nuevo empleado. Esto le muestra a Gust que su gerente cree que debería ser un Ingeniero III. Sin embargo, en lugar de ascenderlo, incluso a Ingeniero II, la empresa preferiría contratar a alguien externo, lo que requiere mucho más tiempo y esfuerzo. Su compañía literalmente hizo todo lo posible para que Gust se sintiera incómodo; eso es un comportamiento agresivo y degradante, por decir lo menos, y me sorprende que Gust no te haya dicho que saltes a un lago la primera vez que le pediste que entrenara a alguien por encima de su nivel. Además de eso, el título del trabajo de Gust era Ingeniero I, a pesar de que estaba haciendo el trabajo de un Ingeniero III (o incluso IV). Ahora, si Gust va y aplica a otra empresa, pondrá "Ingeniero I" en su currículum, porque ese era su título; si pone algo más y se comprueba, se descubrirá que ha estado mintiendo. Eso significa que solo solicitaría trabajos de Ingeniero I o Ingeniero II en otra empresa, una caída significativa en la responsabilidad y una caída significativa en el pago esperado (y merecido) de lo que debería estar recibiendo en su nivel. Básicamente, le has robado 18 meses de la vida de Gust en términos de progresión de su carrera. Tiene razón en estar enojado contigo, realmente muy enojado. No sé a qué se refería en los comentarios cuando dijo que el gerente responsable ha sido severamente castigado, pero como mínimo absoluto debería ser despedido en el acto, con causa, sin indemnización por despido. su bonificación y opciones de compra de acciones fueron revocadas en la mayor medida posible durante el período de esos 18 meses, y probablemente recibió notificación legal por cualquier cosa por la que pueda demandarlo solo por si acaso. Así de mal jodió a Gust. De hecho, es posible que desee investigar los problemas legales que podría presentar contra ese gerente; Gust probablemente tenga un caso legal razonablemente sólido en su contra por despido constructivo si su localidad tiene tales leyes, y probablemente podría demandar a su compañía por un montón de dinero si se da cuenta de esto.

Ahora, el segundo problema es qué hacer para reemplazar a Gust. Tenías un Ingeniero Superior IV. Lo reemplazaste con 3 ingenieros intermedios. Eso no funciona. No se trata de qué tan rápido las manos de Gust pueden moverse por el teclado; no se puede simplemente reemplazar a Jeff Bezos con una población de simios del tamaño de la selva amazónica y esperar que no destruyan a Amazon. Cuando perdiste a Gust, perdiste su conocimiento , y ese es el problema principal. Las personas que contrataste simplemente no son tan buenas como Gust, y llevará añospara que se acerquen. El hecho de que incluso pensara que esto estaba cerca de lo razonable muestra una falta de comprensión de las técnicas de ingeniería por parte de usted y/o de la gerencia de su empresa. Si esta es la forma en que opera su gerencia, no es de extrañar que hayan tratado a Gust tan horriblemente, porque simplemente no respetan lo que significa ser un ingeniero. Así que tienes que ir y arreglar eso.

El tercer problema es con respecto a este repositorio de código abierto. Esto es lo que pasa con los repositorios de código abierto: o los posees o no. Algunas empresas son propietarias o patrocinadoras de proyectos de código abierto, por lo que cuando necesitan implementar una característica, tienen peso para lanzar. Su empresa, al parecer, no lo hace; estabas usando este repositorio de código abierto para hacerte la vida más fácil. Sin embargo, no es su repositorio. Los mantenedores del repositorio son libres de tratar las solicitudes y contribuciones de su equipo como deseen, priorizar sus tickets, fusionar sus relaciones públicas, etc., como mejor les parezca. Y parece que no. No están en deuda contigo, de hecho es al revés. Básicamente, tiene 3 opciones: puede bifurcar el repositorio y mantener su propia copia, puede reconstruir la aplicación desde cero, o puede encontrar otro repositorio con una funcionalidad similar para usar cuyos mantenedores puedan ser más amigables. Me resulta difícil creer (como dijiste en un comentario) que puedes usar un repositorio pero no bifurcarlo, por lo que es posible que desees verificarlo nuevamente. En el peor de los casos, tendrá que usar el repositorio para cualquier funcionalidad que proporcionen los mantenedores y, mientras tanto, tendrá que crear su propio proyecto para migrar su aplicación lejos de ese repositorio para que no tenga que lidiar con esos mantenedores Para responder a su pregunta principal (la que está en negrita): no "pasa la antorcha". Tu puente está quemado. Busque en otra parte. Añádelo al costo de perder a Gust. Quizás no deberías haberlo tratado como una mierda, entonces quizás no tendrías que incurrir en este costo. ¿Valió la pena? Me resulta difícil creer (como dijiste en un comentario) que puedes usar un repositorio pero no bifurcarlo, por lo que es posible que desees verificarlo nuevamente. En el peor de los casos, tendrá que usar el repositorio para cualquier funcionalidad que proporcionen los mantenedores y, mientras tanto, tendrá que crear su propio proyecto para migrar su aplicación lejos de ese repositorio para que no tenga que lidiar con esos mantenedores Para responder a su pregunta principal (la que está en negrita): no "pasa la antorcha". Tu puente está quemado. Busque en otra parte. Añádelo al costo de perder a Gust. Quizás no deberías haberlo tratado como una mierda, entonces quizás no tendrías que incurrir en este costo. ¿Valió la pena? Me resulta difícil creer (como dijiste en un comentario) que puedes usar un repositorio pero no bifurcarlo, por lo que es posible que desees verificarlo nuevamente. En el peor de los casos, tendrá que usar el repositorio para cualquier funcionalidad que proporcionen los mantenedores y, mientras tanto, tendrá que crear su propio proyecto para migrar su aplicación lejos de ese repositorio para que no tenga que lidiar con esos mantenedores Para responder a su pregunta principal (la que está en negrita): no "pasa la antorcha". Tu puente está quemado. Busque en otra parte. Añádelo al costo de perder a Gust. Quizás no deberías haberlo tratado como una mierda, entonces quizás no tendrías que incurrir en este costo. ¿Valió la pena? Tendrá que usar el repositorio para cualquier funcionalidad que proporcionen los mantenedores y, mientras tanto, tendrá que crear su propio proyecto para migrar su aplicación lejos de ese repositorio para que no tenga que lidiar con esos mantenedores. Para responder a su pregunta principal (la que está en negrita): no "pasa la antorcha". Tu puente está quemado. Busque en otra parte. Añádelo al costo de perder a Gust. Quizás no deberías haberlo tratado como una mierda, entonces quizás no tendrías que incurrir en este costo. ¿Valió la pena? Tendrá que usar el repositorio para cualquier funcionalidad que proporcionen los mantenedores y, mientras tanto, tendrá que crear su propio proyecto para migrar su aplicación lejos de ese repositorio para que no tenga que lidiar con esos mantenedores. Para responder a su pregunta principal (la que está en negrita): no "pasa la antorcha". Tu puente está quemado. Busque en otra parte. Añádelo al costo de perder a Gust. Quizás no deberías haberlo tratado como una mierda, entonces quizás no tendrías que incurrir en este costo. ¿Valió la pena? Añádelo al costo de perder a Gust. Quizás no deberías haberlo tratado como una mierda, entonces quizás no tendrías que incurrir en este costo. ¿Valió la pena? Añádelo al costo de perder a Gust. Quizás no deberías haberlo tratado como una mierda, entonces quizás no tendrías que incurrir en este costo. ¿Valió la pena?

En cuanto a la respuesta de Gust cuando le pediste ayuda: yo habría hecho exactamente lo mismo. De hecho, creo que te salió fácil: solo usó una palabrota en su respuesta a ti; Habría usado muchos, muchos más. Te lo merecías. Si desea volver a asociarse con Gust, su próximo mensaje debería ser: "Nos gustaría ofrecerle su antiguo trabajo, con el título de Ingeniero senior V (sí, 5, eso es un nivel por encima de lo que él hubiera tenía derecho), con un salario de <2x el salario normal para alguien de ese nivel>, con una promesa por escrito y contractualmente vinculante de ascenderlo a Ingeniero Senior VI dentro de 1 año, con un aumento de salario apropiado, como un gesto de buena voluntad voluntad, sin ataduras". Básicamente, tienes que hacerle una oferta que no pueda rechazar. Si no está preparado para hacer eso, no

Así que eso es básicamente todo. Estás jodido. Buena suerte.

Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .

¿Cómo nos relacionamos mejor con estos equipos de código abierto y "pasamos la antorcha" de Gust a nuestros ingenieros intermedios, para que podamos continuar obteniendo las funciones que necesitamos en estos proyectos? Directamente le pedimos ayuda a Gust con esto, y él nos dijo rotundamente: "Váyanse a la mierda; presentarles a mis amigos para mis pasatiempos fuera del horario laboral no está en la descripción de mi trabajo".

A pesar de lo colorido que puede ser el lenguaje de Gust, tiene 100% de razón, ya que su empresa no tiene derecho a los contactos sin trabajo de Gust, ni usted ni Gust ni nadie puede obligar a algunos voluntarios de código abierto a contribuir en nada. Esa es la desventaja de depender de la mano de obra gratuita, nadie tiene obligación alguna de seguir contribuyendo.

una gran parte del éxito con estos proyectos implica tener a alguien con la relación necesaria con los mantenedores/contribuyentes de estos proyectos.

Luego, debe comenzar a construir esa relación con los nuevos empleados. Esto requerirá tacto, cuidado y comprensión de que está trabajando con personas que son puramente voluntarios y no tienen nada que los vincule legalmente con el proyecto. Lo que todo eso significa es que su empresa de ninguna manera tiene derecho a su tiempo, y tratar de actuar como tal solo conducirá a alienarlos a la velocidad del rayo.

Ahora bien, ya sea que les haya dicho lo mala que cree que es su empresa, o si obtuvieron una pizca de derecho de los 3 interinos realmente no importa porque ahora depende de ustedes descubrir cómo seguir adelante. Puede hacerlo contratando personas para mantener el proyecto (ya sean voluntarios o contratando a más personas internamente), o tratando de reconstruir la relación con los voluntarios de ese proyecto.

Contratar personas es sencillo, no es necesario explicar más. Con respecto a obtener seguidores y construir una relación con la comunidad de proyectos de código abierto, en mi experiencia, la mejor manera de lograr que los voluntarios lo sigan es demostrar que sus objetivos están alineados y que está dispuesto a hacer el trabajo duro. trabajo que el proyecto necesita para tener éxito.

Pero al final...

Traté de aliviar esto con un ascenso a "ingeniero senior II" y una bonificación para compensar el "pago perdido" durante los últimos 12 meses (el período de prueba nunca debe exceder los 6 meses), pero Gust quería 2-3 promociones directamente ( justo, pero la alta gerencia declinó debido a la "óptica") y una bonificación aún mayor, es decir, "si estoy capacitando a personas 2 niveles por encima de mí, se me debe pagar al menos 3 niveles por encima de mi nivel salarial actual". Gust esperó hasta que se liquidaran las bonificaciones anuales y los pagos de acciones, y entregó su aviso.

Tal vez debería haber hecho una excepción con su estructura de promoción, parece que esta era la mejor manera de avanzar. Ahora es demasiado tarde y tienes que manejar las consecuencias.

Sí, "Gust" no solo estaba trabajando por debajo de su salario, sino que también tenía el valor oculto (léase: dado por sentado) de una buena relación con los contribuyentes de estos proyectos. Si lo hubieran promovido adecuadamente, él -todavía- habría estado agregando valor por encima de su posición.

Haciéndose eco de la última oración en la respuesta de Sascha:

Ofrecerle a Gust un contrato económicamente atractivo como consultor independiente podría ser el bálsamo que necesita. Saber que no es "propiedad" de la empresa, que sus perspectivas de carrera no dependen de los caprichos de la gerencia y que se gana mejor la vida como autónomo haciendo lo que estaba haciendo anteriormente podría ser suficiente para que vuelva a bordo. .

Cuando dejé el mundo del trabajo a tiempo completo para salir por mi cuenta, mi primer cliente fue mi ex-empleador. Atrás quedaron las irritaciones y frustraciones de ser un empleado. Ganaba más dinero, tenía más libertad para elegir las formas y los métodos de mi trabajo y estaba aislado de todas y cada una de las políticas internas y las debilidades de la gestión. Eso contribuyó en gran medida a hacerme más feliz... y mejor. De hecho, mi antiguo jefe y yo nos hicimos muy buenos amigos. No digo que eso suceda o deba suceder con Gust, pero apuesto a que el bagaje de la relación empleador/empleado anterior desaparecerá como si nunca hubiera existido.

Además de bifurcar el código y mantener las bifurcaciones específicas de la empresa (no es inusual, Debian, Red Hat y Android hacen esto en diferentes grados), esta es quizás la forma más realista y práctica que veo de avanzar.
Las personas son contratadas nuevamente como consultores todo el tiempo, ¡a veces incluso cuando la compañía no cometió un error al deshacerse de él/dejarlo ir/dejar que se enojara en primer lugar!

Esto es como Deja Vu de nuevo....

Tenemos un ingeniero senior, muy capaz (es decir, 5x), "Gust", que ha entregado su aviso (4 semanas) y se irá.

Entonces, tenía un trabajador muy leal y altamente competente que ahora se va... Ya veo a dónde va esto.

A nuestra empresa le gusta "probar" a las personas en sus nuevos roles cuando son promovidas hasta 6 meses antes de que las promovamos oficialmente.

Una mala práctica, y por qué, se hará evidente en breve.

Debido a la incompetencia del exgerente de Gust, Gust estuvo básicamente trabajando 2 niveles por encima de su nivel salarial durante 18 meses y capacitando a nuevos ingenieros en niveles más altos de los que le pagan (es decir, Gust es un "ingeniero senior I" y ha estado capacitando a nuevos " puestos de ingeniero superior II/III" durante más de un año).

Oh, esto no es incompetencia, es mala conducta. Si el tiempo típico es de 6 meses, parece que a Gust le prometieron que la luna se sentaría pacientemente. Esa es la única explicación razonable.

Traté de aliviar esto con un ascenso a "ingeniero senior II" y una bonificación para compensar el "pago perdido" durante los últimos 12 meses (el período de prueba nunca debe exceder los 6 meses), pero Gust quería 2-3 promociones directamente ( justo, pero la alta gerencia declinó debido a la "óptica") y una bonificación aún mayor, es decir, "si estoy capacitando a personas 2 niveles por encima de mí, se me debe pagar al menos 3 niveles por encima de mi nivel salarial actual". Gust esperó hasta que se liquidaran las bonificaciones anuales y los pagos de acciones, y entregó su aviso.

Sí, eso se llama agregar insulto a la herida. Clavar un cuchillo tres pulgadas en un hombre, luego sacarlo dos y decir "¿no es eso mejor?" no va a hacer feliz al hombre, razón por la cual pidió una compensación JUSTA.

Mi problema es que, si bien Gust proporciona documentación y materiales de capacitación para sus eventuales reemplazos (tuvo que contratar a 3 ingenieros intermedios en su lugar), gran parte de su trabajo depende de los cambios en las tecnologías de código abierto (numerosos proyectos de código abierto en GitHub).

Por lo tanto, usted no quería la "óptica" de pagarle al hombre lo que vale, pero está bien si contrata a tres personas, lo que le costará mucho más... Solo en el mundo corporativo esto hace algún tipo de de sentido

Tienes suerte de tratar con un hombre honorable, podría haberte follado tan fuerte que habrías andado raro durante una semana.

A pesar de que podemos capacitar gradualmente a sus reemplazos en estos proyectos (después de todo, es solo código), una gran parte de tener éxito con estos proyectos implica tener a alguien con la relación necesaria con los mantenedores/colaboradores de estos proyectos.

INSERTAR RASGUÑO DE REGISTRO

Ahora, veo la fuente del problema: es solo código, después de todo

¿Es solo código, después de todo?

Ese comentario por sí solo resume tu problema. No tiene idea de qué tipo de experiencia está tratando o qué se necesita para programar.

Cuando me contrataron originalmente en mi empleador actual, era como consultor. Terminé el proyecto antes de tiempo y todavía estaba presupuestado para un mes adicional, así que me pidieron que mirara un código. DESPUÉS DE TODO, ES SOLO CÓDIGO . El problema con este código, que es solo código, era que tardaba diez horas en ejecutarse. y paralizó la máquina que estaba ejecutando.

Arreglé el código y ahora se ejecuta en seis minutos. El mero hecho de que hagas tal declaración demuestra que no tienes idea de lo que contribuye alguien en la posición de Gust, pero te espera una educación que nunca olvidarás.

Si es solo código, después de todo, su equipo debería poder manejarlo sin problemas.

una gran parte del éxito con estos proyectos implica tener a alguien con la relación necesaria con los mantenedores/contribuyentes de estos proyectos.

El 90% de cada trabajo es tener buenas relaciones, has cometido un gran error al pensar que SUS relaciones son TUS relaciones.

No sé qué hizo/dijo Gust, pero la mayoría de los desarrolladores de estos proyectos (al menos aquellos a quienes contactamos por correo electrónico) básicamente nos reprendieron y trataron a los ingenieros intermedios con desprecio (y en algunos casos, lenguaje muy soez).

Bueno, dado que tus acciones hacia Gust fueron despreciables, todo lo que tenía que hacer era decir la verdad. ¿Qué tan sorprendido estás? Jodiste a Gust, y los joderás a ellos también. Parece que has hecho enojar a los cachorros y se están vengando de papá oso.

¿Cómo nos relacionamos mejor con estos equipos de código abierto y "pasamos la antorcha" de Gust a nuestros ingenieros intermedios, para que podamos continuar obteniendo las funciones que necesitamos en estos proyectos?

¿Cómo cruzas un puente después de haberlo quemado por completo?

Directamente le pedimos ayuda a Gust con esto, y él nos dijo rotundamente: "Váyanse a la mierda; presentarles a mis amigos para mis pasatiempos fuera del horario laboral no está en mi descripción de trabajo".

Y tiene razón. Sus amigos lo estaban ayudando a ÉL y son leales a ÉL, no a ti. ¿Ves lo que perdiste al no esforzarte más por él?

No veo nada publicado en las listas de correo o en las páginas de GitHub que indique que Gust está alentando a estos equipos a que nos maltraten, pero dudo que esas personas sean tan groseras con los recién llegados que participan en el proyecto a menos que se les indique que actúen de esta manera con nosotros. .

¿Es la primera vez que gestiona programadores? Ciertamente espero que sí porque pareces absolutamente inconsciente de la cultura. Si yo fuera parte del grupo de Gust y leyera esto, regresaría al grupo y les diría no solo que no lo ayuden, sino que deliberadamente le den respuestas incorrectas. Este es el por qué:

Dudo que esas personas sean tan groseras con los recién llegados que participan en el proyecto a menos que se les indique que actúen de esta manera con nosotros.

Acabas de lanzar una seria acusación contra Gust con este. Nuevamente, esto muestra CERO respeto por el hombre, y una asombrosa ignorancia de cuán buen hombre es y cómo operan los programadores. Este hombre probablemente podría cerrar su operación con una palabra, si así lo quisiera. Lo he visto pasar.

En cuanto a él dando órdenes para atacar a tu gente, obviamente no conoces la mentalidad del programador. No seguimos órdenes, pero tendemos a tener un sentido de la justicia demasiado desarrollado y estaríamos felices de meternos con cualquiera que veamos como un matón o que se está aprovechando de uno de nosotros. Para ser honesto, te pareces a ambos para mí.

Por cierto, Gust no me dijo que publicara esto, lo hice todo yo solo.

Si quieres ahorrarte un mundo de dolor, haz lo correcto por Gust. Dele una gran bonificación y contrátelo nuevamente como consultor a una tarifa MÁS ALTA que la que ganaría un ingeniero III, y luego, CORTESAMENTE, solicite su ayuda.

De lo contrario, será mejor que contrates a 10 personas más para prepararte para la avalancha que te va a golpear.

Finalmente, alguien que señaló la raíz del problema. El "es solo código". La compañía no solo no entendió el "valor" de Gust, sino que no entiende que no se puede reemplazar un desarrollador extremadamente bueno con 3 mediocres. Y no entienden cómo funciona el código abierto. Además de no entender cómo trabajan o piensan los desarrolladores. En absoluto. Sin embargo, acortaría un poco la respuesta. Hace que su(s) punto(s) sea(n) mejor(es), si es más breve.
Eso me disparó a mí también. Ese comentario de "Es solo código después de todo". Hablando como un idiota despistado.
@BoboDarph, esto combinado con la actitud de "más personas = más rápido, mejores resultados" es la ruina de mi existencia. El viejo dicho "no puedes contratar a 9 mujeres y esperar tener un bebé en un mes"

¿Cómo nos relacionamos mejor con estos equipos de código abierto y "pasamos la antorcha" de Gust a nuestros ingenieros intermedios, para que podamos continuar obteniendo las funciones que necesitamos en estos proyectos?

Guau. Desea beneficiarse de ese proyecto de código abierto, y ahora logró perder a su persona principal de interfaz (y probablemente la más capacitada) para estos proyectos.

No veo nada publicado en las listas de correo o en las páginas de GitHub que indique que Gust está alentando a estos equipos a que nos maltraten, pero dudo que esas personas sean tan groseras con los recién llegados que participan en el proyecto a menos que se les indique que actúen de esta manera con nosotros. .

Nah, imagino que hay otra explicación: imagino un diálogo como este:

"¿Leíste el correo electrónico del chico nuevo en la compañía X?" - "Sí, parece que aún no están demasiado metidos en código, no tenía sentido para mí" - "¿Dónde Gust?" - "Dejó la empresa" - "Eso no está bien, ¿nos pidieron que incluyéramos la función X? Todavía tenemos algunos problemas allí, y el chico nuevo parece no estar informado al respecto" - "¿No prometieron trabajar en esto?"

Entonces sí. Puedo imaginar que cuando "obtienes funciones en algún proyecto de código abierto" y lo dejas colgando (y sí, perder a la persona más importante es "déjalo colgar") de tu lado, surgen algunas emociones, independientemente de las consideraciones personales.

Mi sugerencia es: contrate a Gust como contratista/consultor súper bien pagado.

Contratarlo como un consultor bien pagado. ” Posiblemente la única idea útil y constructiva en toda esta página.
Es una idea completamente destructiva, a menos que Gust de repente tenga un cambio de personalidad que diga "Si me pagas 1 millón de dólares al año, puedes comprar mi alma". E incluso si acepta una tarifa de consultoría ridículamente alta, eso no significa que se la va a ganar . Si yo fuera Gust, simplemente tomaría su dinero y me reiría en su cara, y qué planearía hacer exactamente al respecto cuando eso suceda, y cuando él le cuente a sus amigos de código abierto cuán despistados usted (y su empresa) realmente son ?
Esta es la única sugerencia con >0.00001% de posibilidades de funcionar. Lo pondría en aproximadamente 0.00002% de probabilidad, pero bueno, eso es una mejora.
@alephzero en realidad, esta táctica funciona con frecuencia en esta situación, con el enfoque correcto y la persona adecuada negociando la oferta.
Obtener salarios de consultor pagados y no estar empleado como un W-2 no es comprar su alma. De hecho, puede ser muy satisfactorio de muchas maneras.

Considere ofrecer pagar a los contribuyentes de código abierto.

Claramente, Gust tenía una buena relación con ellos, pero tú no. Así que ahora cualquier solicitud de ayuda no proviene de un amigo que haya contribuido al proyecto en el pasado, sino de una empresa con fines de lucro que intenta ganar dinero con su pasatiempo.

Entonces, en lugar de pedirles que trabajen básicamente gratis mientras usted obtiene ganancias, ofrézcales algún trabajo por contrato. Ofrezca buenas tarifas, porque si no son buenas, simplemente verán que Gust tenía razón y no querrán trabajar para usted.

Legal no lo permitirá, ya que sienta un mal precedente (es decir, una pendiente resbaladiza; obtuvimos esto gratis antes). Pagar ahora solo fomenta la especulación.
@Henre Eso es absurdo. O su empresa necesita el proyecto, o no lo necesita. Explicar a legal las consecuencias de no tener este proyecto.
@Henre, no lo obtuviste gratis antes. El costo era lo que te costara tener a Gust a bordo. Esto es algo que no se tuvo en cuenta al hablar de su ascenso y ahora se hace evidente.
@Henre, lamento decir esto, pero su empresa merece morir entonces: su empresa hizo su cama, ahora puede acostarse en ella. Diviértete en la bancarrota.
Esto nuevamente huele a troll. ¿Por qué legal estaría interesado en no sentar un precedente? Eso no es un problema legal en primer lugar.
@Henre Y aquí pensé que nada que pudieras agregar a tu publicación original podría hacerte lucir peor. Felicidades, lograste superar las expectativas.

Todo se ha explicado en gran medida en respuestas anteriores. Excepto la resolución:

Ahora, usted tiene que hacer su trabajo. * Diríjase a su superior, explíquele lo importante que es Gust, compense todo el mal que le hizo su empresa, en todos los niveles (humano y profesional), discúlpese por todos los errores que cometió y páguele el doble. Es probablemente la mejor (y más barata) opción que tienes.

Haz lo mismo con el equipo Open Source. Disculpa honestamente cómo te comportas con su proyecto. Tomar gratis y no devolver. Aclara tu relación con ellos, y encuentra alguna forma en la que puedas contribuir con ellos. Pero, si mantienes a Gust, él puede hacer todo esto por ti, solo apoya su trabajo en el proyecto de código abierto.


* ) ahora es el momento en que todo el planeta pasa por una gran limpieza. En todos los niveles, desde personal hasta empresarial, estatal y global. Todo el viejo desorden se está limpiando y esta es una gran oportunidad para ti. Puedes limpiar tu desorden. Pero si su empresa no es lo suficientemente flexible y tiene excusas como "No puedo ascenderlo a tal o cual nivel" o "No puedo pagarle lo que se merece debido a nuestra regla AB y C", su empresa probablemente será limpiada como un todo ;-) Ahora es el momento de limpiar el desorden en las reglas de su empresa, prioridades, ... tirar todo lo que no funciona y buscar lo que tiene sentido. Concéntrese en lo que realmente tiene valor para la empresa y **valorelo!**
Probablemente sea demasiado tarde para esto. Observe la oración en la pregunta original: "Gust esperó hasta que se liquidaran los bonos anuales y los pagos de acciones, y entregó su notificación". En otras palabras, todo esto se vino abajo hace bastante tiempo, los PHB en cuestión tuvieron una gran oportunidad de arreglar lo que rompieron y evitaron esa oportunidad con mucho cuidado. Ese barco aparentemente ha zarpado.
@ JohnR.Strohm eso es cierto, pero nunca es demasiado tarde para intentar corregir los errores del pasado. No es nada fácil, pero para esta compañía, ahora que se da cuenta de cuánto valía Gust y cuán profundo es el problema cuando se va, sigue siendo, con mucho, la opción más fácil, barata y factible. Pero realmente deben disculparse honestamente y rectificar, realmente dar un giro de 180°.

Aparte de sus opciones realmente débiles para obligar a Gust a cooperar (discutido en otras respuestas), lo que quiere no parece realista.

Los proyectos de código abierto son meritocracias, o al menos así lo pretenden.

Ofrecerles colaboradores desconocidos con menor habilidad, menor experiencia y código de menor calidad como reemplazo de su amado Gust no es realmente un trato. Probablemente no sean "gruesos", solo intentan cumplir con algunos estándares de calidad.

Estas nuevas personas tienen que:

  1. construir su propia reputación profesional ante los ojos de los líderes de los proyectos. Pueden beneficiarse de alguna manera de la reputación de Gust solo después de asegurar sus propias posiciones como contribuyentes confiables.
  2. luchar (por medios desconocidos) contra la imagen de que son los reemplazos baratos de Gust en su lugar de trabajo no muy leal.

Tal vez sea posible, pero de ninguna manera tareas simples o rápidas y Gust no está en condiciones de ayudar a estas personas de una manera realista.

Así que se resume en:

Hacer que una persona profundamente irritada coopere no en una tarea simple, sino en algo que se describe mejor como "maravilla".

Cuéntanos si lo consigues. Cambiará un poco los límites de la "maravilla".

Me falta una respuesta aquí. Solo resume la pregunta.
Es una respuesta en el sentido matemático: demuestra que no hay solución. Quieren que Gust haga algo imposible. El hecho de que Gust esté enojado y supuestamente no coopere es secundario.