Hoe ga je om met een "ik word niet genoeg betaald om deze taak te doen" argument?

Nou, de oplossing is hier eenvoudig. Bedank mopperig voor zijn eerlijkheid, zet hem terug op reguliere taken, en breng de volgende man van de bank binnen.

Als iemand niet geïnteresseerd is in een project als dit en er zijn andere mensen beschikbaar dan is het in ieders belang om de mensen op het project te zetten die het meest geïnteresseerd zijn in het project. Het geven van een verhoging zal hem niet enthousiaster maken over het project, dus het is niet in jouw of in het project geïnteresseerd om hem daar toch te hebben.

Verderop zul je ook moeilijke keuzes moeten maken. Ik zou een oogje in het zeil houden op de houding van deze ontwikkelaar en hoe dit het team beïnvloedt. Het kan zijn dat je een beginnend kankergezwel hebt. Als hij echt van zijn werk geniet, is dit een van die uitspraken waar hij spijt van zal krijgen. Maar voor mij is het beste resultaat waar deze ontwikkelaar op kan hopen dat hij zijn plafond heeft bereikt met het team - en dat kan goed zijn als hij uw systemen kent, zijn werk goed doet en geen problemen veroorzaakt. Maar als dat deze persoon niet is, zul je er uiteindelijk toch mee te maken krijgen.

Dit is iets wat voorkomen had moeten worden , niet achteraf behandeld. Het spijt me, maar als je (zoals het lijkt, zonder enige vorm van eerdere waarschuwing) plotseling de richting van de medewerkers persoonlijke ontwikkeling verandert, en verrast wordt als dit niet dezelfde richting is waar de ontwikkelaar naartoe wil gaan, ligt het probleem niet bij de medewerker.

Is het eerlijk om in dit scenario chagrijnig te zijn? Natuurlijk. Is het eerlijk om een verhoging aan te vragen? Misschien, misschien niet - misschien wordt de werknemer zelfs te veel betaald. Aangezien de werkgever en de werknemer duidelijk verschillende verwachtingen hebben over de omvang van de werknemer, is het voor een derde partij niet mogelijk om te zeggen.

Cultuur doet er natuurlijk ook toe - ik ben in Zweden FWIW (meestal relatief vlakke hiërarchieën en mondige werknemers/zwakke leidinggevenden).

Dus, ik heb de twee oudste en meest ervaren ontwikkelaars die ik in mijn team heb gebeld en heb het project aan hen gepresenteerd. Terwijl één van hen er echt in geïnteresseerd leek, was de andere een beetje… chagrijnig, om het zacht uit te drukken.

Je hebt de keuze gemaakt om de twee meest ervaren ontwikkelaars te vragen om de uitdaging aan te gaan. Als degene die de opdracht afwees dit had gedaan zonder chagrijnig te zijn, of een goed doordacht argument had aangedragen, zou je dan gewoon naar kandidaat #3 zijn gegaan? Zo ja, doe dat dan.

Als er nog steeds een plaats is voor de ontwikkelaar die de kans afwees, wijs hem dan die taak toe.

Onthoud dat je hem niet vraagt om een beetje buiten zijn comfortzone te gaan. Je vraagt hen om wat wiskunde te leren die ze misschien niet nodig vinden buiten dit project. De beste kandidaat is misschien niet de twee meest senior ontwikkelaars geweest. Het kan de meest junior ontwikkelaar zijn geweest, of zelfs de stagiair (hoewel ik niet van plan ben om een stagiair te vragen om verantwoordelijk te zijn voor een lange termijn kritische vaardigheid).

Laat me hier de advocaat van de duivel spelen:

• Uw bedrijf heeft een werk aangenomen waarin ze absoluut geen competenties hebben.
• Dit werk bevindt zich op een gebied dat heel anders is dan de meeste andere gebieden in de softwareontwikkeling. Dit is niet je normale “leer nieuwe programmeertaal”, dit is zwaargewicht wiskunde waar zelfs de meeste fulltime wiskundigen bang voor zijn.
• Je bedrijf weigert een nieuw persoon aan te nemen om te leiden, in plaats daarvan gelooft het dat theoretische trainingen en cursussen geen ervaring kunnen goedmaken.
• Ze hebben een hopeloze optimist en enthousiasteling aan het roer gezet (jij)
• De leider (jij) kan niet eens erkennen dat andere mensen misschien andere doelen hebben dan hij.

