Comment gérer un argument "je ne suis pas assez payé pour faire cette tâche" ?

Eh bien, la solution ici est simple. Remerciez Grumpy pour son honnêteté, remettez-le sur des tâches régulières et faites venir le prochain gars du banc.

Si quelqu'un n'est pas intéressé par un projet comme celui-ci et qu'il y a d'autres personnes disponibles, alors il est dans l'intérêt de tous de mettre sur le projet les personnes qui y sont le plus intéressées. Donner une augmentation à un grincheux ne va pas le rendre plus enthousiaste pour le projet, il n'est donc pas dans votre intérêt ni dans celui du projet de l'avoir quand même.

Plus tard, vous devrez aussi faire des choix difficiles. Je garderais un œil sur l'attitude de ce développeur et sur la façon dont elle affecte l'équipe. Il se peut que vous ayez un cancer au départ. S'il aime vraiment son travail, c'est une de ces déclarations qu'il en viendra à regretter. Mais pour moi, le meilleur résultat que ce développeur puisse espérer est qu'il ait atteint son plafond avec l'équipe - et cela peut être correct s'il connaît vos systèmes, fait bien son travail et ne pose pas de problèmes. Mais si ce n'est pas cette personne, vous allez devoir y faire face un jour ou l'autre.

**C'est quelque chose qui aurait dû être évité, et non pas traité après coup. Je suis désolé, mais si vous (comme il semble, sans aucune sorte d'avertissement préalable) changez soudainement la direction du développement personnel de l'employé, et que vous êtes surpris quand ce n'est pas la même direction que celle vers laquelle le développeur veut progresser, le problème ne se situe pas au niveau de l'employé.

Est-il juste d'être grincheux dans ce scénario ? Bien sûr. Est-il juste de demander une augmentation ? Peut-être, peut-être pas - peut-être même que l'employé est trop payé. Comme l'employeur et l'employé ont manifestement des attentes différentes quant au champ d'action de l'employé, il n'est pas possible pour un tiers de le dire.

La culture compte aussi bien sûr - je suis en Suède FWIW (généralement des hiérarchies relativement plates et des employés habilités/des cadres faibles).

J'ai donc appelé les deux développeurs les plus anciens et les plus expérimentés de mon équipe et je leur ai présenté le projet. Alors que l'un d'entre eux semblait vraiment intéressé, l'autre était un peu… grincheux, c'est le moins qu'on puisse dire.

Vous avez fait le choix de demander aux deux développeurs les plus expérimentés de relever le défi. Si celui qui avait refusé la tâche l'avait fait sans être grincheux, ou avait présenté un argument bien réfléchi, vous seriez-vous contenté de vous tourner vers le candidat n°3 ? Si oui, faites-le.

S'il reste une place pour le développeur qui a décliné l'opportunité, alors assignez-leur cette tâche.

Rappelez-vous que vous ne leur demandez pas de sortir légèrement de leur zone de confort. Vous leur demandez d'apprendre des mathématiques dont ils ne verront peut-être pas la nécessité au-delà de ce projet. Le meilleur candidat n'était peut-être pas les deux développeurs les plus expérimentés. Il se peut que ce soit le développeur le plus jeune, ou même le stagiaire (bien que je ne prévoie pas de demander à un stagiaire d'être responsable d'une compétence critique à long terme).

Permettez-moi de me faire l'avocat du diable :

• Votre entreprise a entrepris un travail dans lequel elle n'a absolument aucune compétence.
• Ce travail se situe dans un domaine très différent de la plupart des autres domaines du développement de logiciels. Il ne s'agit pas d'apprendre un nouveau langage de programmation, ce sont des mathématiques lourdes que même la plupart des mathématiciens à plein temps redoutent.
• Votre entreprise refuse d'engager une nouvelle personne pour diriger, elle pense plutôt que des formations et des cours théoriques peuvent compenser l'absence d'expérience.
• Ils ont mis un optimiste et un enthousiaste désespéré à la barre (vous)
• Le leader (vous) ne peut même pas reconnaître que d'autres personnes peuvent avoir des objectifs différents des siens.

Maintenant, je ne dis pas que c'est une recette pour le désastre. Mais de nombreuses catastrophes ont suivi cette recette.

