Come affrontare un argomento del tipo "non sono pagato abbastanza per fare questo compito"?

Beh, la soluzione è semplice. Ringraziate il brontolone per la sua onestà, rimettetelo al lavoro normale e portate il prossimo dalla panchina.

Se qualcuno non è interessato a un progetto come questo e ci sono altre persone disponibili, allora è nell'interesse di tutti mettere sul progetto le persone che sono più interessate. Dare un aumento non lo renderà più entusiasta del progetto, quindi non è nel vostro o nell'interesse del progetto averlo comunque lì.

Più in là dovrai fare anche tu delle scelte difficili. Io terrei d'occhio l'atteggiamento di questo sviluppatore e il modo in cui influisce sul team. Potrebbe essere che tu abbia un inizio di cancro. Se si sta davvero godendo il suo lavoro, questa è una di quelle affermazioni di cui si pentirà. Ma per me, il miglior risultato che questo sviluppatore può sperare è che abbia raggiunto il soffitto con il team - e questo può andare bene se conosce i vostri sistemi, fa bene il suo lavoro e non causa problemi. Se non è questa persona, però, alla fine dovrai affrontarla.

Questo è qualcosa che avrebbe dovuto essere evitato , non affrontato dopo il fatto. Mi dispiace ma se lei (come sembra, senza alcun tipo di preavviso) cambia improvvisamente la direzione dello sviluppo personale dei dipendenti, e si sorprende quando questa non è la stessa direzione verso cui lo sviluppatore vuole procedere, il problema non è con il dipendente.

È giusto essere scontrosi in questo scenario? Certamente. È giusto chiedere un aumento? Forse, forse no - forse il dipendente è addirittura pagato troppo. Dato che il datore di lavoro e il dipendente hanno ovviamente aspettative diverse sulla portata del dipendente, non è possibile che un terzo possa dire.

Anche la cultura conta naturalmente - sono in Svezia FWIW (in genere gerarchie relativamente piatte e dipendenti con poteri/dirigenti deboli).

Così ho chiamato i due sviluppatori più anziani e più esperti che ho nel mio team e ho presentato loro il progetto. Mentre uno di loro sembrava davvero interessato, l'altro era un po’… scontroso, a dir poco.

Hai scelto di chiedere ai due sviluppatori più esperti di accettare la sfida. Se quello che ha rifiutato l'incarico lo avesse fatto senza essere scontroso, o avesse presentato un'argomentazione ben ponderata, vi sareste semplicemente rivolti al candidato n. 3? Se è così, allora fatelo.

Se c'è ancora un posto per lo sviluppatore che ha rifiutato l'opportunità, allora assegnategli quel compito.

