Nou, de oplossing is hier eenvoudig. Bedank chagrijnig voor zijn eerlijkheid, zet hem weer op normale taken en haal 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 er het meest in geïnteresseerd zijn. Chagrijnig een salarisverhoging geven zal hem niet enthousiaster maken over het project, dus het is niet in jouw belang of dat van het project om hem daar toch te hebben.

Verderop in de weg zul je moeten gaan enkele moeilijke keuzes. Ik zou de houding van deze ontwikkelaar in de gaten houden en hoe dit het team beïnvloedt. Het kan zijn dat u begint met kanker. Als hij echt van zijn baan 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 ok zijn als hij uw systemen kent, zijn werk goed doet en geen problemen veroorzaakt. Als dat echter niet deze persoon is, zult u er uiteindelijk mee te maken krijgen.

Dit is iets dat voorkomen had moeten worden , niet achteraf behandeld. Het spijt me, maar als je (zoals het lijkt, zonder enige voorafgaande waarschuwing) plotseling de richting van de persoonlijke ontwikkeling van de werknemers verandert, en verrast wordt wanneer dit niet dezelfde richting is als de ontwikkelaar, is het probleem niet met de werknemer.

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

Cultuur is natuurlijk ook belangrijk - ik ben in Zweden FWIW (meestal relatief vlakke hiërarchieën en mondige werknemers / zwakke managers).

Dus ik belde de twee oudste en meest ervaren ontwikkelaars die ik in mijn team heb en presenteerde het project aan hen. Terwijl een van hen er echt in geïnteresseerd leek, was de andere een beetje ... chagrijnig, op zijn zachtst gezegd.

Je hebt een keuze gemaakt om de twee meest ervaren ontwikkelaars te vragen op de uitdaging. Als degene die de taak had afgewezen dit had gedaan zonder chagrijnig te zijn, of een goed doordacht argument had aangedragen, zou je dan gewoon tot kandidaat # 3 zijn overgegaan? Zo ja, doe dat dan.

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

Onthoud dat je ze niet vraagt ​​om een ​​beetje buiten hun comfortzone te gaan. Je vraagt ​​ze om wat wiskunde te leren die ze misschien niet nodig achten buiten dit project. De beste kandidaat waren misschien niet de twee meest ervaren ontwikkelaars. Het kan de jongste ontwikkelaar zijn geweest, of zelfs de stagiair (hoewel ik niet van plan was een stagiair te vragen verantwoordelijk te zijn voor een kritische vaardigheid op de lange termijn).

Laat me hier de advocaat van de duivel spelen:

• Uw bedrijf heeft een werk opgepakt waar ze absoluut geen competenties in hebben.
• Dit werk bevindt zich op een gebied dat heel anders dan de meeste andere velden in softwareontwikkeling. Dit is niet uw normale "nieuwe programmeertaal leren", dit is zware wiskunde waar zelfs de meeste fulltime wiskundigen bang voor zijn.
• Uw bedrijf weigert een nieuw persoon aan te nemen om leiding te geven, in plaats daarvan gelooft het dat theoretische trainingen en cursussen kunnen geen ervaring goedmaken.
• Ze hebben een hopeloze optimist en enthousiast aan het roer gezet (jij)
• De leider (jij) kan niet eens erkennen dat andere mensen hebben andere doelen dan hij.

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

Deelnemen aan je leidende team is niet alleen rozen, zoals je het beschrijft. U zegt dat het over leren gaat, maar er is niemand met ervaring om u les te geven. Dat betekent dat je van je eigen fouten leert en in veel gevallen dat je het verkeerd leert. In het beste geval zul je grote delen van je nieuwe kennis moeten afleren. In het ergste geval zul je nooit weten wat je fout hebt.

De kans is zeer groot dat je faalt. Er zijn veel manieren waarop het kan mislukken, ik wed op een ernstige tijdoverschrijding (en dus kosten) (een paar honderd %%), zodat uw bedrijf verlies zal lijden. Het ergste geval is dat de klant boeteclausules zal inroepen en uw bedrijf zal veel meer verliezen dan alleen uw tijd en salarissen, dus ontwikkelaars kunnen worden ontslagen met een besmette reputatie. Vind je niet dat risico compensatie waard is?

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

