Gli ho detto che avrei esaminato la questione ma, ad essere sinceri, non so cosa fare con lui. Capisco da dove viene, ma semmai penso che la sua risposta sia stata inappropriata e un po 'poco professionale.

"Abbiamo caricato il nostro mulo da soma con tutto quello che avrebbe portato fino a quando non gemette di dolore . Poi ci siamo ammucchiati un po 'di più su di esso e ha gemuto ancora più forte. Non capisco perché continua a gemere quando ne accumuliamo di più in cima. " - Fondamentalmente è così che vedo la situazione che hai descritto.

Aveva la responsabilità esclusiva del progetto specifico a causa della mancanza di una buona gestione. Ora gli hai presentato una maggiore responsabilità, espressa come una sorta di "boccata d'aria fresca". Lo vede come un carico di lavoro aggiuntivo e francamente sembra esausto. Niente di tutto questo, dal mio punto di vista, è colpa sua o sua responsabilità. Hai intenzione di rimuoverlo dall'altro progetto o di continuare a "accumulare" il suo elenco di responsabilità e carico di lavoro? Se fossi in lui, ti avrei dato la stessa risposta.

Devi fornire una profondità adeguata in modo da alleviare il suo carico di lavoro e devi fargli capire che questo nuovo progetto non sta semplicemente aggiungendo altro lavorare al suo carico già sovraccarico.

MODIFICA:

Ho letto la tua modifica alla domanda, ma francamente continuo a vedere come "Lo sappiamo abbiamo fatto un pessimo lavoro nella gestione di questi progetti e nella gestione del tuo carico di lavoro, ma abbiamo davvero bisogno che tu partecipi a questo progetto recente e molto urgente ". - E sta ancora interpretando la situazione come più lavoro e più responsabilità.

Non ti sto incolpando per questa situazione, ma ci convinco che abbiamo torto con le nostre supposizioni.

hanno tutti persone a rotazione per coprire le emergenze e altre cose. Il team di John, invece, no, perché solo lui sa come risolvere la maggior parte dei problemi che potrebbero sorgere.

Quindi la sua esperienza con l'azienda è di lavoro extra, superiore al normale livelli di stress, essere la singola persona infastidita dallo stato del progetto ed essere quella che deve risolvere ogni problema da sola.

ha evidenziato la sua urgenza per l'azienda

A meno che il progetto non sia di alto profilo e ci sia qualche bella promozione disponibile dopo, "urgente" di solito è il codice per lavoro extra e manager che chiedono "hai finito?" ogni giorno. I progetti urgenti richiedono eroi. L'eroismo può essere apprezzato in molte aziende e può essere ingrato in altre.

Challenging

La maggior parte degli sviluppatori definisce impegnativo un progetto che contiene molte cose che non sanno fare con molte cose che hanno bisogno di imparare, non un progetto con una scadenza ravvicinata.

Metterei nel progetto un altro sviluppatore che ha avuto un'esperienza meno problematica con l'azienda, se per nessun altro motivo potresti facilmente ritrovarti senza alcuna conoscenza al riguardo quando questo sviluppatore si stanca e se ne va.

Posso capire le preoccupazioni di John qui. È l'unica persona che può affrontare le emergenze nel suo progetto attuale. Anche se gli dicessi che non deve più lavorare al suo altro progetto, sa (e ha ragione) che nel momento in cui c'è un problema con il suo progetto attuale, sarà lui quello che sarà chiamato a esaminarlo.

Perché questo nuovo progetto è "critico", sa anche che tutto questo tempo che perderà sulle emergenze dell'altro progetto, si aggiungerà allo stress che sta avendo con il nuovo progetto. E questo nuovo progetto avrà la sua quota di emergenze, quindi per quanto tempo straordinario abbia a causa della mancanza di una squadra, raddoppierà (almeno) con questo nuovo progetto.

E peggio di tutto, suona come l'azienda sta di nuovo cercando di renderlo l'unica persona a conoscenza di un progetto importante, quindi non sembra che il "doppio delle emergenze" se ne andrà presto. Significa solo che alla fine del progetto, la tua azienda deve fare il doppio del lavoro che si è dimostrata riluttante a fare per dare una pausa a John e ora hanno dimostrato che sono disposti a continuare ad accumulare più copie dello stesso identico problema su John ogni volta che si presenta la possibilità.

