¿Cómo lidiar con el argumento de "no me pagan lo suficiente para hacer esta tarea"?

Bueno, la solución aquí es simple. Agradecer a Gruñón por su honestidad, ponerlo de nuevo en tareas regulares, y traer al siguiente tipo del banco.

Si alguien no está interesado en un proyecto como este y hay otras personas disponibles, entonces es del interés de todos poner a las personas en el proyecto que están más interesadas en él. Darle un aumento de sueldo a un gruñón no va a hacer que se entusiasme más con el proyecto, así que no es de tu interés ni del del del proyecto tenerlo allí de todos modos.

Más adelante tendrás que tomar algunas decisiones difíciles también. Yo vigilaría la actitud de este desarrollador y cómo afecta al equipo. Puede ser que tengas un cáncer que está empezando. Si realmente está disfrutando de su trabajo, esta es una de esas afirmaciones de las que se arrepentirá. Pero para mí, el mejor resultado que este desarrollador puede esperar es que haya tocado su techo con el equipo, y eso puede estar bien si conoce sus sistemas, hace bien su trabajo y no causa problemas. Si no es esta persona, sin embargo, tendrá que lidiar con ello eventualmente.

Esto es algo que debería haber sido prevenido, no tratado después del hecho. Lo siento pero si usted (como parece, sin ningún tipo de aviso previo) cambia repentinamente la dirección del desarrollo personal de los empleados, y se sorprende cuando esta no es la misma dirección hacia la que el desarrollador quiere progresar, el problema no es con el empleado.

¿Es justo ser gruñón en este escenario? Por supuesto. ¿Es justo solicitar un aumento? Tal vez, tal vez no - tal vez el empleado incluso se le paga demasiado. Dado que el empleador y el empleado obviamente tienen expectativas diferentes sobre el alcance del empleado, no es posible que un tercero diga.

La cultura también importa, por supuesto - estoy en Suecia FWIW (típicamente jerarquías relativamente planas y empleados con poder/gerentes débiles).

Así que llamé a los dos desarrolladores más antiguos y experimentados que tengo en mi equipo y les presenté el proyecto. Mientras que uno de ellos parecía realmente interesado en él, el otro estaba un poco… gruñón, por decir algo.

Usted tomó la decisión de pedir a los dos desarrolladores más experimentados que aceptaran el desafío. Si el que rechazó la tarea lo hubiera hecho sin ser gruñón, o hubiera presentado un argumento bien pensado, ¿habrías acudido al candidato número 3? Si es así, entonces hágalo.

Si todavía hay un lugar para el desarrollador que rechazó la oportunidad, entonces asígnele esa tarea.

Recuerde, no le está pidiendo que se salga un poco de su zona de confort. Les estás pidiendo que aprendan algunas matemáticas que tal vez no vean la necesidad de ir más allá de este proyecto. El mejor candidato puede no haber sido los dos desarrolladores más antiguos. Puede haber sido el desarrollador más joven, o incluso el interno (aunque no planearía pedirle a un interno que sea responsable de una habilidad crítica a largo plazo).

Déjeme jugar al abogado del diablo aquí:

• Su compañía ha tomado un trabajo en el que no tienen absolutamente ninguna competencia.
• Este trabajo es en un campo que es muy diferente a la mayoría de los otros campos en el desarrollo de software. Este no es su habitual “aprender un nuevo lenguaje de programación”, se trata de matemáticas de peso que incluso la mayoría de los matemáticos de tiempo completo temen.
• Su empresa se niega a contratar a una nueva persona para dirigir, en su lugar cree que la formación teórica y los cursos pueden compensar la falta de experiencia.
• Han puesto a un optimista y entusiasta desesperado al timón (usted)
• El líder (usted) ni siquiera puede reconocer que otras personas pueden tener objetivos diferentes a los suyos.

Ahora, no estoy diciendo que esto sea una receta para el desastre. Pero muchos desastres han seguido esta receta.