Laten we teruggaan naar het laatste punt van mijn lijst met opsommingstekens, dat is het enige dat je persoonlijk verkeerd hebt gedaan. Je hebt de beslissing genomen over wat andere ontwikkelaars in handen willen hebben. U lijkt niet te beseffen dat wat u als opwindend beschouwt, andere mensen misschien als intimiderend of alleen maar saai ervaren. Je ziet het als een upgrade terwijl je weigert te accepteren dat anderen het als een downgrade zien. Of gewoon niet goed bij hun werk-privébalans. Een andere invalshoek is dat je het ziet als binnen het bereik van de "ontwikkelaar" -positie. Het probleem is dat het niets anders is dan een mening. Een tegenovergestelde mening, dat het een geheel nieuwe baan is, is net zo geldig als die van jou. Je moet van andere mensen verwachten dat ze jouw mening niet delen. Het was oké om terloops te vragen of iemand de nieuwe baan wil. Maar je had zowel "nee" als "ja" moeten verwachten.

Je moet er ook rekening mee houden dat een baan altijd een contract is. En zoals bij elk contract, zijn er twee kanten nodig om het te wijzigen. 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 doorgaans van een werknemer verwacht dat hij verbetert, maar dat betekent niet dat hij nieuwe verantwoordelijkheden moet opnemen, maar dat hij competitief moet blijven bij het uitvoeren van de taken waarvoor hij is aangenomen.

Het contract kan op elk moment worden gewijzigd wanneer beide partijen akkoord gaan met de verandering. Het is net zo goed voor hem om loonsverhoging te vragen als voor jou om een ​​baanwissel aan te vragen. Maar iedereen moet bereid zijn om met het antwoord te leven.

IMHO zijn vraag was geen echte, hij wil gewoon niet de nieuwe baan. En draaide de rollen om, zodat jij eigenlijk "nee" moet zeggen. U hoeft hier niets aan te doen, behalve het veranderen van uw houding ten opzichte van uw team door uw overtuigingen en levensdoelen te delen.

Ik denk dat het eerlijk is om loonsverhoging te vragen nadat ik ben toegewezen aan specialistisch werk dat een specifieke reeks vaardigheden vereist die niet gebruikelijk zijn op de werkplek. Het klinkt alsof dit een big data-project is en er is veel vraag naar die vaardigheden en ze betalen veel beter dan het gemiddelde salaris van een ontwikkelaar. Dit geldt alleen als de taak een lopende taak is.

Verhogingen voor specialistische vaardigheden voor een eenmalig project van drie tot zes maanden zijn niet geschikt (een bonus kan dat wel zijn). Verhogingen voor het nieuwe permanente Big Data-team zijn. Als hoofdleider zou u de salarissen kunnen onderzoeken van mensen met de vaardigheden die u uw team vraagt, en kijken of het misschien gepast is om salarisverhogingen met het management te bespreken nadat uw team zichzelf heeft bewezen.

, normaal gesproken zou dat verzoek voor het hele team zijn en meestal plaatsvinden nadat ze de vaardigheid hebben verworven, hoewel het op een bepaalde datum later zou kunnen worden beloofd als de vaardigheden werden verworven.

De manier waarop hij het deed door te weigeren zich te kwalificeren zonder een verhoging, wordt over het algemeen afgekeurd. Persoonlijk, aangezien u ander personeel heeft om uit te kiezen, zou ik doorgaan naar de volgende persoon die mogelijk geïnteresseerd is. Ik zou waarschijnlijk het team hebben ondervraagd voordat ik iemand had gevraagd om te zien wie geïnteresseerd was in het verwerven van deze vaardigheden en vervolgens mijn keuze had gemaakt uit de vrijwilligers nadat iedereen de kans had gehad om zijn argument te verdedigen waarom hij gekozen moest worden. Er zijn niet veel mensen die echt geïnteresseerd zijn in hogere wiskundige vaardigheden, een jongere persoon heeft misschien al wat studie op dit gebied gedaan omdat het deel uitmaakte van zijn interesses.