Nu, ik zeg niet dat dit een recept voor een ramp is. Maar veel rampen hebben dit recept gevolgd.

Deelnemen aan je speerpuntteam is niet allemaal rozengeur en maneschijn zoals je het omschrijft. Je zegt dat het gaat om leren, maar er is niemand met ervaring om het je te leren. Dat betekent dat je op je eigen fouten zult leren en in veel gevallen zul je verkeerd leren. In het beste geval zul je grote stukken van je nieuwe kennis moeten afleren. In het ergste geval zul je nooit weten wat je fout hebt.

Er is een grote kans dat je zult falen. Er zijn veel manieren waarop het kan mislukken, ik zet in op ernstige tijdsoverschrijdingen (dus kosten), zodat uw bedrijf een verlies zal maken. Het ergste geval is dat de klant zich beroept op boeteclausules en uw bedrijf zal veel meer verliezen dan alleen uw tijd en salarissen, dus devs kan ontslagen worden met reputatie besmeurd. Denk je niet dat dat risico de moeite waard is om te compenseren?

Ik heb het meest pessimistische beeld geschilderd, maar ik denk dat het nodig is om je optimisme tegen te gaan.

Laten we teruggaan naar het laatste punt van mijn bulletlist, dat is het enige wat je persoonlijk verkeerd hebt gedaan. Je hebt de beslissing genomen over wat andere devs in je handen willen hebben. Je lijkt je niet te realiseren dat wat jij als opwindend ziet, andere mensen misschien als intimiderend of alleen maar saai zien. Je ziet het als een upgrade, terwijl je weigert te accepteren dat anderen het als een degradatie zien. Of gewoon niet goed passen bij hun balans tussen werk en privé. Een andere invalshoek is dat je het ziet als binnen het bereik van “ontwikkelaar” positie. Het probleem is dat het niets anders is dan een mening. Een tegengestelde mening, dat het een gloednieuwe baan is, is net zo geldig als de jouwe. Je moet verwachten dat andere mensen je mening niet delen. Het was OK om terloops te vragen of iemand de nieuwe baan wil. Maar je had evenzeer “nee” als “ja” moeten verwachten.

Je moet ook in gedachten houden dat een baan altijd een contract is. En zoals elk contract, zijn er twee kanten nodig om het te veranderen. De functiebeschrijving maakt deel uit van het contract. Je kunt de functieomschrijving niet eenzijdig wijzigen, net zoals de werknemer zijn salaris niet eenzijdig kan wijzigen. Ja, er wordt vaak van een werknemer verwacht dat hij zich verbetert, maar dat betekent niet dat hij nieuwe verantwoordelijkheden op zich moet nemen, maar dat hij concurrerend moet blijven bij de uitvoering van de taken waarvoor hij is aangenomen.

Het contract kan op elk moment worden gewijzigd wanneer beide partijen instemmen met de wijziging. ** Het is net zo goed voor hem om opslag te vragen als voor jou om een baanverandering te vragen.** Maar iedereen moet bereid zijn om met het antwoord te leven.

IMHO zijn vraag was niet echt, hij wil de nieuwe baan gewoon niet. En hij heeft de rollen omgedraaid, dus jij bent het die eigenlijk “nee” moet zeggen. Er is niets voor jou om mee om te gaan, behalve het veranderen van je houding ten opzichte van je team en het delen van je overtuigingen en levensdoelen.

Ik denk dat het eerlijk is om te vragen om een verhoging na toewijzing aan gespecialiseerd werk dat een specifieke set van vaardigheden vereist die niet gebruikelijk zijn op de werkplek. Het klinkt alsof dit een project van het type ‘big data’ is en die vaardigheden zijn zeer gewild en betalen veel beter dan het gemiddelde salaris van een ontwikkelaar. Dit geldt ook alleen als het een doorlopende taak betreft.