Rejoindre votre équipe de fer de lance n'est pas tout rose comme vous le décrivez. Vous dites qu'il s'agit d'apprendre, mais il n'y a personne avec de l'expérience pour vous enseigner. Cela signifie que vous apprendrez sur vos propres erreurs et, dans de nombreux cas, vous apprendrez mal. Dans le meilleur des cas, vous devrez désapprendre une grande partie de vos nouvelles connaissances. Dans le pire des cas, vous ne saurez jamais ce que vous avez fait de mal.

Il y a de fortes chances que vous échouiez. Il existe de nombreuses façons d'échouer. Je parie sur un dépassement important des délais (donc des coûts) (quelques centaines de %) pour que votre entreprise fasse une perte. Dans le pire des cas, le client invoquera des clauses de pénalité et votre entreprise perdra bien plus que votre temps et vos salaires, de sorte que les développeurs risquent d'être licenciés pour atteinte à leur réputation. Ne pensez-vous pas que ce risque mérite une compensation ?

J'ai peint l'image la plus pessimiste, mais je crois qu'il est nécessaire de contrebalancer votre optimisme.

Revenons au dernier point de ma liste de points, qui est la seule chose que vous avez personnellement mal faite. Vous avez pris la décision de ce que les autres développeurs veulent vous confier. Vous ne semblez pas réaliser que ce que vous considérez comme palpitant, d'autres personnes peuvent le considérer comme intimidant ou simplement ennuyeux. Vous le voyez comme une amélioration tout en refusant d'accepter que d'autres puissent le voir comme une dégradation. Ou tout simplement pas un bon équilibre entre leur vie professionnelle et leur vie privée. Un autre angle d'approche est que vous considérez que cela relève du poste de “développeur”. Le problème est que ce n'est rien d'autre qu'une opinion. Une opinion contraire, selon laquelle il s'agit d'un tout nouvel emploi, est tout aussi valable que la vôtre. Vous devez vous attendre à ce que les autres personnes ne partagent pas vos opinions. Il n'y a pas de mal à demander à quelqu'un s'il veut le nouveau poste. Mais vous auriez dû vous attendre à un “non” autant qu'à un “oui”.

Vous devez également garder à l'esprit qu'un emploi est toujours un contrat. Et comme pour tout contrat, il faut que deux parties le changent. La description de l'emploi fait partie du contrat. Vous ne pouvez pas modifier la description de poste unilatéralement, tout comme l'employé ne peut pas modifier unilatéralement son salaire. Oui, on attend généralement d'un employé qu'il s'améliore, mais cela ne signifie pas qu'il doive assumer de nouvelles responsabilités, cela signifie qu'il doit rester compétitif dans l'exercice de celles pour lesquelles il a été engagé. Le contrat peut être modifié à tout moment si les deux parties sont d'accord. **C'est aussi bien pour lui de demander une augmentation que pour vous de demander un changement de poste, mais tout le monde doit être prêt à vivre avec la réponse. Et il a retourné la situation contre toi, donc c'est toi qui dois dire “non”. Vous n'avez rien à faire ici, si ce n'est changer d'attitude sur le fait que votre équipe partage vos convictions et vos objectifs de vie.

Je pense qu'il est juste de demander une augmentation après avoir été affecté à un travail spécialisé qui requiert un ensemble de compétences spécifiques qui ne sont pas courantes sur le lieu de travail. Il semble qu'il s'agisse d'un projet de type données importantes et que ces compétences soient très demandées et payent beaucoup mieux que le salaire moyen d'un développeur. Cela n'est également vrai que si la tâche est continue.