Grumpy heeft dit erg slecht afgehandeld. Maar ...

Als iemand die decennia lang ontwikkelaar was en nu wiskundig onderzoeker is die veel voorspellende analyses doet, begrijp ik het punt van Grumpy wel. Hoewel softwareontwikkelaars bereid moeten zijn om stukjes en beetjes uit een breed scala aan disciplines te leren om hun werk te kunnen doen, is er een aanzienlijk verschil tussen een ontwikkelaar en een onderzoeker, net zoals tussen een manager en een ontwikkelaar. Dit is niet alsof hij weigert een nieuwe programmeertaal te leren of uit te zoeken hoe hij met rare hardware moet communiceren; het is meer alsof hij weigert grafisch ontwerp te doen, een team te leiden of een vliegtuig te besturen.

Chagrijnig is misschien fobisch voor wiskunde. Maar het is ook mogelijk dat hij genoeg weet van statistieken en datamining om te vermoeden dat het een moeilijke, duistere plooi zal worden. Op dit specifieke gebied van wiskunde is het heel gemakkelijk om enkele technieken te leren, maar het is ook gemakkelijk om ze in de verkeerde situaties toe te passen! Een middelbare scholier zou kunnen leren ARIMA te doen, maar weten wanneer het geldig is en hoe de juiste parameters te kiezen, ligt meer op het niveau van de afgestudeerde student. Veel wiskundigen houden niet van statistiek, niet omdat het moeilijker is dan andere velden, maar omdat het meer ... onhandig is.

Net als jij grijp ik de kans om leer nieuwe wiskunde, en ik hou van mijn werk. Maar ik kan zien hoe Grumpy het gevoel zou kunnen hebben dat hem wordt gevraagd iets te doen dat gewoon te ver buiten de rol van ontwikkelaar valt. Zoals ik al zei, hij behandelde het erg slecht, en dat is geen excuus. Maar hij kan een rechtvaardiging hebben voor de manier waarop hij voelt .

Als wiskundige die softwareontwikkelaar is geworden, sympathiseer ik met Grumpy: ik geef nu de voorkeur aan softwareontwikkeling (en ik denk dat ik nu beter ben in softwareontwikkeling dan in wiskunde).

Aan de andere kant als ik in de plaats van Grumpy was en dat tegen je wilde zeggen, zou ik dat doen - en ik zou het doen zonder de kwestie te verwarren door salaris te noemen.

Het feit dat Grumpy het salaris noemde, kan betekenen dat Grumpy chagrijnig is over salaris, en dit project is slechts een trigger of excuus om een ​​loonsverhoging te vragen.

Dus mijn advies zou zijn om te proberen de problemen te scheiden, zelfs als Grumpy ze niet uit elkaar heeft gehaald. Vraag: "Is Grumpy blij met zijn huidige salaris? Vraagt ​​hij om loonsverhoging ongeacht dit nieuwe project?" Aangezien hij een van de twee oudste en meest ervaren ontwikkelaars is, moet je hem eerst een onvoorwaardelijke salarisverhoging aanbieden en dan vragen of hij bereid is om dit nieuwe te doen?

En / of kunt u hem geruststellen over de aard van de nieuwe verantwoordelijkheden? Als ik hem was, zou ik me zorgen maken dat ik zou falen. Het verhoogde salaris kan 'gevarengeld' zijn om mij te compenseren voor verhoogd risico of stress of onbetaalde overuren. Zal het bedrijf bijvoorbeeld voldoende hulp bieden (bijvoorbeeld een domeinexpert, dat wil zeggen een wiskunde-mentor) om zijn succes te garanderen?

U zegt dat dit "onderzoek op academisch niveau" is, maar ook "in wezen software R&D" die elkaar wederzijds uitsluiten / tegenstrijdig kunnen zijn. Blijkbaar houdt u meer van academisch onderzoek dan hij?