Verhogingen voor specialistische vaardigheden voor een eenmalig project van 3-6 maanden zijn niet gepast (een bonus zou kunnen zijn). Verhogingen voor het nieuwe vaste Big Data team wel. Als leider zou je de salarissen kunnen onderzoeken voor mensen met de vaardigheden die je aan je team vraagt en kijken of het gepast is om salarisverhogingen te bespreken met het management nadat je team zich heeft bewezen.

Echter, normaal gesproken zou dat verzoek voor het hele team zijn en zou het over het algemeen gebeuren nadat ze de vaardigheden hebben verworven, hoewel het op een bepaalde datum later kan worden beloofd als de vaardigheden zijn verworven.

De manier waarop hij te werk is gegaan door te weigeren om gekwalificeerd te worden zonder een verhoging wordt over het algemeen afgekeurd. Persoonlijk zou ik, aangezien je andere medewerkers hebt om uit te kiezen, door gaan naar de volgende persoon die geïnteresseerd zou kunnen zijn. Ik zou waarschijnlijk het team hebben ondervraagd voordat ik iemand vroeg om te zien wie er geïnteresseerd was in het verkrijgen van deze vaardigheden en vervolgens mijn keuze hebben gemaakt uit de vrijwilligers nadat ieder de kans had gehad om zijn zaak te bepleiten waarom hij zou moeten worden gekozen. Er zijn niet zo veel mensen die echt geïnteresseerd zijn in de hogere wiskundige vaardigheden, een meer junior persoon zou al enige studie op dit gebied kunnen hebben gedaan, omdat het deel uitmaakte van zijn interesses.

Grumpy heeft dit zeer slecht afgehandeld. Echter…

Als iemand die decennia lang een ontwikkelaar was, en nu een wiskunde-onderzoeker is die veel voorspellende analytics doet, zie ik een soort van Grumpy’s punt. Terwijl software ontwikkelaars bereid moeten zijn om stukjes en beetjes te leren van een grote verscheidenheid aan disciplines om hun werk te kunnen doen, is er een significant verschil tussen een ontwikkelaar en een onderzoeker, net zoals er een verschil is tussen een manager en een ontwikkelaar. Het is niet zo dat hij weigert om een nieuwe programmeertaal te leren of om uit te vinden hoe hij met een of andere rare hardware moet omgaan; het is meer dat hij weigert om grafisch ontwerp te doen of een team te managen of een vliegtuig te besturen.

Grumpy is misschien wel wiskunde-fobisch. Maar het is ook mogelijk dat hij genoeg weet over statistiek en datamining om te vermoeden dat het een moeilijke, duistere slogan zal zijn. Op dit specifieke gebied van wiskunde is het heel gemakkelijk om sommige technieken te leren, maar het is ook gemakkelijk om ze toe te passen in de verkeerde situaties! Een middelbare scholier zou kunnen leren hoe ARIMA te doen, maar weten wanneer het geldig is en hoe de juiste parameters te kiezen zijn meer op het niveau van de afgestudeerde student. Veel wiskundigen houden niet van statistiek, niet omdat het moeilijker is dan andere vakgebieden, maar omdat het meer… vals is.

Net als jij, spring ik op de kans om nieuwe wiskunde te leren, en ik hou van mijn werk. Maar ik kan zien hoe Grumpy het gevoel heeft dat hij gevraagd wordt iets te doen wat te ver buiten de rol van een ontwikkelaar ligt. Zoals ik al zei, hij behandelde het zeer slecht, en ik verontschuldig me daar niet voor. Maar hij kan enige rechtvaardiging hebben voor de manier waarop hij voelt.

Sprekend als een wiskunde-gedraaide software ontwikkelaar sympathiseer ik met Grumpy: d.w.z. ik geef nu de voorkeur aan software ontwikkeling (en ik denk dat ik nu beter ben in software ontwikkeling dan in wiskunde).