Les augmentations pour des compétences spécialisées pour un projet unique de 3 à 6 mois ne sont pas appropriées (une prime pourrait l'être). Les augmentations pour la nouvelle équipe permanente de Big Data le sont. En tant que responsable, vous pourriez faire des recherches sur les salaires des personnes possédant les compétences que vous demandez à votre équipe et voir s'il serait approprié de discuter des augmentations de salaire avec la direction après que votre équipe ait fait ses preuves.

Cependant, normalement, cette demande concerne l'ensemble de l'équipe et se fait généralement après l'acquisition des compétences, bien qu'elle puisse être promise à une certaine date ultérieure si les compétences ont été acquises.

La façon dont il s'y est pris en refusant de se qualifier sans augmentation est généralement mal vue. Personnellement, puisque vous avez d'autres personnels à choisir, je passerais à la personne suivante qui pourrait être intéressée. J'aurais probablement fait un sondage auprès de l'équipe avant de demander à quelqu'un de voir qui était intéressé par l'acquisition de ces compétences, puis j'aurais fait mon choix parmi les volontaires après que chacun ait eu l'occasion de faire valoir ses arguments pour justifier son choix. Il n'y a pas beaucoup de personnes qui sont vraiment intéressées par les compétences supérieures en mathématiques, une personne plus jeune aurait peut-être déjà fait des études dans ce domaine, car cela faisait partie de ses intérêts.

Grumpy a très mal géré cette très mauvaise affaire. Cependant…

En tant que développeur pendant des décennies, et maintenant chercheur en mathématiques faisant beaucoup d’ analyse prédictive, je vois un peu le point de vue de Grumpy. Alors que les développeurs de logiciels doivent être prêts à apprendre des bribes d'informations dans une grande variété de disciplines pour faire leur travail, il y a une différence significative entre un développeur et un chercheur, tout comme il y a une différence entre un gestionnaire et un développeur. Ce n'est pas comme s'il refusait d'apprendre un nouveau langage de programmation ou de trouver comment s'interfacer avec un matériel bizarre ; c'est plutôt comme s'il refusait de faire de la conception graphique ou de gérer une équipe ou de piloter un avion.

Grumpy peut être mathématicien-phobe. Mais il est également possible qu'il en sache assez sur les statistiques et le data mining pour suspecter que ce sera un travail difficile et obscur. Dans ce domaine particulier des mathématiques, il est très facile d'apprendre certaines techniques, mais il est également facile de les appliquer dans les mauvaises situations ! Un lycéen pourrait apprendre à faire ARIMA, mais savoir quand c'est valable et comment choisir les bons paramètres relève plutôt du niveau des étudiants de troisième cycle. Beaucoup de mathématiciens n'aiment pas les statistiques, non pas parce que c'est plus difficile que d'autres domaines, mais parce que c'est plus… compliqué.

Comme vous, je saute sur l'occasion d'apprendre de nouvelles maths, et j'aime mon travail. Mais je comprends que Grumpy puisse se sentir obligé de faire quelque chose qui dépasse de loin le rôle de développeur. Comme je l'ai dit, il a très mal géré la situation, et je ne l'excuse pas. Mais il peut avoir une justification pour la façon dont il se sent.

En tant que mathématicien devenu développeur de logiciels, je sympathise avec Grumpy : c'est-à-dire que je préfère maintenant le développement de logiciels (et je pense que je suis maintenant meilleur en développement de logiciels qu'en mathématiques).

Par contre, si j'étais à la place de Grumpy et que je voulais vous le dire, je le ferais – et je le ferais sans confondre la question en mentionnant le salaire.

Le fait que Grumpy ait mentionné le salaire pourrait signifier que Grumpy est grincheux à propos du salaire, et ce projet n'est qu'un déclencheur ou une excuse pour demander une augmentation.

Donc mon conseil serait d'essayer de séparer les questions, même si Grumpy ne les a pas séparées. Demandez : “Grumpy est-il satisfait de son salaire actuel ? Demande-t-il une augmentation indépendamment de ce nouveau projet ?” Étant donné qu'il est l'un des deux développeurs les plus anciens et les plus expérimentés, devriez-vous d'abord lui offrir une augmentation inconditionnelle, puis lui demander s'il est prêt à faire cette nouvelle chose ?

Et/ou pouvez-vous le rassurer sur la nature de ses nouvelles responsabilités ? Si j'étais à sa place, je pourrais craindre d'échouer. L'augmentation de salaire pourrait être une “prime de risque” pour me compenser en cas de risque accru, de stress ou d'heures supplémentaires non rémunérées. Par exemple, l'entreprise lui apportera-t-elle une aide suffisante (par exemple un expert du domaine, c'est-à-dire un mentor en mathématiques) pour garantir son succès ?

Vous dites qu'il s'agit de “recherche de niveau universitaire” mais aussi de “R&D essentiellement logicielle” qui pourraient être mutuellement exclusives/contradictoires. Apparemment, vous êtes plus passionné par la recherche académique que lui ?