Dovresti essere felice che abbia detto che non è interessato. Se dovesse accettare questo, ci sono buone probabilità che si dimetta a metà a causa del burnout o della disillusione. Sembra abbastanza intelligente da sapere cosa succederà se dice di sì nella situazione attuale.

Se vuoi che si occupi di nuovi progetti, devi prima dagli il tempo di trasferire tutte le responsabilità per il suo progetto attuale a un nuovo team e poi mettilo a lavorare su questo nuovo progetto con un team . Qualsiasi altra cosa peggiora il problema (e il modo in cui si sente).

il titolo parla di> nuove sfide di <. il corpo è circa> più sfide di <.

prima hai menzionato di avergli procurato una sostituzione, ma invece sembra che ci sia solo un nuovo progetto senza alcuna sostituzione. Quindi questo sembra essere un caso di più.

Quindi il tuo miglior sviluppatore non vuole di più. Se vuoi che lavori al nuovo progetto, assicurati che questo progetto critico sia nuovo, invece di altro. Dopo che sei sicuro che sia davvero solo una novità, dovrebbe essere facile convincere il tuo sviluppatore che è così.

Ma se è di più: il tuo miglior sviluppatore ne sentirà l'odore. Quindi sii onesto con te stesso.

La sua risposta è perfetta, anche piena di satira. Non vedo come un progetto "impegnativo" rimarrebbe inattivo per così tanto tempo, solo per essere ricomposto come "opportunità" in mezzo a una depressione. Mi sembra una "emergenza". I progetti impegnativi sono le cose per cui gli sviluppatori vivono, prima di tutto.

Supponi di aver gareggiato in un incontro su pista. Hai appena finito di correre una maratona. Hai dato il massimo e sei arrivato molto alto in classifica, ma a questo punto sei esausto e piegato in due cercando di riprendere il fiato. Il tuo allenatore ti si avvicina e ti dice "Ehi, bel lavoro! Guarda, uno dei nostri corridori nello sprint dei 500 metri è uscito zoppo. Puoi fare jogging fino alla linea di partenza e sostituirlo? So che sei un corridore di distanza, ma Scommetto che questo è proprio il tipo di sfida che amate i fondisti ". Le probabilità sono alte che lasceresti immediatamente la squadra, magari dopo aver preso di mira l'allenatore.

Dici che questo è uno dei tuoi migliori sviluppatori, ma a quanto pare la tua azienda li sta facendo funzionare male per un po 'di tempo. Per quanto ne so, anche dopo la tua modifica, non hai ancora affrontato la loro preoccupazione principale di essere l'unica risorsa per il vecchio progetto. Potresti progettare di convincere qualcuno a sostituirli durante la manutenzione di quel progetto, ma questo significa semplicemente che saranno responsabili dell'onboarding della loro sostituzione proprio mentre stanno diventando un percorso critico per il nuovo progetto.

La tua azienda ha bruciato uno dei suoi migliori sviluppatori. È necessario seguire e ottenere la sostituzione in atto e addestrati sul vecchio progetto. Devi anche dare al top dev un po 'di respiro per riprendersi da un periodo stressante, forse un paio di mesi in cui la loro unica responsabilità è la manutenzione leggera e l'addestramento della loro sostituzione. Come altri hanno suggerito, chiedi allo sviluppatore cosa vorrebbe fare in futuro . Non devi dare loro tutto ciò che chiedono, ma devi ascoltare e iniziare una negoziazione.

Infine, non parli da nessuna parte di ricompense o incentivi monetari per qualcuno che apparentemente ha svolto un lavoro eccellente , ed è un attore chiave. Lo sviluppatore ha ricevuto una ricompensa monetaria adeguata per il suo buon lavoro? Bonus? Opzioni su azioni? Un aumento?