Ricordate, non chiedete loro di uscire leggermente dalla loro zona di comfort. State chiedendo loro di imparare un po’ di matematica di cui potrebbero non vedere la necessità al di là di questo progetto. Il candidato migliore potrebbe non essere stato il due sviluppatori più anziani. Potrebbe essere stato lo sviluppatore più giovane, o anche lo stagista (anche se non ho intenzione di chiedere a uno stagista di essere responsabile di un'abilità critica a lungo termine).

Lasciatemi fare l'avvocato del diavolo:

• La vostra azienda ha intrapreso un lavoro in cui non ha assolutamente alcuna competenza.
• Questo lavoro si svolge in un campo che è molto diverso dalla maggior parte degli altri campi dello sviluppo di software. Questo non è il vostro abituale “imparare un nuovo linguaggio di programmazione”, questa è una matematica pesante che anche la maggior parte dei matematici a tempo pieno teme.
• La vostra azienda si rifiuta di assumere una nuova persona come guida, invece crede che i corsi e le formazioni teoriche possano compensare l'assenza di esperienza.
• Hanno messo al timone un ottimista e un entusiasta senza speranza (voi)
• Il leader (voi) non riesce nemmeno a riconoscere che altre persone potrebbero avere obiettivi diversi dai suoi.

Ora, non sto dicendo che questa sia una ricetta per il disastro. Ma molti disastri hanno seguito questa ricetta.

Unirsi al vostro team di leader non è tutto rose e fiori come lo descrivete voi. Dici che si tratta di imparare, ma non c'è nessuno che abbia esperienza per insegnarti. Questo significa che imparerete con i vostri errori e in molti casi imparerete sbagliando. Nel migliore dei casi, dovrete disimparare grandi pezzi della vostra nuova conoscenza. Nel peggiore dei casi, non saprete mai cosa avete sbagliato.

C'è un'alta probabilità di fallire. Ci sono molti modi in cui può fallire, scommetto che il tempo (e quindi il costo) è molto alto (poche centinaia di punti percentuali), quindi la vostra azienda sarà in perdita. Il caso peggiore è che il cliente invocherà clausole penali e la vostra azienda perderà molto di più del vostro tempo e dei vostri stipendi, quindi gli sviluppatori potrebbero essere licenziati con la reputazione macchiata. Non crede che il rischio valga la pena di essere compensato?

Ho dipinto l'immagine più pessimista, ma credo che sia necessario controbilanciare il suo ottimismo.

Torniamo all'ultimo punto della mia lista di punti, che è l'unica cosa che lei personalmente ha sbagliato. Lei ha preso la decisione su ciò che gli altri sviluppatori vogliono nelle sue mani. Non sembra che tu ti renda conto che ciò che tu vedi come eccitante, gli altri possono vederlo come intimidatorio o semplicemente noioso. Lo vedete come un miglioramento, mentre vi rifiutate di accettare che gli altri lo vedano come un declassamento. O semplicemente non si adatta bene al loro equilibrio tra lavoro e vita privata. Un altro punto di vista è che lo vedete come rientrante nell'ambito della posizione di “sviluppatore”. Il problema è che non è altro che un'opinione. Un'opinione opposta, che costituisce un lavoro nuovo di zecca, è valida quanto la vostra. Devi aspettarti che altre persone non condividano le tue opinioni. Andava bene chiedere con disinvoltura se qualcuno vuole il nuovo lavoro. Ma ci si sarebbe dovuto aspettare un “no” tanto quanto un “sì”.

Bisogna anche tenere presente che un lavoro è sempre un contratto. E come ogni contratto, ci vogliono due parti per cambiarlo. La descrizione del lavoro fa parte del contratto. Non si può cambiare la descrizione del lavoro unilateralmente, così come il dipendente non può cambiare unilateralmente il suo stipendio. Sì, ci si aspetta comunemente che un dipendente migliori, ma questo non significa assumersi nuove responsabilità, significa rimanere competitivi nell'esecuzione di quelle per cui è stato assunto.

Il contratto può essere cambiato in qualsiasi momento ogni volta che entrambe le parti sono d'accordo con il cambiamento. **Ma tutti devono essere pronti a convivere con la risposta.

IMHO la sua domanda non era una vera domanda, semplicemente non vuole il nuovo lavoro. E ti ha ribaltato la situazione, quindi sei tu che devi dire “no”. Non c'è niente da gestire qui, se non cambiare il tuo atteggiamento nei confronti del tuo team che condivide le tue convinzioni e i tuoi obiettivi di vita.

Penso che sia giusto chiedere un aumento dopo essere stato assegnato a un lavoro specializzato che richiede un insieme specifico di competenze che non sono comuni sul posto di lavoro. Sembra che questo possa essere un progetto di tipo “big data” e che queste competenze siano molto richieste e che paghino molto meglio dello stipendio medio di uno sviluppatore. Questo è vero anche solo se l'attività sarà continuativa.

Gli aumenti per le competenze specialistiche per un progetto di 3-6 mesi non sono appropriati (potrebbe essere un bonus). I rilanci per il nuovo team permanente Big Data sono. Come capo, potresti fare una ricerca sugli stipendi per le persone con le competenze che chiedi al tuo team e vedere se potrebbe essere opportuno discutere gli aumenti di stipendio con il management dopo che il tuo team ha dato prova di sé.

Tuttavia, normalmente questa richiesta sarebbe per l'intero team e generalmente avverrebbe dopo che hanno acquisito le competenze, anche se potrebbe essere promesso in una certa data successiva se le competenze sono state acquisite.

Il modo in cui si è comportato rifiutando di ottenere la qualifica senza un aumento di stipendio è generalmente disapprovato. Personalmente, dato che lei ha altro personale tra cui scegliere, passerei alla persona successiva che potrebbe essere interessata. Probabilmente avrei intervistato la squadra prima di chiedere a chiunque fosse interessato ad acquisire queste competenze e poi avrei fatto la mia scelta tra i volontari dopo che ognuno di loro ha avuto la possibilità di far valere le proprie ragioni per cui dovrebbe essere scelto. Non sono molte le persone che sono veramente interessate alle competenze matematiche superiori, ma una persona più giovane potrebbe aver già fatto qualche studio in questo campo perché faceva parte dei suoi interessi.

Il brontolone ha gestito questo molto male. Tuttavia…

In qualità di sviluppatore per decenni, e ora è un ricercatore matematico che si occupa di analisi predittive, capisco il punto di vista di Grumpy. Mentre gli sviluppatori di software devono essere preparati ad apprendere bit e pezzi da una grande varietà di discipline per poter fare il loro lavoro, c'è una differenza significativa tra uno sviluppatore e un ricercatore, così come c'è tra un manager e uno sviluppatore. Questo non è come se si rifiutasse di imparare un nuovo linguaggio di programmazione o di capire come interfacciarsi con qualche hardware strano; è più come se si rifiutasse di fare progettazione grafica o di gestire un team o di pilotare un aereo.

Grumpy può essere matematico-fobico. Ma è anche possibile che sappia abbastanza di statistica e di data mining da sospettare che si tratti di un difficile e torbido slog. In questo particolare settore della matematica, è molto facile imparare alcune tecniche, ma è anche facile applicarle nelle situazioni sbagliate! Uno studente delle scuole superiori potrebbe imparare a fare ARIMA, ma sapere quando è valida e come scegliere i parametri giusti è più a livello di studente laureato. Molti matematici non amano la statistica, non perché sia più difficile di altri campi, ma perché è più… complicato.

Come te, salto la possibilità di imparare nuova matematica, e amo il mio lavoro. Ma capisco come Grumpy possa sentire che gli si chiede di fare qualcosa che è troppo al di fuori del ruolo di sviluppatore. Come ho detto, l'ha gestita molto male, e non lo scuso. Ma potrebbe avere qualche giustificazione per il modo in cui si sente.

Parlando da matematico diventato sviluppatore di software, simpatizzo con Grumpy: cioè ora preferisco lo sviluppo di software (e penso di essere più bravo nello sviluppo di software che in matematica).

D'altra parte, se fossi al posto di Grumpy e volessi dirvi questo, lo farei - e lo farei senza confondere la questione menzionando lo stipendio.

Il fatto che Grumpy abbia menzionato lo stipendio potrebbe significare che Grumpy è scontroso riguardo allo stipendio, e questo progetto è solo una scusa per chiedere un aumento.

Quindi il mio consiglio sarebbe quello di cercare di separare le questioni, anche se Grumpy non le ha separate. Chiedete: “Grumpy è contento del suo attuale stipendio? Chiede un aumento a prescindere da questo nuovo progetto?”. Dato che è quello dei due sviluppatori più vecchi e più esperti dovresti prima offrirgli un aumento incondizionato, e poi chiedergli se è disposto a fare questa nuova cosa?

E/O puoi rassicurarlo sulla natura delle nuove responsabilità? Se fossi in lui potrei preoccuparmi di fallire. L'aumento di stipendio potrebbe essere “denaro del pericolo” per compensarmi dell'aumento del rischio o dello stress o degli straordinari non pagati. Ad esempio, l'azienda fornirà un aiuto sufficiente (ad esempio, un esperto di settore, cioè un mentore matematico) per garantire il suo successo?

Lei dice che si tratta di “ricerca a livello accademico”, ma anche di “fondamentalmente ricerca e sviluppo di software” che potrebbe essere reciprocamente escludente/contraddittorio. A quanto pare lei è più appassionato di lui di quanto lo sia lui di ricerca accademica?

È possibile che lo sviluppatore pensi di non essere pagato abbastanza per il lavoro che sta svolgendo ora? Di solito quando la gente dice “non sono pagato abbastanza per fare questo”, intende dire che si sente sottovalutato in generale, e potrebbe essere un rischio di fuga.

Se sei nella posizione di aggiustare questo, e lui è sottovalutato (o non è grossolanamente sopravvalutato), allora potrebbe fare una buona osservazione, e si può regolare i suoi obiettivi aziendali per riflettere che se fa questa ricerca e sviluppa questo progetto con successo, otterrà un aumento quest'anno che sarà migliore dell'aumento del costo della vita. Proporre una percentuale in anticipo e documentarla. Oppure la vostra azienda potrebbe avere delle designazioni come “superare le aspettative” che si traducono automaticamente in un grosso aumento, quindi ditegli che otterrà “superare le aspettative” e sarà ricompensato di conseguenza. Il denaro può essere un grande motivatore, e trasformare i brontoloni in campeggiatori felici.

Oppure potrebbe dire che non si vede davvero come un ricercatore matematico. Se è così, chiedete a qualcun altro di farlo e presentatelo al team. Se in realtà si tratta solo di ricerca, potreste chiedere al vostro product manager o all'analista aziendale di studiare le informazioni e di metterle in relazione con il team di sviluppo dei requisiti.

Anche se non sono davvero, davvero non sono un fan del fraseggio di questo tizio - nello sviluppo di software in particolare, siamo pagati una cifra abbastanza decente per fare quello che facciamo, e quello che facciamo spesso comporta la ricerca per capire come farai la cosa che hai detto che avresti fatto - penso che ci sia un nocciolo di verità in quello che sta dicendo. No, non dovresti dargli un aumento. C'è un punto però in cui chiedere a una persona che non lavora con cose matematiche di fare cose matematiche sarà un brutto momento sia per te che per loro.

In realtà mi sono imbattuto in una situazione semi simile nella mia carriera di sviluppatore. Voglio dire, per certi versi non è proprio la stessa cosa, ma comunque… come già detto, sono uno sviluppatore. Io sviluppo cose. Se vuoi implementare una qualche logica di business e far sì che i widget su una pagina web saltino in giro e facciano cose, io sono il tuo uomo. Ho lavorato sul back end e sul front end, ho costruito servizi web di medio livello, e ho raccolto nuovi linguaggi e framework al volo quando ne ho avuto bisogno. Quello che non faccio - dovrei dire, quello che non faccio bene - è il design. Se mi chiedete di progettare una pagina web, lo farò, non fraintendetemi, ma lo farò dicendovi che non ho formazione o esperienza in questo e che i risultati potrebbero non piacervi. Alla fine penso che sarà meglio che assumiate un designer vero e proprio e poi mi usiate per prendere il progetto di quella persona e realizzarlo.

Quindi quello che direi di fare qui è di prendere questo tizio come se vi stesse dicendo questa cosa invece di “pagarmi di più”, perché in un certo senso questo tipo di è quello che sta facendo. Il problema qui non è tanto che gli sviluppatori di software vengono pagati X e fare matematica dovrebbe farti ottenere X + 10%, è che alcuni sviluppi software non richiedono la matematica e quindi chiedere alla gente di farne molta significa che ti ritroverai con risultati meno che stellari. A seconda della situazione, potrei consigliare:

• Guardando attraverso le competenze degli altri sviluppatori e vedendo se qualcun altro nel vostro team ha un background più matematico, o è disposto ad imparare quello che dovete imparare. Potreste anche convincerli del fatto che questo rappresenta un nuovo strumento che possono imparare e portare con sé per i loro futuri concerti (vedi sotto!). Il più grande svantaggio in questo caso è che, oltre al tempo supplementare speso per far crescere le cose (e nel processo, possibilmente per imparare nuove architetture e framework), quel particolare dev sarà anche rallentato dal dover imparare e capire la matematica che si vuole implementare.

• Portare un analista per capire le equazioni e poi fare in modo che i vostri dev esistenti implementino le equazioni in codice, proprio come farebbero con qualsiasi altro pezzo di logica di business. Questo ha l'aspetto negativo che la persona che conosce la matematica non sta alla fine scrivendo la matematica nel vostro sistema, ma che può essere risolto abbastanza facilmente mettendo l'enfasi sullo sviluppo guidato dai test (cosa che state già facendo, giusto? Giusto?). Questo metodo ha anche il vantaggio che, se si lavora, per esempio, in finanza, si può prendere uno dei numeri del loro dipartimento: è probabile che conoscano questa roba meglio di qualsiasi s-dev si possa portare per strada, perché questo è il loro lavoro.

• Portare un consulente di terze parti per gestire solo la parte matematica del codice, e poi bloccare quella parte per non essere mai più toccata. Anche questo è problematico per molte ragioni - prima di tutto, il giorno in cui trovo del codice che non ha bisogno di essere rifatto a posteriori è il giorno in cui mi presento allo sviluppatore più psichico di sempre - ma a seconda di quello che stai cercando di fare, questa potrebbe essere la strada da seguire. Quell'altro tizio potrebbe anche costare un po’ di più di quello che stai pagando ai tuoi attuali sviluppatori, ma, beh, è un sottocampo specializzato.

Come ho detto, non sono un grande fan del fraseggio qui, e forse questo significa che di per sé significa che hai bisogno di fare una chiacchierata con la persona che ti sta dicendo questo (io, a parte questo, sarei un po’ diffidente se non aderisse al Bus Factor e potrebbe essere il momento di ripercorrere un po’ del codice di questo tizio, non come punizione, ma perché le persone IME che pensano in termini di retribuzione in questo settore pensano anche in termini di fare cose per rendersi insostituibili). Non penso però che sia necessariamente ingiusto.

Lei dice che il brontolone è uno dei più vecchi sviluppatori. Chissà quanti anni ha? Anni fa avevo qualcuno che lavorava per me che aveva circa 50 anni, era uno sviluppatore competente, era felice nel suo lavoro, ma si rifiutava di assumersi qualsiasi responsabilità extra. È venuto fuori che c'era una storia, aveva dovuto prendere una pausa di carriera in passato a causa dello stress, conosceva i suoi limiti, e non voleva superarli. Rispetta il suo giudizio e usalo per le cose che fa bene.

Direi che la risposta dipende da quanto è accurata la valutazione dello sviluppatore.

Se la sua descrizione del lavoro include effettivamente lo svolgimento di questo tipo di lavoro, e la sua retribuzione è appropriata per questo, allora la sua affermazione è imprecisa.

D'altro canto, la descrizione del suo lavoro e/o il tasso di retribuzione non corrispondono al nuovo tipo di lavoro, quindi dovrebbero essere corretti per riflettere accuratamente questo.

In generale, anche se un'azienda forma un dipendente a una nuova descrizione del lavoro, ciò non significa che l'azienda non dovrebbe poi adattare la descrizione del lavoro e il tasso di retribuzione di quel dipendente per corrispondere. Alcune aziende possono tentare di farlo, ma questo non è appropriato ed è incline a diminuire il morale ed eventualmente a perdere dipendenti.

Dai vostri commenti, sembra che non ne siate sicuri. Piuttosto che (come hanno suggerito alcune altre risposte) trasformare la sua dichiarazione in un rifiuto o in un cattivo atteggiamento, suggerirei di trattarlo come un suggerimento adulto rispettabile, e di rispondere in modo professionale adulto, riconoscendo il suggerimento e consultando le persone che saprebbero cosa è appropriato per quel tipo di lavoro, per poi tornare da lui su ciò che avete scoperto.

Il dipendente dichiara di non voler fare un lavoro per il quale non è stato assunto e fornisce un compromesso: più soldi e farà il lavoro comunque.

È necessario rifiutare l'opzione più soldi. Se non vuole fare il lavoro, probabilmente non sarà contento di farlo nonostante il denaro aggiuntivo, e l'infelicità può essere contagiosa. Inoltre, crea un brutto precedente per le persone che vogliono fare il lavoro ma che ora sanno di poter chiedere un aumento prima di imparare qualcosa di diverso.

Trattatelo come qualsiasi altro dipendente che non vuole fare un lavoro per il quale non è stato assunto. E come gestirlo dipende da molti altri dettagli, ma in questo caso specifico, ** lo si ringrazia per il tempo e si chiede un volontario diverso** , perché questo è il tipo di progetto su cui si vuole lavorare con persone che vogliono lavorare su di esso.

Penso che un paio di punti minori relativi alla domanda non siano stati posti/risposti da altri poster (a partire da questo post):

• Qual è il titolo della vecchia posizione?
• Cosa viene pagato per quella posizione? (Tassi di mercato)
• Qual è il titolo della nuova posizione?
• Cosa viene pagato? (Tariffe di mercato)
• Qual è la differenza di retribuzione tra “Sviluppatore Senior” e “Quel titolo”
• Vale il tempo/sforzo per lui per ottenere la differenza di retribuzione?

Qual è il titolo della posizione attuale? Titoli diversi ottengono tariffe retributive diverse… c'è una differenza tra uno Sviluppatore e un Ingegnere… uno Sviluppatore Senior e un Ingegnere Senior. Come si chiama il nuovo titolo? Sviluppatore di matematica? Ricercatore Sviluppatore? Senior Research Engineer?

Come viene pagato qualcuno con questo titolo, a prezzi di mercato? Ci sono alcune posizioni che sono “più difficili” ma vengono pagate meno… Pensate a Ricercatore presso le Università… molte persone che cercano di ottenere le posizioni in modo che la domanda abbassi i tassi di mercato.

Qual è la differenza tra l'attuale “Titolo” e “Nuovo Titolo” nel mercato? Se si tratta di $1000/anno… è una conversazione diversa da quella di $75000 all'anno…

Il che significa… vale la pena che “Grumpy Dev” impari “Math Research”? Sì, è vero che parte della vita di uno Sviluppatore è imparare cose nuove… è anche imparare cose nuove che hanno un valore. Sia in termini monetari (aumento dei salari) che in altri termini (progressione di carriera, nuove opportunità, nuove tecnologie)…

Sir Grumpy, per me, ha chiarito che la sua priorità principale è il denaro. Se vuole diventare uno Sviluppatore di Front End e voi state cercando di farne uno sviluppatore di Scienze Applicate… potrebbe non valergli la pena di cambiare - data la stessa scala retributiva. L'unico modo per lui di considerare che ne valga la pena sarebbe di $$$. O è così, oppure non è interessato e sta passando la responsabilità a voi. Le tariffe di mercato sono in linea con le sue aspettative? Le sue aspettative?

Credo che una risposta al vostro problema sia già stata fornita - che se avete una persona nel vostro team non interessata ad un progetto che va in una nuova direzione, ma avete bisogno di qualcuno con esperienza per aiutarvi, allora andate dalla persona con la più grande esperienza dopo di lui, o forse anche prendere in considerazione la possibilità di esaminare le sue competenze specifiche (qualcuno nel vostro team ha un background matematico?) e lasciate che continui a fare la manutenzione che il vostro team di solito fa.

Ma per rispondere alla vostra domanda - “è una richiesta giusta? Se avete fatto le vostre ricerche e vi siete assicurati che la retribuzione di una persona con la sua esperienza nella sua posizione sia conforme ai valori di mercato, allora non c'è molto spazio per sostenere che un aumento permanente sia adeguato.

Inoltre, considerate tutte le implicazioni del suo titolo - uno Sviluppatore di software è tenuto a svolgere attività di ricerca e sviluppo quando è rilevante per la sua posizione. Finora non lo è stato. Ma dato che il suo team è stato incaricato di implementare questo nuovo tipo di programma, ora fa parte del lavoro, e rifiutare di eseguire questi compiti significa declinare una parte del suo lavoro.

Per ora, questo non è un problema dannoso - avete altri sviluppatori che potete impostare su questo compito, invece. Ma se il vostro team continua ad avere bisogno di sviluppatori che abbiano una certa comprensione di questo tipo di matematica, questo dipendente potrebbe diventare un peso se non è disposto ad imparare. Quindi tenetelo a mente.

Si noti che il fatto che rientri o meno nella sua descrizione del lavoro dipende anche dal suo contratto - molti contratti hanno una clausola per "qualsiasi altro compito richiesto per svolgere il vostro lavoro”, che include una formazione aggiuntiva come questa.

Ciò che il vostro compagno di squadra chiede non è giusto - per niente.

L'apprendimento di nuove competenze fa parte di qualsiasi lavoro, soprattutto oggi nel settore tecnologico.

La vostra azienda si offre di pagare la formazione, quindi non è come se il vostro compagno di squadra venisse gettato nel profondo.

La maggior parte delle persone apprezzerebbe la possibilità di espandere e migliorare le proprie competenze a poco o nessun costo, ed essere in grado di imparare essenzialmente sul lavoro.

La risposta del tuo compagno di squadra è francamente insubordinata e tossica. Non avete bisogno di nessuno di questo tipo nel vostro team.

Questo problema dovrebbe essere affrontato da un manager o da qualcuno che sia responsabile della valutazione delle prestazioni del vostro compagno di squadra.