• Unirse a tu equipo de punta de lanza no es todo color de rosa como lo describes. Dices que se trata de aprender, pero no hay nadie con experiencia para enseñarte. Eso significa que aprenderás de tus propios errores y en muchos casos aprenderás mal. En el mejor de los casos, tendrás que desaprender grandes trozos de tu nuevo conocimiento. En el peor de los casos, nunca sabrás en qué te has equivocado.

Hay muchas posibilidades de que fracases. Hay muchas maneras de fallar, apuesto a que el tiempo (y por lo tanto el costo) se sobrepasa (unos pocos cientos %) por lo que su empresa tendrá una pérdida. En el peor de los casos, el cliente invocará cláusulas de penalización y su empresa perderá mucho más que su tiempo y sus salarios, por lo que los desarrolladores pueden ser despedidos con la reputación manchada. ¿No cree que ese riesgo vale la pena como compensación?

He pintado la imagen más pesimista, pero creo que es necesario para contrarrestar su optimismo.

Volvamos al último punto de mi lista de viñetas, que es lo único que usted personalmente ha hecho mal. Usted ha tomado la decisión sobre lo que otros desarrolladores quieren en sus manos. No pareces darte cuenta de que lo que tú ves como emocionante, otras personas pueden verlo como intimidante o simplemente aburrido. Lo ves como una mejora, mientras que te niegas a aceptar que otros puedan verlo como una reducción. O simplemente no encaja bien con su equilibrio entre trabajo y vida. Otro ángulo es que lo ves como dentro del ámbito de la posición de “desarrollador”. El problema es que no es más que una opinión. Una opinión opuesta, que constituye un nuevo trabajo es tan válida como la tuya. Tienes que esperar que otras personas no compartan tus opiniones. Está bien preguntar casualmente si alguien quiere el nuevo trabajo. Pero deberías haber esperado tanto un “no” como un “sí”.

También debes tener en cuenta que un trabajo es siempre un contrato. Y como cualquier contrato, se necesitan dos partes para cambiarlo. La descripción del trabajo es parte del contrato. No se puede cambiar la descripción del trabajo unilateralmente, así como el empleado no puede cambiar su salario unilateralmente. Sí, comúnmente se espera que un empleado mejore, pero eso no significa asumir nuevas responsabilidades, sino seguir siendo competitivo en el cumplimiento de las que fue contratado.

El contrato puede ser cambiado en cualquier momento siempre que ambas partes estén de acuerdo con el cambio. **

IMHO su pregunta no era real, simplemente no quiere el nuevo trabajo. Y te dio la vuelta a la tortilla, así que eres tú quien tiene que decir realmente “no”. No hay nada que puedas hacer aquí, excepto cambiar tu actitud sobre que tu equipo comparta tus creencias y objetivos de vida.

Creo que es justo pedir un aumento después de ser asignado a un trabajo especializado que requiere un conjunto específico de habilidades que no son comunes en el lugar de trabajo. Suena como si este fuera un proyecto de grandes datos y esas habilidades están muy demandadas y pagan mucho mejor que el salario promedio de un desarrollador. Esto también es cierto sólo si la tarea será continua.

Los aumentos para habilidades especializadas para un proyecto único de 3-6 meses no son apropiados (un bono podría ser). Los aumentos para el nuevo equipo permanente de Big Data sí lo son. Como líder, podría investigar los salarios de las personas con las habilidades que está pidiendo a su equipo y ver si sería apropiado discutir los aumentos salariales con la dirección después de que su equipo se haya probado.

Sin embargo, normalmente esa petición sería para todo el equipo y generalmente ocurriría después de que hayan adquirido la habilidad, aunque se podría prometer en una fecha determinada más tarde si las habilidades se adquirieron.

La forma en que se negó a calificarse sin un aumento está generalmente mal vista. Personalmente, ya que tiene otro personal para elegir, pasaría a la siguiente persona que podría estar interesada. Probablemente habría encuestado al equipo antes de solicitar a alguien que estuviera interesado en obtener estas habilidades y luego elegiría a los voluntarios después de que cada uno tuviera la oportunidad de hacer su caso para saber por qué debería ser elegido. No hay mucha gente que esté realmente interesada en las habilidades matemáticas superiores, una persona más joven podría ya haber hecho algún estudio en esta área porque era parte de sus intereses.