Aan de andere kant als ik in de plaats van Grumpy zou zijn en dat tegen u zou willen zeggen, zou ik - en ik zou zonder de kwestie te verwarren door het noemen van het salaris - de kwestie bespreken.

Het feit dat Grumpy salaris noemde kan betekenen dat Grumpy chagrijnig is over salaris, en dit project is slechts een trigger of excuus voor het vragen van opslag.

Dus mijn advies zou zijn om te proberen de kwesties te scheiden, zelfs als Grumpy ze niet zou scheiden. Vraag: “Is Grumpy blij met zijn huidige salaris? Vraagt hij om loonsverhoging ongeacht dit nieuwe project?” Gezien het feit dat hij een van de twee oudste en meest ervaren ontwikkelaars is, moet je hem eerst een onvoorwaardelijke loonsverhoging aanbieden, en dan vragen of hij bereid is om dit nieuwe ding te doen?

En/of kun je hem geruststellen over de aard van de nieuwe verantwoordelijkheden? Als ik hem was, zou ik me misschien zorgen maken over een mislukking. Het verhoogde salaris zou ‘gevaarsgeld’ kunnen zijn om mij te compenseren voor verhoogd risico of stress of onbetaalde overuren. Zal het bedrijf bijvoorbeeld voldoende hulp bieden (bijvoorbeeld een domeinexpert, d.w.z. een wiskundementor) om zijn succes te garanderen?

U zegt dat dit “onderzoek op academisch niveau” is, maar ook “in principe software R&D” die elkaar misschien uitsluiten/tegenspreekt. Blijkbaar bent u enthousiaster over academisch onderzoek dan hij?

Is het mogelijk dat de ontwikkelaar het gevoel heeft dat hij niet genoeg betaald krijgt voor het werk dat hij nu doet? Meestal als mensen zeggen “Ik krijg niet genoeg betaald om dit te doen,” bedoelen ze dat ze het gevoel hebben dat ze ondergewaardeerd zijn in het algemeen, en dat het een vluchtrisico kan zijn.

Als je in een positie bent om dat aan te passen, en hij is ondergewaardeerd (of niet grof overgewaardeerd), dan maakt hij misschien een goed punt, en kun je zijn bedrijfsdoelen aanpassen om te reflecteren dat als hij dit onderzoek doet en dit project succesvol ontwikkelt, hij dit jaar een verhoging krijgt die beter zal zijn dan een verhoging van de kosten van levensonderhoud. Stel vooraf een percentage voor en documenteer het. Of uw bedrijf kan aanduidingen hebben zoals ‘de verwachtingen overtreffen’ die automatisch leiden tot een grote verhoging, dus vertel hem dat hij ‘de verwachtingen zal overtreffen’ en dienovereenkomstig zal worden gecompenseerd. Geld kan een grote motivator zijn, en van knorren gelukkige kampeerders maken.

Of hij kan zeggen dat hij zichzelf niet echt ziet als een wiskunde-onderzoeker. Als dat het geval is, vraag dan iemand anders om het te doen en presenteer het aan het team. Als het echt alleen maar onderzoek is, kun je misschien je productmanager of bedrijfsanalist vragen om de informatie te bestuderen en deze in verband te brengen met het dev-team in de vereisten.

Hoewel ik echt, echt geen fan ben van de bewoordingen van deze man - vooral in de softwareontwikkeling worden we behoorlijk betaald om te doen wat we doen, en wat we doen houdt vaak in dat we onderzoeken hoe je het ding gaat doen waarvan je zei dat je het ging doen - denk ik dat er een kern van waarheid zit in waar hij het over heeft. Nee, je moet hem geen opslag geven. Er is echter een punt waarop het vragen van een persoon die niet werkt met matige dingen om matige dingen te doen een slecht moment gaat zijn voor zowel jou als hen.