Est-il possible que le promoteur estime qu'il n'est pas suffisamment payé pour le travail qu'il effectue actuellement ? Si vous êtes en mesure d'ajuster cela, et qu'il est sous-évalué (ou qu'il n'est pas surévalué), alors il pourrait faire valoir un bon argument, et vous pouvez ajuster les objectifs de son entreprise pour refléter le fait que s'il effectue cette recherche et développe ce projet avec succès, il obtiendra cette année une augmentation qui sera meilleure que l'augmentation du coût de la vie. Proposez un pourcentage à l'avance et documentez-le. Votre entreprise peut aussi avoir des désignations telles que “dépasse les attentes” qui entraînent automatiquement une augmentation importante. Dites-lui donc qu'il obtiendra “dépasse les attentes” et qu'il sera rémunéré en conséquence. L'argent peut être une grande source de motivation et transformer les grincheux en campeurs heureux.

Ou il pourrait dire qu'il ne se considère pas vraiment comme un chercheur en mathématiques. Si c'est le cas, demandez à quelqu'un d'autre de le faire et présentez-le à l'équipe. S'il s'agit vraiment d'une simple recherche, vous pouvez demander à votre chef de produit ou à votre analyste commercial d'étudier l'information et de la présenter à l'équipe de développement dans les exigences.

Bien que je ne sois vraiment, vraiment pas fan de la formulation de ce type - dans le développement de logiciels en particulier, nous sommes payés un montant assez décent pour faire ce que nous faisons, et ce que nous faisons implique souvent des recherches pour savoir comment vous allez faire la chose que vous avez dit que vous alliez faire - je pense qu'il y a un noyau de vérité dans ce dont il parle. Non, vous ne devriez pas lui donner une augmentation. Mais il y a un point où demander à une personne qui ne travaille pas avec des choses mathématiques de faire des choses mathématiques va être un mauvais moment pour vous et pour elle.

J'ai en fait rencontré une situation semi-similaire dans ma carrière de développeur. Je veux dire, d'une certaine façon, ce n'est pas exactement la même chose, mais quand même… comme on l'a dit, je suis un développeur. Je développe des choses. Si vous voulez mettre en place une logique commerciale et avoir des widgets sur une page web pour sauter partout et faire des choses, je suis votre homme. J'ai travaillé sur le back-end et le front-end, j'ai construit des services web de niveau intermédiaire, et j'ai appris de nouveaux langages et de nouveaux cadres à la volée quand j'en ai eu besoin. Ce que je ne fais pas - je devrais dire, ce que je ne fais pas - c'est le design. Si vous me demandez de concevoir une page web, je le ferai, ne vous méprenez pas, mais je le ferai en vous disant que je n'ai pas de formation ou d'expertise dans ce domaine et que vous n'aimerez peut-être pas les résultats. En fin de compte, je pense que vous ferez mieux d'engager un vrai designer et de m'utiliser pour prendre le design de cette personne et le mettre en œuvre.

Donc ce que je dirais de faire ici, c'est de prendre ce type comme s'il vous disait cette chose au lieu de “me payer plus”, parce que dans un sens, c'est ce genre de c'est ce qu'il fait. Le problème ici n'est pas tant que les développeurs de logiciels soient payés X et que les mathématiques devraient vous rapporter X + 10%, mais que certains développements de logiciels ne nécessitent pas vraiment de mathématiques et que demander aux gens d'en faire beaucoup signifie que vous allez vous retrouver avec des résultats moins qu'excellents. En fonction de la situation, je pourrais vous recommander :

• d'examiner les compétences de vos autres développeurs et de voir si un autre membre de votre équipe a une formation plus mathématique, ou est prêt à apprendre ce que vous avez besoin d'apprendre. Vous pourriez même leur faire croire que cela représente un nouvel outil qu'ils peuvent apprendre et emporter avec eux lors de futurs concerts (voir ci-dessous !). Le plus gros inconvénient est qu'en plus du temps supplémentaire passé à accélérer les choses (et, ce faisant, à apprendre de nouvelles architectures et de nouveaux cadres), ce développeur sera également ralenti par le fait qu'il devra apprendre et comprendre les mathématiques que vous voulez mettre en œuvre.