Gruñón manejó esto muy mal. Sin embargo…

Como alguien que fue desarrollador por décadas, y ahora es un investigador matemático que hace mucho análisis predictivo, yo como que veo el punto de Gruñón. Mientras que los desarrolladores de software tienen que estar preparados para aprender bits y piezas de una amplia variedad de disciplinas para hacer su trabajo, hay una diferencia significativa entre un desarrollador y un investigador, al igual que entre un gerente y un desarrollador. Esto no es como si se negara a aprender un nuevo lenguaje de programación o a averiguar cómo interactuar con algún hardware extraño; es más bien como si se negara a hacer diseño gráfico o a dirigir un equipo o a pilotar un avión.

Gruñón puede tener fobia a las matemáticas. Pero también es posible que sepa lo suficiente sobre estadística y minería de datos como para sospechar que será un trabajo difícil y turbio. En esta área particular de las matemáticas, es muy fácil aprender algunas técnicas, pero también es fácil aplicarlas en las situaciones equivocadas! Un estudiante de secundaria podría aprender a hacer ARIMA, pero saber cuándo es válido y cómo elegir los parámetros correctos es más a nivel de estudiante de postgrado. A muchos matemáticos no les gusta la estadística, no porque sea más difícil que otros campos, sino porque es más… difícil.

Como tú, salto a la oportunidad de aprender nuevas matemáticas, y me encanta mi trabajo. Pero puedo ver cómo Gruñón puede sentir que se le pide que haga algo que está demasiado lejos del papel de un desarrollador. Como dije, lo manejó muy mal, y no lo excuso. Pero puede tener alguna justificación para la forma en que se siente.

Hablando como matemático convertido en desarrollador de software simpatizo con Gruñón: es decir, ahora prefiero el desarrollo de software (y creo que ahora soy mejor en el desarrollo de software que en las matemáticas).

Por otra parte, si estuviera en el lugar de Gruñón y quisiera decírselo, lo haría… y lo haría sin confundir el tema mencionando el salario.

El hecho de que Gruñón mencionara el salario podría significar que Gruñón está gruñón por el salario, y este proyecto es meramente un disparador o una excusa para pedir un aumento.

Así que mi consejo sería tratar de separar los temas, aunque Gruñón no los separara. Pregunte, “¿Está Gruñón contento con su salario actual? ¿Está pidiendo un aumento a pesar de este nuevo proyecto?” Dado que él es el de dos desarrolladores más antiguos y experimentados ¿deberías ofrecerle un aumento incondicional primero, y luego preguntarle si está dispuesto a hacer esta nueva cosa?

Y / o ¿puedes tranquilizarlo sobre la naturaleza de las nuevas responsabilidades? Si yo fuera él, me preocuparía de fracasar. El aumento de salario podría ser “dinero del peligro” para compensarme por el aumento del riesgo o el estrés o las horas extras no pagadas. Por ejemplo, ¿la empresa le proporcionará suficiente ayuda (por ejemplo, un experto en dominios, es decir, un mentor de matemáticas) para garantizar su éxito?

Usted dice que se trata de “investigación a nivel académico” pero también de “básicamente I+D de software” que podría ser mutuamente excluyente/contradictorio. Aparentemente usted es más aficionado a la investigación académica que él a la suya…

¿Es posible que el promotor sienta que no le pagan lo suficiente por el trabajo que está haciendo ahora? Normalmente, cuando la gente dice “No me pagan lo suficiente para hacer esto”, quieren decir que sienten que están infravalorados en general, y podría ser un riesgo de fuga.

Si estás en posición de ajustar eso, y él está infravalorado (o no sobrevalorado groseramente), entonces puede que esté haciendo un buen argumento, y puedes ajustar sus objetivos empresariales para reflejar que si hace esta investigación y desarrolla este proyecto con éxito, obtendrá un aumento este año que será mejor que el aumento del coste de la vida. Proponga un porcentaje de antemano y documéntelo. O su compañía podría tener designaciones como “exceder las expectativas” que automáticamente resulten en un gran aumento, así que dígale que obtendrá “exceder las expectativas” y será compensado en consecuencia. El dinero puede ser un gran motivador, y convertir a los gruñones en felices acampantes.