Is het mogelijk dat de ontwikkelaar vindt dat hij niet genoeg wordt betaald voor het werk dat hij nu doet? Als mensen zeggen: "Ik krijg hiervoor niet genoeg betaald", bedoelen ze dat ze het gevoel hebben dat ze over het algemeen ondergewaardeerd zijn en een vluchtrisico kunnen vormen.

Als u in een positie bent om dat aan te passen, en hij wordt ondergewaardeerd (of niet erg overgewaardeerd), dan maakt hij misschien een goed punt en kunt u zijn bedrijfsdoelen aanpassen om dat weer te geven als hij dit onderzoek doet en dit project met succes ontwikkelt, zal hij dit jaar een loonsverhoging krijgen die beter is dan hogere kosten van levensonderhoud. Stel vooraf een percentage voor en documenteer dit. Of uw bedrijf heeft aanduidingen zoals 'verwachtingen overtreffen' die automatisch resulteren in een grote verhoging, dus vertel hem dat hij 'verwachtingen overtreft' en dienovereenkomstig wordt gecompenseerd. Geld kan een geweldige motivator zijn en van mopperen blije kampeerders maken.

Of misschien zegt hij dat hij zichzelf niet echt als wiskundig onderzoeker ziet. Als dat het geval is, vraag dan iemand anders om het te doen en presenteer het aan het team. Als het eigenlijk alleen maar onderzoek is, kunt u uw productmanager of bedrijfsanalist misschien vragen om de informatie te bestuderen en deze in de vereisten te relateren aan het ontwikkelteam.

Hoewel ik echt geen fan ben van de bewoordingen van deze man - vooral bij softwareontwikkeling krijgen we een behoorlijk bedrag om te doen wat we doen, en wat we doen, is vaak onderzoeken om erachter te komen hoe het met je gaat om te doen wat u zei dat u ging doen - ik denk 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 met wiskundige dingen werkt, om wiskundige dingen te doen, een slechte tijd zal zijn voor zowel jou als voor hen.

Ik ben eigenlijk een semi- soortgelijke situatie in mijn carrière als ontwikkelaar. Ik bedoel, in sommige opzichten is het helemaal niet hetzelfde, maar toch ... zoals opgemerkt, ben ik een ontwikkelaar. Ik ontwikkel dingen. Als je wat bedrijfslogica wilt implementeren en widgets op een webpagina wilt krijgen om rond te springen en dingen te doen, dan ben ik je man. Ik heb aan de achterkant en de voorkant gewerkt, webservices op de middenlaag gebouwd en heb nieuwe talen en frameworks direct opgepikt wanneer dat nodig was. Wat ik niet doe - ik zou moeten zeggen, wat ik niet goed doe - is design. Als je me vraagt ​​om een ​​webpagina te ontwerpen, zal ik het doen, begrijp me niet verkeerd, maar ik zal het je doen door je te vertellen dat ik hierin geen training of expertise heb en dat je de resultaten misschien niet leuk vindt. Ik denk dat je uiteindelijk beter een echte ontwerper kunt inhuren en mij vervolgens kunt gebruiken om het ontwerp van die persoon te nemen en het 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 "betaal me meer", want in zekere zin is dat wat hij doet. Het probleem hier is echt niet zozeer dat software-ontwikkelaars betaald krijgen X en wiskunde zou je X + 10% moeten opleveren, het is dat sommige softwareontwikkeling niet echt wiskunde vereist en dus mensen vragen om veel te doen, betekent dat je zullen eindigen met minder dan geweldige resultaten. Afhankelijk van de situatie zou ik kunnen aanbevelen:

• De vaardigheden van uw andere ontwikkelaars doornemen en kijken of iemand anders in uw team een ​​meer wiskundige achtergrond heeft, of bereid is te leren wat u moet leren. Je zou ze zelfs kunnen verkopen met de gedachte 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 wordt besteed aan het opvoeren van dingen (en in het proces, mogelijk aan het leren van nieuwe architectuur en frameworks), die specifieke ontwikkelaar ook zal worden vertraagd door de wiskunde die je moet leren en begrijpen. willen implementeren.