Ik ben eigenlijk in een semi-achtige situatie terechtgekomen in mijn carrière als ontwikkelaar. Ik bedoel, in sommige opzichten is het helemaal niet hetzelfde, maar toch… zoals gezegd, ben ik een ontwikkelaar. Ik ontwikkel dingen. Als je wat zakelijke logica wilt implementeren en widgets op een webpagina wilt krijgen om rond te springen en dingen te doen, dan ben ik je mannetje. Ik heb gewerkt aan de achterkant en de voorkant, heb middle-tier webservices gebouwd, en heb nieuwe talen en frameworks on the fly opgepikt wanneer ik dat nodig had. Wat ik niet doe - ik moet zeggen, wat ik niet doe wel - is ontwerpen. Als je me vraagt om een webpagina te ontwerpen, zal ik het doen, begrijp me niet verkeerd, maar ik zal het doen om je te vertellen dat ik hier geen training of expertise in heb en dat je de resultaten misschien niet leuk vindt. Uiteindelijk denk ik dat je beter een echte ontwerper kunt inhuren en mij dan gebruiken om het ontwerp van die persoon te nemen en te implementeren.

Dus wat ik zou zeggen om hier te doen is om deze man te nemen alsof hij je dit ding vertelt in plaats van “me meer te betalen”, want in zekere zin is dat soort is wat hij aan het doen is. Het gaat er hier niet zozeer om dat softwareontwikkelaars X betaald krijgen en dat je bij wiskunde X + 10% krijgt, maar dat sommige softwareontwikkeling niet echt wiskunde vereist en dus betekent het vragen van mensen om er veel van te doen dat je met minder dan stellaire resultaten komt te zitten. Afhankelijk van de situatie zou ik kunnen aanraden:

• Door de skillsets van je andere ontwikkelaars te bekijken en te zien of iemand anders in je team een meer matige achtergrond heeft, of bereid is te leren wat je moet leren. Je zou ze zelfs kunnen verkopen op het idee dat dit een nieuwe tool is die ze kunnen leren en meenemen naar toekomstige optredens (zie hieronder!). Het grootste nadeel hier is dat naast de extra tijd die je kwijt bent aan het opvoeren van dingen (en in het proces, mogelijk het leren van nieuwe architectuur en raamwerken), dat bepaalde dev ook zal worden vertraagd door het moeten leren en begrijpen van de wiskunde die je wilt implementeren.

• Het binnenhalen van een analist om de vergelijkingen uit te zoeken en dan je bestaande devs de vergelijkingen te laten implementeren in code, net zoals ze dat zouden doen met elk ander stuk van de business logica. Dit heeft als nadeel dat de persoon die de wiskunde kent uiteindelijk niet de wiskunde in je systeem schrijft, maar dat kan vrij eenvoudig opgelost worden door de nadruk te leggen op testgedreven ontwikkeling (wat je al doet, toch?). Deze methode heeft ook het voordeel dat, als je bijvoorbeeld in de financiële sector werkt, je een van de cijfers uit hun afdeling kunt halen: de kans is groot dat ze dit spul beter kennen dan praktisch elke s-dev die je van de straat kunt halen, want dat is hun werk.

• Het binnenhalen van een externe consultant om niets anders aan te pakken dan het matige deel van de code, en dan gewoon dat deel op te sluiten om nooit meer aangeraakt te worden. Dit is ook problematisch om een heleboel redenen - eerst en vooral, de dag dat ik code vind die niet opnieuw hoeft te worden bewerkt is de dag dat ik mezelf voorstel aan de meest psychische ontwikkelaar ooit - maar afhankelijk van wat je probeert te doen, kan dit de manier zijn om het te doen. Die andere man kost misschien ook iets meer dan wat je je huidige ontwikkelaars betaalt, maar, nou ja, het is een gespecialiseerd subveld.

Zoals ik al zei, ik ben niet echt een grote fan van de formulering hier, en misschien betekent dat op zich al dat je een sit-down gesprek moet hebben met de persoon die dit zegt (ik zou, terzijde, een beetje op zijn hoede zijn voor het niet naleven van de Bus Factor en het is misschien tijd om wat van de code van deze man door te lopen, niet als straf maar omdat IME-mensen die denken in termen van beloningscijfers in deze industrie ook denken in termen van het doen van dingen om zichzelf onvervangbaar te maken). Ik denk niet dat hij per se verkeerd is.