O podría estar diciendo que realmente no se ve a sí mismo como un investigador matemático. Si ese es el caso, pídele a alguien más que lo haga y preséntalo al equipo. Si realmente es sólo una investigación, puede pedirle a su gerente de producto o analista de negocios que estudie la información y la relacione con el equipo de desarrollo en los requisitos.

Aunque realmente no soy un fanático de la fraseología de este tipo, especialmente en el desarrollo de software, nos pagan una cantidad bastante decente por hacer lo que hacemos, y lo que hacemos a menudo implica investigar para averiguar cómo vas a hacer lo que dijiste que ibas a hacer, creo que hay un núcleo de verdad en lo que está hablando. No, no deberías darle un aumento. Hay un punto en el que pedirle a una persona que no trabaja en matemáticas que haga cosas matemáticas es un mal momento tanto para ti como para ellos.

En realidad me he encontrado con una situación semi-similar en mi carrera como desarrollador. Quiero decir, en cierto modo no es exactamente lo mismo, pero aún así… como ya he dicho, soy un desarrollador. Desarrollo cosas. Si quieres implementar alguna lógica de negocios y tener widgets en una página web para saltar y hacer cosas, yo soy tu hombre. He trabajado en la parte trasera y en la delantera, he construido servicios web de nivel medio, y he cogido nuevos lenguajes y marcos sobre la marcha cuando lo he necesitado. Lo que no hago, debería decir, lo que no hago, bueno, es diseño. Si me piden que diseñe una página web, lo haré, no me malinterpreten, pero lo haré diciéndoles que no tengo entrenamiento o experiencia en esto y puede que no les gusten los resultados. Al final creo que será mejor contratar a un diseñador real y luego usarme para tomar el diseño de esa persona e implementarlo.

Así que lo que yo diría que se haga aquí es tomar a este tipo como si te dijera esto en lugar de “pagarme más”, porque en cierto sentido ese tipo de es lo que está haciendo. El problema aquí no es tanto que los desarrolladores de software cobren X y haciendo matemáticas deberían obtener X + 10%, es que algunos desarrollos de software no requieren de matemáticas y pedirle a la gente que haga muchas de ellas significa que vas a terminar con resultados menos que estelares. Dependiendo de la situación, yo podría recomendar:

• Revisar las habilidades de tus otros desarrolladores y ver si alguien más en tu equipo tiene una formación más matemática, o está dispuesto a aprender lo que tú necesitas aprender. Incluso podrías venderles la idea de que esto representa una nueva herramienta que pueden aprender y llevar con ellos a futuras actuaciones (¡ver abajo!). La mayor desventaja aquí es que además del tiempo extra que se gasta en acelerar las cosas (y en el proceso, posiblemente aprendiendo nuevas arquitecturas y marcos), ese desarrollo en particular también se va a retrasar por tener que aprender y entender las matemáticas que quieres implementar.

• Traer un analista para resolver las ecuaciones y luego hacer que tus actuales desarrolladores implementen las ecuaciones en el código, al igual que lo harían con cualquier otra pieza de la lógica de negocios. Esto tiene el inconveniente de que la persona que sabe las matemáticas no está al final escribiendo las matemáticas en tu sistema, pero eso se puede resolver muy fácilmente poniendo énfasis en el desarrollo basado en pruebas (lo cual ya estás haciendo, ¿verdad? ¿Verdad?). Este método también tiene la ventaja de que, si trabajas, por ejemplo, en finanzas, puedes coger uno de los números de la gente de su departamento: lo más probable es que conozcan estas cosas mejor que prácticamente cualquier s-dev que puedas traer de la calle porque ese es su trabajo.