• Een analist inschakelen om de vergelijkingen uit te zoeken en vervolgens uw bestaande ontwikkelaars de vergelijkingen in code laten implementeren, net zoals ze zouden doen met andere stukje bedrijfslogica. Dit heeft als nadeel dat de persoon die de wiskunde kent, uiteindelijk niet de wiskunde in je systeem schrijft, maar dat kan vrij gemakkelijk worden opgelost door de nadruk te leggen op testgestuurde ontwikkeling (wat je al doet, toch? Rechtsaf?). Deze methode heeft ook het voordeel dat, als je bijvoorbeeld in de financiële wereld werkt, je een van de nummers kunt pakken die mensen uit hun afdeling halen: de kans is groot dat ze deze dingen beter zullen kennen dan praktisch elke s-dev. die u van de straat kunt halen, want dat is hun taak.

• Een externe consultant binnenhalen om niets anders te doen dan het wiskundige gedeelte van de code, en dan gewoon een beetje dat deel vergrendelen om nooit meer te worden aangeraakt. Dit is ook om veel redenen problematisch - in de eerste plaats, de dag dat ik code vind die niet hoeft te worden geherstructureerd, is de dag dat ik mezelf voorstel aan de meest paranormale ontwikkelaar ooit - maar afhankelijk van wat jij bent proberen te doen, is dit misschien de manier om het aan te pakken. Die andere man kost misschien ook wat meer dan wat je aan je huidige ontwikkelaars betaalt, maar 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 zichzelf dat je een sit-down gesprek moet hebben met de persoon die dit zegt (ik zou, als een terzijde, wees voorzichtig dat hij zich niet houdt aan de busfactor en het is misschien tijd om een ​​deel van de code van deze man door te nemen, niet als straf, maar omdat IME-mensen die denken in termen van looncijfers in deze industrie denkt ook in termen van dingen doen om zichzelf onvervangbaar te maken). Ik denk echter niet dat hij per se ongelijk is.

U zegt dat chagrijnig een van de oudste ontwikkelaars is. Ik vraag me af hoe oud? Jaren geleden had ik iemand die halverwege de vijftig voor me werkte, hij was een bekwame ontwikkelaar, hij was gelukkig in zijn werk, maar hij weigerde enige 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 ze niet overschrijden. Respecteer zijn oordeel en gebruik hem voor de dingen die hij goed doet.

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

Als zijn functieomschrijving het doen van dit soort werk echt inhoudt, en zijn salaris daarvoor geschikt is, dan is zijn claim is onnauwkeurig.

Aan de andere kant komen zijn functieomschrijving en / of salaris 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 voor een nieuwe functieomschrijving, betekent dit niet dat het bedrijf de functieomschrijving en het salaris van die werknemer dan niet moet aanpassen. Sommige bedrijven proberen dat misschien, maar dat is niet gepast en kan het moreel verminderen en uiteindelijk werknemers verliezen.

Uit uw opmerkingen klinkt het alsof u het niet zeker weet. In plaats van (zoals sommige andere antwoorden hier suggereren) een weigering of een slechte houding aan te nemen, zou ik voorstellen om het te behandelen als een respectabele suggestie voor volwassenen en op een professionele manier te reageren door de suggestie te erkennen en mensen te raadplegen die dat zouden willen. weet wat geschikt is voor dat soort werk, en neem dan contact met hem op over wat je daarover te weten bent gekomen.

De werknemer zegt dat hij geen werk wil doen waarvoor hij niet is ingehuurd, en biedt een compromis: meer geld en hij doet het werk toch.

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

Behandel dit als elke andere werknemer die geen werk wil doen. baan waarvoor hij niet was aangenomen. En hoe je daarmee 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 eraan willen werken.

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

• Wat is de titel van de oude functie?
• Wat wordt voor die functie betaald? (Markttarieven)
• Wat is de titel van de nieuwe functie?
• Wat wordt voor die titel betaald? (Markttarieven)
• Wat is het verschil in beloning tussen "Senior Developer" en "That Title"
• Is het de tijd / moeite waard voor hem om het loonverschil te krijgen?