U zegt dat chagrijnig een van de oudste ontwikkelaars is. Ik vraag me af hoe oud? Jaren geleden had ik iemand voor me werken die midden in de 50 was, hij was een bekwame ontwikkelaar, hij was gelukkig in zijn werk, maar hij weigerde elke extra verantwoordelijkheid op zich te nemen. Het bleek dat er een geschiedenis was, hij had in het verleden een loopbaanonderbreking moeten nemen vanwege stress, hij kende zijn grenzen, en hij wilde die niet overstijgen. Respecteer zijn oordeel en gebruik hem voor de dingen die hij goed doet.

Ik zou zeggen dat het antwoord afhangt van hoe accuraat de beoordeling van de ontwikkelaar is.

Als zijn functieomschrijving daadwerkelijk het doen van dit soort werk omvat, en zijn beloning daarvoor geschikt is, dan is zijn claim onnauwkeurig.

Aan de andere kant komen zijn functieomschrijving en/of loonniveau niet overeen met het nieuwe type werk, dan moeten ze worden aangepast om dat nauwkeurig weer te geven.

In het algemeen, zelfs als een bedrijf een werknemer opleidt tot een nieuwe functieomschrijving, betekent dat niet dat het bedrijf dan de functieomschrijving en het loonniveau van die werknemer niet moet aanpassen aan de nieuwe functieomschrijving. Sommige bedrijven proberen dat misschien wel te doen, maar dat is niet gepast en is geneigd het moreel te verlagen en uiteindelijk werknemers te verliezen.

Uit uw commentaar klinkt het alsof u het niet zeker weet. In plaats van (zoals sommige andere antwoorden hier hebben gesuggereerd) zijn uitspraak te doen in een weigering of slechte houding, stel ik voor het te behandelen als een volwassen respectabele suggestie, en te reageren op een volwassen professionele manier, door het erkennen van de suggestie en het raadplegen van mensen die zouden weten wat geschikt is voor dat soort werk, en dan terug te keren naar hem over wat je te weten bent gekomen over dat soort werk.

Werknemer geeft aan dat hij geen werk wil doen waarvoor hij niet is ingehuurd, en zorgt voor een compromis: meer geld en hij doet het werk toch.

Je moet de meer geld optie afwijzen. Als hij het werk niet wil doen, zal hij waarschijnlijk ongelukkig zijn om het werk te doen, ondanks het extra geld, en ongelukkig zijn kan besmettelijk zijn. Bovendien schept het een slecht precedent voor mensen die het werk willen doen, maar nu weten dat ze om opslag kunnen vragen voordat ze iets anders leren.

Behandel dit als elke andere werknemer die geen werk wil doen waarvoor hij niet is aangenomen. En hoe je daar mee omgaat hangt af van veel andere details, maar in dit specifieke geval bedank je hem voor de tijd en vraag je om een andere vrijwilliger , want dit is het soort project waar je aan wilt werken met mensen die er aan willen werken.

Ik denk dat een paar kleine punten met betrekking tot de vraag niet zijn gesteld/beantwoord door andere posters (vanaf deze posting):

• Wat is de titel van de oude functie?
• Wat wordt er betaald voor die functie? (Markttarieven)
• Wat is de titel van de nieuwe functie?
• Wat wordt er voor betaald? (Markttarieven)
• Wat is het verschil in salaris tussen “Senior Developer” en “That Title”

• Is het de tijd/inspanning waard voor hem om het salarisverschil te krijgen?

• Wat is de titel van de huidige positie? Verschillende titels krijgen verschillende salarissen… er is een verschil tussen een Developer en een Engineer… een Senior Developer en Senior Engineer. Hoe heet de nieuwe titel? Mathmatics Developer? Researcher Developer? Senior Research Engineer?

Wat krijgt iemand met die titel betaald, in markttarieven? Er zijn sommige functies die “moeilijker” zijn, maar minder betaald worden… Denk onderzoeker aan universiteiten… veel mensen proberen de posities te krijgen, dus de vraag verlaagt de markttarieven.