• Traer a un consultor externo para que se encargue de nada más que de la parte matemática del código, y luego simplemente bloquear esa parte para que no se vuelva a tocar nunca más. Esto también es problemático por muchas razones, primero y principal, el día que encuentro un código que no necesita ser refactorizado es el día que me presento al desarrollador más psíquico de la historia, pero dependiendo de lo que estés tratando de hacer, esta podría ser la manera de hacerlo. Ese otro tipo puede costar un poco más de lo que pagas por tus desarrollos actuales, pero, bueno, es un subcampo especializado.

Como dije, no soy un gran fan de la fraseología aquí, y tal vez eso en sí mismo significa que necesitas tener una charla con la persona que está diciendo esto (yo, como un aparte, sería un poco cauteloso de que no se adhiera al Factor Bus y puede ser el momento de revisar algo del código de este tipo, no como castigo sino porque la gente del IME que piensa en términos de grados de pago en esta industria también piensa en términos de hacer cosas para hacerse irremplazables). No creo que esté necesariamente equivocado sin embargo.

Mencionas que Gruñón es uno de los desarrolladores más antiguos. Me pregunto cuántos años. Hace años tuve a alguien trabajando para mí que tenía unos 50 años, era un desarrollador competente, era feliz en su trabajo, pero se negó a asumir cualquier responsabilidad extra. Resultó que había una historia, había tenido que hacer una pausa en su carrera en el pasado debido al estrés, conocía sus límites, y no quería sobrepasarlos. Respetar su juicio y utilizarlo para las cosas que hace bien.

Diría que la respuesta depende de cuán precisa sea la evaluación del promotor.

Si la descripción de su trabajo incluye realmente hacer este tipo de trabajo, y su salario es apropiado para ello, entonces su afirmación es inexacta.

Por otro lado, la descripción de su trabajo y/o su tasa de pago no coinciden con el nuevo tipo de trabajo, entonces deben ser ajustados para reflejar eso con precisión.

En general, incluso si una compañía entrena a un empleado en una nueva descripción de trabajo, eso no significa que la compañía no deba ajustar la descripción del trabajo y la tasa de pago de ese empleado para que coincidan. Algunas empresas pueden intentar hacerlo, pero no es apropiado y es propenso a disminuir la moral y eventualmente perder empleados.

Por sus comentarios, parece que no está seguro. En lugar de (como han sugerido otras respuestas aquí) convertir su declaración en una negativa o una mala actitud, sugeriría tratarlo como una sugerencia respetable para adultos, y responder de una manera profesional adulta, reconociendo la sugerencia y consultando a personas que sabrían lo que es apropiado para ese tipo de trabajo, y luego devolverle la llamada sobre lo que ha averiguado al respecto.

El empleado declara que no quiere hacer un trabajo para el que no fue contratado, y ofrece un compromiso: Más dinero y hará el trabajo de todos modos.

Necesitas rechazar la opción de más dinero. Si no quiere hacer el trabajo, es probable que no esté contento con el trabajo a pesar del dinero adicional, y la infelicidad puede ser contagiosa. Además, sienta un mal precedente para las personas que quieren hacer el trabajo pero que ahora saben que pueden pedir un aumento antes de aprender algo diferente.

Tratar esto como cualquier otro empleado que no quiere hacer un trabajo para el que no fue contratado. Y la forma de manejarlo depende de muchos otros detalles, pero en este caso específico, le agradeces el tiempo y pides un voluntario diferente, porque este es el tipo de proyecto en el que quieres trabajar con gente que quiere trabajar en él.

Creo que un par de puntos menores relacionados con la pregunta no han sido preguntados/respondidos por otros carteles (a partir de esta publicación):

• ¿Cuál es el título del antiguo puesto?
• ¿Cuánto se le paga a ese puesto? (Tasas de mercado)
• ¿Cuál es el título de la nueva posición?
• ¿Cuánto se paga por ese título? (Tasas de mercado)
• ¿Cuál es la diferencia de pago entre “Desarrollador Senior” y “Ese título”
• ¿Vale la pena el tiempo/esfuerzo para que él obtenga la diferencia de pago?