Wat is de titel van de huidige positie? Verschillende titels krijgen verschillende salaristarieven ... er is een verschil tussen een ontwikkelaar en een ingenieur ... een senior ontwikkelaar en een senior ingenieur. Hoe heet de nieuwe titel? Mathmatics Developer? Onderzoeker Ontwikkelaar? Senior Research Engineer?

Wat krijgt iemand met die titel tegen marktconforme tarieven betaald? Sommige functies zijn 'moeilijker' maar worden minder betaald ... Denkonderzoeker aan universiteiten ... veel mensen proberen de posities te krijgen die zo eisen verlaagt de markttarieven.

Wat is het verschil tussen de huidige "Titel" en "Nieuwe titel" op de markt? Als het $ 1000 / jaar is ... is dat een ander gesprek dan het $ 75.000 per jaar is ...

Wat betekent ... is het de moeite waard voor "Grumpy Dev" om "Math Research" te leren? Ja, het is waar dat een deel van een ontwikkelaarsleven het leren van nieuwe dingen is ... het is ook het leren van nieuwe dingen die waardevol zijn. Ofwel in geldelijke termen (loonsverhoging) of in andere termen (loopbaanontwikkeling, nieuwe kansen, nieuwe technologieën) ...

Sir Grumpy, voor mij, heeft duidelijk gemaakt dat zijn belangrijkste prioriteit geld is. Als hij een front-end ontwikkelaar wil worden en je probeert hem een ​​Applied Science-ontwikkelaar te maken ... is het misschien niet de moeite waard om over te stappen - gezien dezelfde loonschaal. De enige manier waarop hij het de moeite waard zou vinden, is $$$. Of hij is niet geïnteresseerd en schuift de verantwoordelijkheid aan jou over. Komen de marktrente overeen met zijn verwachtingen? Uw verwachtingen?

Ik denk 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 inslaat, maar je iemand met ervaring nodig hebt om te helpen, dan ga je naar die persoon met de op een na beste ervaring na hem, of overweeg zelfs om naar hun specifieke vaardigheden te kijken (heeft iemand in uw team een ​​wiskundige achtergrond?) en laat hem doorgaan met het onderhoud dat uw team gewoonlijk doet.

Maar om uw vraag te beantwoorden: 'is dit een eerlijk verzoek?' - het is eerlijk van hem om er te vragen , maar je hoeft er helemaal niet verder op in te gaan.

Als je grondig onderzoek hebt gedaan en ervoor hebt gezorgd dat het loonpercentage voor een persoon met zijn ervaring in zijn functie marktconform is, dan is er weinig ruimte om te beweren dat een permanente verhoging op zijn plaats is.

Overweeg ook de volledige betekenis van zijn titel - van een softwareontwikkelaar wordt verwacht dat hij wat onderzoek en ontwikkeling doet wanneer dit relevant is voor zijn functie. Tot nu toe is dat niet zo geweest. Maar aangezien uw team de opdracht krijgt om dit nieuwe type programma te implementeren, maakt het nu deel uit van het werk, en als u die taken niet uitvoert, moet u een deel van zijn baan afwijzen.

Vanaf nu is dat geen vernietigend probleem - je hebt andere ontwikkelaars die je in plaats daarvan voor deze taak kunt instellen. Maar als uw team ontwikkelaars nodig blijft hebben die enig begrip hebben van dit soort wiskunde, kan deze werknemer een aansprakelijkheid worden als hij niet bereid is om te leren. Houd daar dus rekening mee.

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

Waar je teamgenoot om vraagt, is helemaal niet eerlijk.

Het leren van nieuwe vaardigheden maakt deel uit van elke baan, vooral vandaag de dag in de technische 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 de kans waarderen om hun vaardigheden bij weinig of geen kosten, en in wezen kunnen leren tijdens het werk.

De reactie van je teamgenoot is ronduit ongehoorzaam en giftig. Je hebt zo iemand niet nodig in je team.

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