• Faire venir un analyste pour comprendre les équations, puis demander à vos développeurs actuels de les coder, comme ils le feraient pour n'importe quelle autre logique commerciale. L'inconvénient est que la personne qui connaît les mathématiques n'écrit pas en fin de compte les calculs dans votre système, mais cela peut être assez facilement résolu en mettant l'accent sur le développement piloté par les tests (ce que vous faites déjà, n'est-ce pas ?). Cette méthode présente également l'avantage, si vous travaillez dans le domaine des finances par exemple, de pouvoir saisir l'un des chiffres de leur département : il y a de fortes chances qu'ils connaissent mieux ce domaine que pratiquement tous les autres départements que vous pouvez faire venir de la rue, car c'est leur travail.

• Faire appel à un consultant tiers pour ne s'occuper que de la partie mathématique du code, puis verrouiller cette partie pour qu'elle ne soit plus jamais touchée. C'est également problématique pour de nombreuses raisons - tout d'abord, le jour où je trouve un code qui n'a pas besoin d'être retravaillé en cours de route est le jour où je me présente au développeur le plus psychique de tous les temps - mais selon ce que vous essayez de faire, c'est peut-être la bonne façon de procéder. Cet autre type peut coûter un peu plus cher que ce que vous payez à vos développeurs actuels, mais c'est un sous-domaine spécialisé. Comme je l'ai dit, je ne suis pas vraiment fan de la formulation ici, et peut-être que cela signifie en soi que vous devez avoir une discussion avec la personne qui dit cela (je me méfierais, en passant, s'il n'adhérait pas au Bus Factor et il serait peut-être temps de passer en revue une partie du code de ce type, non pas comme une punition mais parce que les gens de l'IME qui pensent en termes de salaire dans cette industrie pensent aussi en termes de faire des choses pour se rendre irremplaçables). Mais je ne pense pas qu'il soit forcément fautif.

Vous mentionnez que Grumpy est l'un des plus anciens développeurs. Je me demande quel âge il a. Il y a des années, j'avais quelqu'un qui travaillait pour moi et qui avait la cinquantaine, c'était un développeur compétent, il était heureux dans son travail, mais il refusait de prendre des responsabilités supplémentaires. Il s'est avéré qu'il y avait une histoire, qu'il avait dû faire une pause dans sa carrière par le passé à cause du stress, qu'il connaissait ses limites et qu'il ne voulait pas les dépasser. Respectez son jugement et utilisez-le pour les choses qu'il fait bien.

Je dirais que la réponse dépend de la précision de l'évaluation du promoteur.

Si sa description de poste inclut effectivement ce type de travail, et que son taux de rémunération est approprié pour cela, alors sa déclaration est inexacte. En général, même si une entreprise forme un employé à une nouvelle description de poste, cela ne signifie pas que l'entreprise ne doit pas adapter la description de poste et le taux de rémunération de cet employé pour qu'ils correspondent. Certaines entreprises peuvent essayer de le faire, mais cela n'est pas approprié et risque de démoraliser les employés et de les perdre à terme.

D'après vos commentaires, il semble que vous n'en soyez pas sûr. Plutôt que (comme d'autres réponses l'ont suggéré) de transformer sa déclaration en refus ou en mauvaise attitude, je vous suggère de la traiter comme une suggestion respectable d'adulte, et d'y répondre de manière professionnelle, en prenant acte de la suggestion et en consultant des personnes qui sauraient ce qui est approprié pour ce type de travail, puis de lui faire part de ce que vous avez découvert à ce sujet.

L'employé déclare qu'il ne veut pas faire un travail pour lequel il n'a pas été engagé et propose un compromis : plus d'argent et il fera le travail de toute façon.

Vous devez rejeter l'option plus d'argent. S'il ne veut pas faire le travail, il sera probablement mécontent de faire le travail malgré l'argent supplémentaire, et le mécontentement peut être contagieux. De plus, cela crée un mauvais précédent pour les personnes qui veulent faire le travail mais savent maintenant qu'elles peuvent demander une augmentation avant d'apprendre quelque chose de différent.

Traitez-le comme n'importe quel autre employé qui ne veut pas faire un travail pour lequel il n'a pas été embauché. Et la façon dont vous traitez cela dépend de nombreux autres détails, mais dans ce cas précis, vous le remerciez pour le temps qu'il vous a consacré et vous demandez un autre volontaire, parce que c'est le genre de projet sur lequel vous voulez travailler avec des gens qui veulent y travailler.

Je pense que quelques points mineurs liés à la question n'ont pas été posés/répondus par d'autres affiches (à partir de cet affichage) :

• Quel est le titre de l'ancien poste ?
• Quel est le salaire de ce poste ? (Taux du marché)
• Quel est le titre du nouveau poste ?
• Quel est le salaire de ce titre ? (Taux du marché)
• Quelle est la différence de rémunération entre “Senior Developer” et “That Title”