Wat is het verschil tussen de huidige “Titel” en “Nieuwe Titel” in de markt? Als het $1000/jaar is… dat is een ander gesprek dan het is $75000 per jaar…

Wat betekent… is het de moeite waard voor “Grumpy Dev” om “Math Research” te leren? Ja, het is waar dat een deel van een Developers Life bestaat uit het leren van nieuwe dingen… het is ook het leren van nieuwe dingen die waardevol zijn. Hetzij in monetaire termen (loonsverhoging) of in andere termen (loopbaanontwikkeling, nieuwe kansen, nieuwe technologieën)…

Sir Grumpy, heeft mij duidelijk gemaakt dat zijn belangrijkste prioriteit geld is. Als hij een Front End Developer wil zijn en je probeert hem een Applied Science ontwikkelaar te maken… is het voor hem misschien niet de moeite waard om over te stappen - gezien dezelfde loonschaal. De enige manier voor hem om het de moeite waard te vinden zou $$$ zijn. Of dat, of hij is niet geïnteresseerd en geeft de verantwoordelijkheid aan u door. Lijnen de marktprijzen overeen met zijn verwachtingen? Uw verwachtingen?

Ik heb het gevoel dat er al een antwoord op je probleem is gegeven - dat als je een persoon in je team hebt die niet geïnteresseerd is in een project dat een nieuwe richting uitgaat, maar je hebt iemand nodig met ervaring om te helpen, dan ga je naar de persoon met de eerstvolgende ervaring na hem, of misschien zelfs overwegen om te kijken naar hun specifieke vaardigheden (heeft iemand in je team een wiskundige achtergrond?) en laat hem doorgaan met het onderhoud dat je team gewoonlijk doet.

Maar om je vraag te beantwoorden - ‘is dit een eerlijk verzoek? Het is een eerlijk verzoek van hem om het te _vragen, maar van u wordt helemaal niet verlangd dat u verder gaat dan dat.

Als u uw onderzoek heeft gedaan en er zeker van bent dat het loon voor een persoon met ervaring in zijn functie voldoet aan de marktwaarde, dan is er weinig ruimte om te beargumenteren dat een permanente verhoging in orde is.

Overweeg ook de volledige implicatie van zijn titel - een softwareontwikkelaar is verwacht om wat onderzoek en ontwikkeling uit te voeren wanneer het relevant is voor zijn functie. Tot nu toe is dat niet het geval geweest. Maar aangezien je team de opdracht krijgt om dit nieuwe type programma te implementeren, maakt het nu deel uit van het werk, en het weigeren om die taken uit te voeren betekent het weigeren van een deel van zijn werk.

Vanaf nu is dat geen verdomd probleem - je hebt andere ontwikkelaars die je in plaats daarvan op deze taak kunt zetten. Maar als je team nog steeds ontwikkelaars nodig heeft die enig begrip hebben voor dit soort wiskunde, kan deze medewerker een verplichting worden als hij niet bereid is om te leren. Houd dat dus in gedachten.

Merk op dat of het wel of niet binnen zijn functieomschrijving valt ook afhangt van zijn contract - veel contracten hebben een clausule voor 'alle andere taken die nodig zijn om je taak uit te voeren’, die extra training zoals deze omvat.

Wat uw teamgenoot vraagt is niet eerlijk – helemaal niet.

Het leren van nieuwe vaardigheden maakt deel uit van elke baan, vooral vandaag de dag in de tech industrie.

Uw bedrijf biedt aan om te betalen voor training, dus het is niet alsof uw teamgenoot in het diepe wordt gegooid.

De meeste mensen zouden het op prijs stellen als ze de kans kregen om hun vaardigheden uit te breiden en te verbeteren tegen weinig of geen kosten, en om in wezen te kunnen leren op het werk.

Het antwoord van uw teamgenoot is eerlijk gezegd insubordinaat en giftig. Je hebt zo iemand niet nodig in je team.

Deze kwestie moet worden geëscaleerd naar een manager of iemand die verantwoordelijk is voor het evalueren van de prestaties van je teamgenoot.