¿Cuál es el título de la posición actual? Diferentes títulos tienen diferentes tasas de pago… hay una diferencia entre un Desarrollador y un Ingeniero… un Desarrollador Senior y un Ingeniero Senior. ¿Cómo se llama el nuevo título? ¿Desarrollador de Matemáticas? ¿Desarrollador investigador? ¿Ingeniero de Investigación Senior?

¿Qué es lo que se le paga a alguien de ese título, en tasas de mercado? Hay algunas posiciones que son “más difíciles” pero que cobran menos… Piensa Investigador en Universidades… mucha gente tratando de conseguir las posiciones para que la demanda baje las tasas de mercado.

¿Cuál es la diferencia entre el “Título” actual y el “Nuevo Título” en el mercado? Si es $1000/año… esa es una conversación diferente a la de $75000 al año…

Lo que significa… ¿merece la pena que “Gruñón Dev” aprenda “Investigación Matemática”? Sí, es cierto que parte de la vida de un desarrollador es aprender cosas nuevas… también es aprender cosas nuevas que son valiosas. Ya sea en términos monetarios (aumento de sueldo) o en otros términos (progresión de carrera, nuevas oportunidades, nuevas tecnologías)…

Sir Gruñón, para mí, ha dejado claro que su principal prioridad es el dinero. Si él quiere ser un desarrollador de Front End y usted está tratando de convertirlo en un desarrollador de Ciencias Aplicadas… puede que no valga la pena para él cambiar - dada la misma escala de pago. La única manera de que él considere que vale la pena sería con $$$$. O eso, o no está interesado y te está pasando la responsabilidad a ti. ¿Las tasas de mercado se alinean con sus expectativas? ¿Sus expectativas?

Creo que ya se ha dado una respuesta a tu problema - que si tienes a una persona en tu equipo que no está interesada en un proyecto que va en una nueva dirección, pero necesitas a alguien con experiencia para ayudar, entonces vas a la persona con la siguiente mayor experiencia después de él, o quizás incluso consideras investigar sus habilidades específicas (¿alguien en tu equipo tiene conocimientos de matemáticas?) y le dejas continuar haciendo el mantenimiento que tu equipo normalmente hace.

Pero para responder a tu pregunta - ‘¿es esta una petición justa? es justo que él pida por ello, pero no se le exige en absoluto que vaya más allá.

Si ha hecho la debida investigación y se ha asegurado de que la tasa de pago para una persona de su experiencia en su posición se ajusta a los valores del mercado, entonces hay poco espacio para argumentar que un aumento permanente está en orden.

También considere la implicación completa de su título - un desarrollador de software _se espera que realice alguna investigación y desarrollo cuando sea relevante para su posición. Hasta ahora, no lo ha sido. Pero como su equipo está siendo encargado de implementar este nuevo tipo de programa, ahora es parte del trabajo, y rechazar la realización de esas tareas significa rechazar una parte de su trabajo.

A partir de ahora, eso no es una cuestión condenatoria - tiene otros desarrolladores a los que puede poner en esta tarea en su lugar. Pero si su equipo continúa necesitando desarrolladores que tengan algún conocimiento de este tipo de matemáticas, este empleado puede convertirse en una carga si no está dispuesto a aprender. Así que tenlo en cuenta.

Ten en cuenta que si está o no dentro de la descripción de su trabajo también depende de su contrato - muchos contratos tienen una cláusula para “cualquier otra tarea requerida para realizar su trabajo”, que incluye entrenamiento adicional como este.

Lo que tu compañero de equipo está pidiendo no es justo… en absoluto.

Aprender nuevas habilidades es parte de cualquier trabajo, especialmente hoy en día en la industria de la tecnología.

Tu compañía está ofreciendo pagar por el entrenamiento, así que no es como si tu compañero de equipo estuviera siendo arrojado al fondo.

La mayoría de la gente apreciaría la oportunidad de expandir y mejorar sus habilidades a un bajo o ningún costo, y ser capaz de aprender esencialmente en el trabajo.

La respuesta de tu compañero de equipo es francamente insubordinada y tóxica. No necesitas a nadie así en tu equipo.

Este asunto debería ser elevado a un gerente o alguien que sea responsable de evaluar el desempeño de tu compañero de equipo.