• Le temps/les efforts qu'il a consacrés à obtenir la différence de rémunération en valent-ils la peine ?

• Quel est le titre du poste actuel ? Différents titres obtiennent différents taux de rémunération… il y a une différence entre un développeur et un ingénieur… un développeur senior et un ingénieur senior. Comment s'appelle le nouveau titre ? Développeur en mathématiques ? Chercheur développeur ? Ingénieur de recherche senior ?

Qu'est-ce qu'une personne de ce titre est payée, aux taux du marché ? Certains postes sont “plus difficiles” mais sont moins bien rémunérés… Pensez Chercheur dans les universités… beaucoup de gens essaient d'obtenir les postes pour lesquels la demande fait baisser les taux du marché.

Quelle est la différence entre le “Titre” actuel et le “Nouveau Titre” sur le marché ? Si c'est 1000$/an… c'est une conversation différente de celle de 75000$ par an…

Ce qui veut dire… est-ce que ça vaut la peine pour “Grumpy Dev” d'apprendre “Math Research” ? Oui, il est vrai qu'une partie de la vie d'un développeur consiste à apprendre de nouvelles choses… c'est aussi apprendre de nouvelles choses qui ont de la valeur. Que ce soit en termes monétaires (augmentation de salaire) ou en d'autres termes (progression de carrière, nouvelles opportunités, nouvelles technologies)…

Sir Grumpy, pour moi, a clairement indiqué que sa principale priorité est l'argent. S'il veut être un développeur de premier plan et que vous essayez d'en faire un développeur de sciences appliquées… cela ne vaut peut-être pas la peine pour lui de changer - étant donné la même échelle de salaires. La seule façon pour lui de considérer que cela en vaut la peine serait $$$. Soit cela, soit il n'est pas intéressé et vous en confie la responsabilité. Les taux du marché correspondent-ils à ses attentes ? Vos attentes ?

J'ai le sentiment qu'une réponse à votre problème a déjà été fournie : si un membre de votre équipe n'est pas intéressé par un projet allant dans une nouvelle direction, mais que vous avez besoin de l'aide d'une personne expérimentée, alors vous vous adressez à la personne ayant la plus grande expérience après lui, ou peut-être même envisagez-vous de vous renseigner sur ses compétences spécifiques (est-ce que quelqu'un dans votre équipe a une formation en mathématiques ?) et de le laisser continuer à faire l'entretien que votre équipe fait habituellement. Si vous avez fait les recherches nécessaires et vous êtes assuré que le taux de rémunération d'une personne de son expérience dans son poste correspond aux valeurs du marché, il n'y a guère de place pour soutenir qu'une augmentation permanente est nécessaire. De même, considérez toutes les implications de son titre - un développeur de logiciels est censé effectuer des recherches et du développement lorsque cela est pertinent pour son poste. Jusqu'à présent, cela n'a pas été le cas. Mais comme votre équipe est chargée de mettre en œuvre ce nouveau type de programme, cela fait maintenant partie de son travail, et refuser d'effectuer ces tâches signifie refuser une partie de son travail.

Pour l'instant, ce n'est pas un problème accablant - vous avez d'autres développeurs que vous pouvez charger de cette tâche à la place. Mais si votre équipe continue à avoir besoin de développeurs qui ont une certaine compréhension de ce type de mathématiques, cet employé peut devenir un handicap s'il n'est pas disposé à apprendre. Gardez donc cela à l'esprit.

Notez que le fait que cela fasse partie ou non de sa description de poste dépend également de son contrat - de nombreux contrats comportent une clause pour “toute autre tâche nécessaire à l'exécution de votre travail”, qui inclut une formation supplémentaire comme celle-ci.

**Ce que votre coéquipier demande n'est pas juste du tout.

L'apprentissage de nouvelles compétences fait partie de tout emploi, surtout aujourd'hui dans l'industrie technologique.

Votre entreprise offre de payer pour la formation, ce n'est donc pas comme si votre coéquipier était jeté au fond du trou.

La plupart des gens apprécieraient d'avoir la possibilité d'élargir et d'améliorer leurs compétences à peu de frais ou gratuitement, et de pouvoir essentiellement apprendre sur le tas.

La réponse de votre coéquipier est franchement insubordonnée et toxique. Vous n'avez besoin de personne de ce genre dans votre équipe.

Ce problème devrait être soumis à un responsable ou à une personne chargée d'évaluer les performances de votre coéquipier.