Le altre domande rispondono molto bene al problema attuale (come sviluppatore sono d'accordo con loro), ma non come risolverlo in futuro .

Consiglio vivamente di fare le seguenti cose:

• Assicurati che parte della conoscenza che solo lui possiede sia data a qualcun altro. Se viene investito da un autobus, hai un problema ancora più grande. È nel tuo interesse diffondere la conoscenza per ridurre al minimo i rischi. È nel suo interesse diffonderlo in modo che non debba aggiustare ogni dannata cosa e dopo un po 'si crea anche un pari con cui discutere certi problemi.

  • Ti suggerisco di farlo chiedendogli se [nuovo bug trovato] potrebbe essere risolto da qualcun altro, possibilmente con una piccola guida da parte sua, in modo che la prossima volta che si verifica l'altra persona possa aggiustalo.
  • Suggerisco anche che crei un qualche tipo di presentazione e lasci che gli altri partecipino per diffonderla ulteriormente e anche rendendo gli altri consapevoli che non è più solo un problema di John. (Puoi opzionalmente aggiungere un "John ha molte conoscenze, in caso di dubbio, John può decidere" bit, riconoscendo lui / il suo lavoro).

• Parlategli di come migliorare la sua situazione. Lascia che le altre risposte penetrino, renditi conto che ha una prospettiva diversa e digli che hai svolto alcune ricerche e "potresti capire meglio la sua risposta". Quindi fai un incontro / discussione con lui dove puoi discutere alcune idee per migliorare la situazione. Alla maggior parte dei programmatori piace creare nuovo codice anziché correggere i bug, quindi il fatto che declina sia una grande bandiera rossa.

Assicurati di essere sincero (a giudicare dal tuo post, non credo sia un problema). Se lo "inganni" (a parte il fatto che è un disgraziato), potrebbe smettere. Ciò di cui ha bisogno in questo momento è qualcuno che gli dia le spalle, che abbia buone intenzioni con John l'umano invece che con John il programmatore.

Come verrà ricompensato?

Ha già fatto un carico di lavoro extra, ha lanciato un progetto sul mercato e ora è fondamentale per il mantenimento di quell'unico progetto. Questo è il confronto con ogni altra squadra, dove ci vogliono più persone per fare ciò che doveva fare da solo. Cosa gli hai dato per questo? L'anno scorso ha ottenuto un aumento di stipendio del 10%? Vacanza extra? Opzioni su azioni? Un'opportunità per scegliere il suo prossimo progetto che avrebbe trovato tecnicamente più interessante?

Se tutto ciò che ha ottenuto è stato "ecco il tuo stipendio, ed ecco un altro progetto deathmarch", non sorprenderti se non è entusiasta.

Si dice spesso che gli ingegneri siano più motivati ​​dalla soddisfazione sul lavoro che dal denaro, e in una certa misura questo è vero. Ma il denaro è l ' modo per giudicare il modo in cui l'azienda ti apprezza veramente. Tutto il resto è sostanzialmente gratuito per l'azienda e il management. Quindi il denaro è il modo in cui tieni il punteggio se la direzione ritiene che i tuoi contributi all'azienda siano stati significativi o meno. Non importa quanti poster "dipendente del mese" ricevi o se il tuo manager dice "bel lavoro". Se hai generato entrate extra per l'azienda, oltre alle aspettative quotidiane, è assolutamente ragionevole aspettarti entrate extra. E viceversa, è assolutamente ragionevole rifiutarsi di impegnarsi ulteriormente se non ci sono ricompense.

Hai etichettato la risposta come "inappropriata / non professionale" a causa del suo rifiuto o del modo in cui ha respinto? Penso che sia ragionevolmente professionale stabilire dei limiti e gestire le aspettative per la sua disponibilità e il carico di lavoro.

Potrebbe essere giusto che dica "Non penso di poter soddisfare le aspettative su questo nuovo progetto data la mia attuale obblighi ". Mi sembra una risposta più professionale che dire "cosa sicura" a un lavoro illimitato e poi fallire in un sottoinsieme arbitrario di esso. Sono parole diverse da quelle che ha usato, ma questo potrebbe essere il messaggio che sta cercando di trasmettere, soprattutto perché non siamo riusciti a vedere la citazione esatta e il contesto per il modo in cui gli hai presentato questo progetto.

Se pensi che sarebbe prezioso per lui partecipare a quel nuovo progetto, chiedigli a quali cose avrebbe bisogno di rinunciare per far sì che il nuovo progetto abbia successo (potenzialmente più opzioni a vari livelli di personale - solo leadership , team lead, unico collaboratore) e quanto tempo prima avrebbe avuto bisogno di trasferire il suo lavoro precedente. Potresti non gradire le risposte che dà, oppure potresti decidere che dovresti scaricare abbastanza lavoro da non essere più un'opzione praticabile, ma avresti almeno trasformato una risposta "sì o no" in un "quanto lo farebbe costa "risposta, e questo da solo può portare a una migliore comprensione e una conversazione più fruttuosa.

Mi sembra che probabilmente abbia rinunciato alla tua azienda e stia cercando qualcos'altro. Quindi non sono interessato a fare qualcosa di nuovo lì. In tal caso la tua unica speranza di trattenerlo sarebbe fargli un'offerta che corrisponda o superi quella che probabilmente otterrebbe sul mercato libero.

Considera inoltre che potrebbe pensare che la tua azienda sia peggiore della media per mantenere le promesse, o l'ambiente di lavoro, o qualsiasi altra cosa, a seconda di ciò che ha vissuto lì. Quindi potresti dovergli offrire molto di più di altri per mantenerlo.

Non importa se è vero o no, a questo punto si tratta solo delle sue percezioni, che potrebbero essere molto difficile da cambiare. Alcune relazioni sono irreparabili.

Per quanto riguarda ciò che dovresti fare:

• Fai sapere ai dirigenti di livello superiore che c'è un alto rischio che se ne vada e che ci sarà un impatto. Più a lungo lo lasci, più alla fine sarà considerato un tuo errore.
• Prepara te stesso e il resto della squadra alla sua improvvisa partenza. Tu, o forse qualcun altro di cui ti fidi, dovresti raccogliere quante più informazioni possibili su ciò che fa senza alienarlo. Questo è più facile in un mondo in cui i manager possono effettivamente fare ciò che fanno i loro diretti, ma non un mondo in cui vive la maggior parte delle persone IT.
• Ovviamente gli altri suggerimenti qui, che sono principalmente incentrati sulla motivazione, valgono provando. Ma se ha già deciso di andarsene, potresti non essere più in grado di influenzarlo e sarebbe uno spreco di fatica. Quindi preparati al peggio.

Non ho visto quella risposta qui, quindi la sto pubblicando, piuttosto tardi.

IL TUO NUMERO DI AUTOBUS È UNO.

È l'unico a conoscere le cose importanti di un'applicazione. Dovrebbe documentare tale applicazione in modo che chiunque abbia familiarità con gli elementi dello stack tecnologico dell'applicazione possa sostituirlo con un tempo minimo di consegna.

Questo dovrebbe essere un progetto formale nel suo elenco di progetti, con una priorità seconda solo per apportare le modifiche necessarie all'applicazione stessa.

La tua descrizione della situazione contiene un indizio che potrebbe essere importante.

John ha una squadra, eppure è l'unico che ha una conoscenza sufficiente del suo progetto per risolverne i problemi particolari .

Alla radice c'è la domanda "perché anche il suo team non è informato e non è in grado di essere coinvolto, o addirittura non fornisce copertura sul suo progetto, soprattutto se altri team dell'azienda seguono questa pratica?" .

Parli di una storia di cattiva gestione del progetto. Ciò può portare i membri del team a evitare il progetto danneggiato piuttosto che condividere la responsabilità. È anche abbastanza naturale per sviluppatori sovraccarichi suddividere sezioni di un progetto o di un portfolio di team in nicchie private in cui il costo della condivisione delle conoscenze è ottimizzato (non hai larghezza di banda per sapere più di quello che hai nel piatto).

È anche possibile che John abbia qualche problema di conforto quando si trasferisce in un nuovo progetto, piuttosto che rimanere in uno in cui è inestimabile e conosce il sistema. Questi possono aumentare il tempo, nuove abilità, ma anche la preoccupazione di essere messo su un ramo che potrebbe essere segato in tempi difficili.

In ogni caso, ci sono cose che potresti essere in grado di fare per staccare John e il suo team dal progetto che è solo su di lui.

Parla con tutto il team, non solo con John, con l'intenzione di migliorare la capacità dell'azienda di condividere il supporto su qualsiasi progetto tra più persone, permettendo loro di lavorare in questo modo.

Ciò porta alla discussione del carico di lavoro del team, del tempo concesso per la documentazione, della condivisione del supporto di produzione, forse della necessità di DevOps o altro personale di supporto o di best practice che potrebbero essere assenti per condividere le responsabilità, ecc. L'elenco potrebbe continuare.

Se vuoi davvero ottenere il massimo dal tuo staff di sviluppo, è importante riconoscere che se John è sovraccarico, probabilmente lo sono anche gli altri. Hanno sperimentato una cattiva gestione ammessa. Non vederlo solo come un problema di John. Probabilmente dovrai assumere qualcuno per aumentare il suo team e / o sostenerlo meglio.

Modifica: assicurati a John con qualsiasi mezzo appropriato che l'azienda lo apprezza e sta vedendo il nuovo progetto come un passo di avanzamento di carriera che lo farà essere riconosciuto in titolo, responsabilità e compenso ... dopo tutto è il tuo miglior sviluppatore.