Quindi ecco la parte che mi sembra approssimativa: hai chiesto al tuo dipendente, John, di fare gli straordinari non pagati nel fine settimana.

• Il motivo per cui è "lavoro" è perché imparare Angular non è qualcosa che John vorrebbe fare nel suo tempo libero, quindi perché non l'ha già fatto (e continua a non farlo), e non fornisce alcun valore a John personalmente se non in quanto fornisce valore a l'azienda. L'esecuzione di un compito che non è a proprio vantaggio ed è invece a beneficio esclusivo del proprio datore di lavoro, si chiama "lavoro".

• Quanto agli "straordinari", tanto dovrebbe essere chiaro; John normalmente non lavora nei fine settimana, quindi gli hai chiesto di lavorare al di fuori dell'orario normale. Si chiama "straordinario".

• Per quanto riguarda "non pagato", presumibilmente non hai offerto a John alcun tipo di compenso per aver svolto questo lavoro durante il fine settimana, e presumibilmente non lo fai avere l'autorità per farlo. Di conseguenza, John non sarà ricompensato per aver fatto questi sforzi nel fine settimana. Si chiama "non retribuito".

Ora che abbiamo capito bene, come team leader e in particolare come nuovo team leader, non dovresti avere la tua prima impressione con la tua nuova squadra essere "per favore trascorri il tuo fine settimana facendo straordinari non retribuiti". Non funzionerà per te a lungo termine. Non farlo.

Arrivando a questo dal punto di vista di John, ho potuto ugualmente vedere una domanda (e ne ho viste molte su Workplace SE in passato!) Che è più o meno questa:

Mi sono laureato di recente all'università, ho fatto domanda e ho ottenuto un lavoro presso un'azienda che cercava uno sviluppatore Java back-end. Una volta entrato in azienda, sono stato immediatamente inserito in un team di sviluppo frontend che utilizza Angular. Non ho esperienza con Angular e l'intervistatore e il responsabile delle assunzioni ne erano entrambi consapevoli durante tutto il processo di intervista. Inoltre, a causa di queste circostanze, il mio capo mi ha chiesto di fare straordinari non retribuiti nei fine settimana per recuperare la mia mancanza di conoscenza. Cosa dovrei fare?

A cui, e poiché ho visto questo tipo di domande in passato, la risposta della stragrande maggioranza sarebbe "Gli straordinari non pagati non sono cool, la tua azienda non rispetta tu, ti hanno accecato con una squadra che non corrisponde alle tue capacità, trova un altro lavoro ". Ed è quello che farà John.

Se vuoi aiutare John invece di frustrarlo e farlo partire, ecco cosa puoi fare:

1. Non chiedere a John (oa chiunque altro!) Di fare straordinari non retribuiti. Non è bello.

2. Se John ha bisogno di imparare Angular, permettigli di farlo durante l'orario di lavoro. Preparagli alcune attività di avviamento (piccoli compiti per abituarlo al framework e abituarlo allo sviluppo del frontend) in modo che possa bagnarsi lentamente i piedi e aumentare il suo livello di comfort.

3. Fornisci a John il tutoraggio di cui ha bisogno.

In mancanza di quanto sopra, chiedi alla tua catena di comando di trasferire John a un team che utilizza effettivamente lo skillset per cui è stato intervistato e assunto con, e non accecarlo cercando di trasformare un abile sviluppatore di backend in un orribile sviluppatore di frontend.

Se fossi un CTO e un manager è venuto da me e mi ha detto,

Non ci stiamo esibendo perché uno dei membri del mio team non è bravo nel suo lavoro

La mia risposta sarebbe,

Perché mi dici questo? Sei il capo del team, fai qualcosa al riguardo. Qual è il tuo piano?

In altre parole, vai dal tuo CTO e spiega il ritardo sottolineando il rendimento problemi nel tuo team non è la soluzione : non cambierà improvvisamente nulla o risolverà il problema. Hai bisogno di elaborare un piano d'azione, non solo di dire a qualcun altro che la persona ha un rendimento scarso. Sì, potresti voler comunicare il fatto che ha una performance scadente, ma la comunicazione è solo una parte del processo, non è la cosa che farà sparire tutto questo.

Suona come te " ho già svolto un lavoro poco convinto dicendole che ha bisogno di conoscere questi argomenti. Potresti riflettere su alcune altre opzioni:

• Aspettarsi che un dipendente impari nel proprio tempo non è sempre fruttuoso, come hai visto. Hai l'opportunità di integrare la formazione nel suo orario di lavoro? Avendo qualcuno che la guida o la formi? O lasciare che il "tempo di sviluppo" possa concentrarsi sull'apprendimento?
• Aspettarsi che un dipendente sia in grado di svolgere un buon lavoro in una tecnologia con cui non ha familiarità non è sempre fruttuoso. Alcuni sviluppatori possono facilmente acquisire nuovi linguaggi o piattaforme, altri hanno difficoltà e vengono trattati meglio come "esperti" in un ambiente specifico. Se è il caso di questa donna, devi decidere se la tua azienda ha bisogno di un esperto in Java o se hai bisogno di qualcuno che sia flessibile. Non è intrinsecamente un problema che sia una cattiva sviluppatrice, potrebbe semplicemente essere che non è il tipo di cui hai bisogno.
• Assicurati di comprendere l'approccio del tuo datore di lavoro alla gestione delle prestazioni. Se il dipendente non è in grado di svolgere il lavoro come delineato nella descrizione del lavoro, potrebbe essere necessario iniziare a intraprendere azioni più formali. La chiave quando ciò accade è seguire la politica (cioè il tuo dipartimento delle risorse umane ha un processo formale di miglioramento delle prestazioni?) E documentare ogni piccolo dettaglio, in modo da avere un buon supporto se arrivi al punto di decidere di lasciarla andare perché non è una brava in forma.

Una cosa difficile da comprendere per alcuni leader neopromossi è che il tuo lavoro non è quello di essere un esperto dei compiti che svolge il tuo team. In molti ambienti, il tuo lavoro consiste tanto nella gestione delle persone quanto nella gestione del lavoro. Questo è un problema delle persone. Sì, potrebbero essere le sue scarse capacità a causare ritardi nel lavoro, ma dal punto di vista del datore di lavoro, questo è tanto il tuo problema quanto il suo.

Ma non conosce nemmeno le basi di HTML e CSS. Gli ho detto di studiare queste materie a casa dalla Codeacademy durante il fine settimana / le vacanze.

Enorme bandiera rossa.

Tu (o la tua azienda, ma dato che sei il comando, è una tua responsabilità) mettilo in un lavoro che necessita di competenze che non ha. Devi addestrarlo durante l'orario di lavoro se è necessaria la formazione . Se ha mentito sulle sue capacità, licenziatelo, ma se era chiaro che conosceva solo Java, allora ti sbagli.

La soluzione è abbastanza semplice: permettigli di studiare queste materie al lavoro e non fare nulla altro lavoro correlato durante un time box ben ponderato (due o tre giorni per un ingegnere del software, forse di più per sviluppatori meno laureati).

Non ripeterò l'eccellente risposta di dwizum, ma ho alcune cose da aggiungere:

Il suo problema principale è che non fa il lavoro in modo logico ma ci prova sempre alcune permutazioni e combinazioni casuali per rendere il suo colpo di fortuna un tentativo riuscito di fare il lavoro.

Hai provato a mostrargli strategie di problem solving più efficaci? (Sì, idealmente un laureato saprebbe "lavorare logicamente", ma le strategie di problem solving di solito non fanno parte del curriculum formale e talvolta non vengono insegnate come dovrebbero).

I gli ha persino detto di cercare su Google un concetto che non conosce, ma non è nemmeno bravo a cercare su Google

Hai provato a mostrargli come usare Google in modo efficace?

Nota inoltre che sarà difficile per uno sviluppatore Java individuare i problemi di Google Angular, poiché il linguaggio di programmazione, gli strumenti di compilazione e l'ambiente di runtime sono completamente diversi. Comprendere un post sul blog casuale di uno sviluppatore JavaScript è difficile se non conosci le tecnologie web.

Verifica le tue aspettative

Ho speso l'ultima un paio d'anni di coaching hanno sperimentato team Java nei loro primi progetti angolari. Nella mia esperienza, solo il 20% circa degli sviluppatori è stato in grado di effettuare questo passaggio senza aiuto. E sì, anche se tutti hanno frequentato un corso professionale di angular e hanno avuto accesso a un aiuto esperto, i progressi sul primo progetto angular sono stati abbastanza lenti da innervosire la direzione.

Sì, gli sviluppatori veramente bravi possono imparare una nuova lingua senza alcun aiuto, ma la maggior parte degli sviluppatori avrà bisogno di più aiuto di "hai bisogno di imparare le basi".

Devi fare il tuo lavoro.

Dal lato del team, decidi se è fattibile fare da mentore a chi ha meno prestazioni o meno. Se pensi che siano disposti a imparare e in grado di essere produttivi e le prestazioni a lungo termine del tuo team sono più importanti dei costi a breve termine di un mentoring, allora decidi di fare da mentore e informare il team. Assegna loro compiti realistici in base al loro livello di abilità e rivaluta periodicamente per vedere se il mentoring funziona.

Dal lato CTO, devi informare realisticamente il tuo CTO delle capacità del tuo team. Se cerca di dirti che il compito è facile o che chiunque può imparare, rispondi come segue:

1. Stai gestendo il team in modo appropriato, date le risorse disponibili. Se ha consigli specifici su come puoi gestire il team in modo appropriato, saresti felice di ascoltarlo.

2. Il team si sta comportando così. Non sta facendo il lavoro più velocemente di quanto non sia. Non esiste una frusta magica che puoi rompere. I tuoi dipendenti hanno la produttività che hanno e tu non puoi magicamente renderli più produttivi.

3. Spiega i tuoi consigli sul membro del team con prestazioni insufficienti. Spiega che hai deciso che ha più senso impegnarti a farli da mentore anche se ciò ha un costo a breve termine o chiedi che vengano licenziati. Se pensi che sostituirli possa aiutare, spiegalo.

In definitiva, devi dire al CTO che credi di guidare il team in modo appropriato, ma che le prestazioni del team sono non sufficiente per svolgere i compiti richiesti nei tempi desiderati. Offri opzioni utili come assumere più persone, ridurre il set di funzionalità e così via. Spiegagli che chiederti di produrre un risultato migliore non cambierà la tua valutazione di ciò che la tua squadra è realisticamente in grado di ottenere.

Qualunque cosa tu faccia, non essere d'accordo con le sue affermazioni secondo cui il team può produrre di più e quindi ripetere il ciclo di fornire meno di quanto il CTO si aspetta seguito da promesse rituali non realistiche di fare meglio in futuro.

Gli altri commentatori hanno ragione: è tua responsabilità assicurarti che questo sviluppatore sia in grado di sviluppare in Angular (perché è stato assegnato questo compito sapendo che il loro background è in Java).

Anche io devo risolvere il 90-95% dei suoi compiti da solo e poi lui impara

NON risolvere i compiti assegnati a questa persona per loro - è ostacolante il loro processo di apprendimento. Se non sono in grado di gestire il carico di lavoro e alla fine stai completando le attività per loro, PRIMA di parlarne con il tuo CTO, ti suggerirei:

1. di fornire loro un tutorial di base su Angular (magari concentrarti su sulle cose che utilizzerai)
2. Riduci la quantità di attività assegnate loro (qualunque carico di lavoro abbiano attualmente suona come troppo in questo momento )
3. Non risolvere i loro compiti per loro, dare loro un feedback in modo che possano tornare indietro e correggere gli errori / fare il lavoro (capiranno il flusso del loro codice meglio di te)
4. introdurre la doppia codifica / shadowing / revisione del codice tra i tuoi sviluppatori in modo che imparino gli uni dagli altri (meno interferenze da parte tua)

Come qualcuno che si trova in una posizione simile, questi passaggi (specialmente 3 & 4) sono stati utile per convincere quel dipendente a essere più forte in un'area in cui all'inizio non si sentiva a suo agio. Invece di scaricare la colpa sul dipendente "con prestazioni insufficienti", dovresti chiedere perché è stato assegnato a questo progetto dato il loro background, o, se in qualsiasi momento erano consapevoli che il loro lavoro richiedeva loro di imparare un ambiente completamente nuovo.

In qualità di guida di una squadra, ci si può aspettare una certa quantità di gestione delle prestazioni del resto della squadra.

Sembra che finora tu abbia fatto una quantità abbastanza minima di questo, principalmente dicendo loro di studiare a casa o di cercarlo su google. E finora ciò non ha avuto particolare successo, probabilmente perché sono approcci piuttosto inutili per aiutare un nuovo membro del team di livello iniziale a iniziare.

Penso che l'unica soluzione che mi rimane con è quello di raccontare al CTO di quella ragazza e delle sue abitudini di lavorare con stime approssimative in modo che possa decidere se è pronta a lavorare o no.

Alla fine si potrebbe arrivare a quello, ma se fossi al posto del tuo CTO, ti cercherei di assumere un ruolo più proattivo nel tentativo di risolvere il problema prima che tu me lo chieda.

Metti da parte il membro del team in difficoltà e fai una conversazione con loro, vedi se puoi a) arrivare alla radice del problema eb) lavorare per migliorarlo.

Non è necessario essere grossi, urlanti e aggressivi: un buon leader di squadra dovrebbe facilitare il lavoro senza dominare con il pugno di ferro.

Sembra che tu stia lottando con alcuni degli elementi su cui stiamo lavorando in questo momento s o come posso aiutare? Puoi dirmi perché stai lottando? C'è qualcosa in particolare su cui ritieni di aver bisogno di aiuto?

Spero che tu possa quindi lavorare con il membro del team per migliorare le cose, ma alla fine potrebbe non funzionare su. Quindi puoi considerare di parlare con il CTO e dire qualcosa del tipo:

[Il membro del team] fa davvero fatica a cogliere alcuni elementi chiave del lavoro. Ho parlato con loro e abbiamo fatto X, Y e Z per cercare di migliorare la situazione, ma non è stato di grande aiuto e sono preoccupato che stia influenzando la capacità di portare a termine il lavoro del nostro team.

Ecco il tuo problema: il tuo team non è in grado di svolgere il lavoro che dovrebbe svolgere nel tempo che ti è consentito. Il fatto che uno dei tuoi colleghi abbia un rendimento scarso è secondario. È un problema per loro, potrebbe portarli a perdere il lavoro nel peggiore dei casi, ma il tuo problema è che il lavoro non viene svolto.

Ci sono due soluzioni al tuo problema: migliorare il lavoro del tuo team o chiarire alla direzione che il tuo team non è in grado di fornire risultati e che non è colpa tua. Dovresti lavorare su entrambi.

Per prima cosa, parli con quel collega, gli dici che la squadra è in pericolo, e quindi loro sono in pericolo e il loro lavoro deve essere migliorato. Il miglioramento può essere fatto solo imparando. Dai loro tempo al lavoro per imparare (è più efficiente per loro imparare che fare un lavoro scadente che deve essere rifatto). Di 'loro di chiedere aiuto immediatamente se non sanno come continuare, perché 5 minuti di aiuto possono smettere di sprecare due ore di lavoro.

Per il secondo, dì al tuo manager che questo collega non è all'altezza. Spiega loro quali misure stai prendendo per migliorare le cose. Spiega loro che con dipendenti competenti svolgeresti i tuoi compiti (se ciò è effettivamente vero), ma al momento non hai questo e ti ci vorrà del tempo per arrivarci. Se qualcuno pensa che ci vogliano solo ore per imparare i CSS, ad esempio, puoi dirgli che sei rispettosamente in disaccordo e, indipendentemente dal fatto che tu sia d'accordo o meno, hai un dipendente che non lo sta imparando in poche ore.

Puoi suggerire di sostituire la persona del team, che non sta realmente gestendo il tuo problema.

1) Il personale delle risorse umane / assunzioni lascia cadere la palla se assume persone che non soddisfano nemmeno i requisiti minimi di abilità per il lavoro. IE: se ha bisogno di conoscere HTML, Angular, ecc. Allora la descrizione del loro lavoro avrebbe dovuto dirlo. Se è stato assunto senza quelle abilità, significa che la loro descrizione del lavoro era pessima (che è sulla persona tecnica nel tuo dipartimento che stava dicendo loro quali abilità erano necessarie), o su di loro (assumere qualcuno senza essere rigorosi sulle abilità necessario ... alcuni folsk delle risorse umane non tecnologici pensano "oh, questo ragazzo è un programmatore può programmare qualsiasi cosa" .. e assumono una persona che conosce SQL per fare lavori Java ... la persona non tecnologica non ha idea .). In ogni caso, parla con le risorse umane e chiedi loro di agire insieme.

2) I neolaureati sono colpevoli. La maggior parte sta cercando di imparare sul lavoro al loro primo concerto, e poi abbandonare la nave dopo un anno di "esperienza" per trovare un lavoro migliore (b / c quando si diplomano per la prima volta, è tutto su quanto velocemente possono ottenere più soldi .. b / c i prestiti agli studenti non si ripagheranno da soli, e vivere a mani nude al college li ha resi motivati ​​dal denaro).

Devi davvero valutare il lungo periodo del laureato potenziale termine per vedere se vale la pena addestrarli sul posto di lavoro (e sarà una formazione sul posto di lavoro, come altri hanno sottolineato .. i programmatori davvero motivati ​​faranno cose nel loro tempo libero per imparare e rimanere al passo con tendenze ... ma alla fine stiamo parlando di un lavoro qui e le persone vogliono un compenso per le loro capacità che apprendono e per il lavoro che svolgono.)

Ancora una volta, le persone delle risorse umane avrebbero dovuto valutare la fattibilità a lungo termine della persona con domande BS come "dove ti vedi tra 5 anni?"

Ma dovresti solo avere un cuore a cuore con il candidato. Se sembrano umili e davvero motivati ​​a voler fare un buon lavoro e farti piacere .. allora devi addestrarli e metterli al passo .. b / c le probabilità sono buone che rimarranno a lungo termine e diventeranno un risorsa preziosa.

Se si comportano in modo presuntuoso o distaccato o non sembrano preoccuparsi di rimanere indietro ... salteranno rapidamente dalla nave. Sei solo un trampolino di lancio per loro da usare mentre si dirigono verso un altro posto.

Quindi, siediti con loro per mezz'ora o un'ora a chattare nel tuo ufficio e chiedi loro "dove vedi questo lavoro andare? " "dove ti vedi tra 5 anni" ecc, ecc, ecc ... guarda cosa pensano. Sanno già cosa stai pensando (stai pensando di aver bisogno di qualcuno che possa produrre in questo momento).

Ma i programmatori sono lavoratori della conoscenza di fascia alta. Non è come il lavoro di scavo di fossi, dove un buon scavatore di fossi è migliore dell'1,05% rispetto a quello medio. Un buon programmatore può essere molte volte più produttivo di un programmatore avg. Se questo neolaureato ha le materie prime per essere un buon programmatore (veloce da imparare, motivato a lavorare, buone capacità di problem solving ... non importa quali lingue conoscono se non hanno una motivazione alla radice da fare tipo di programmazione) .. allora sono un diamante grezzo in attesa di essere lucidato.

La preoccupazione più grande è che sei bloccato con un programmatore proveniente da CS o IS perché sono entrati nella laurea programmi per soldi, non per passione. Sono in un programma MIS al college in questo momento con il 90% di studenti indiani ... circa 2/3 di loro NON vogliono essere lì, ma sono lì perché la loro famiglia li ha spinti a farlo. Non si preoccupano della programmazione, della gestione dei dati, dei sistemi informativi, dell'analisi ... per loro è solo un lavoro e fanno il minimo indispensabile per cavarsela in classe (a volte imbrogliano gli altri) e vogliono solo entrare nel mondo del lavoro e andare avanti con la vita e guadagnare soldi. Sarà solo un lavoro per loro. Parlo con alcuni, e sono pronti a dire come preferirebbero essere nel campo dell'arte, della letteratura o delle scienze sociali, ma la loro famiglia li ha spinti a una carriera di alto livello (produttori di denaro STEM ... medicina, tecnologia, ecc. .. non scienze sociali).

Quindi, devi valutare se il tuo ragazzo sta facendo un lavoro a cui è appassionato o se è solo un modo per lui di guadagnare denaro.

Probabilmente ha interagito con gli altri membri del team. Ottieni la loro valutazione ... la loro valutazione sociale ... sanno già che gli mancano le competenze. MA, se sentono che è un giocatore di squadra, risolutore di problemi, ecc. Allora ha del potenziale.

ES: a volte va bene avere un "programmatore fannullone" nel gruppo se sono un grande problema risolutore che fa pensare agli altri in modo diverso. Le altre persone faranno rimbalzare idee su di loro, e il "fannullone" può dare loro buone idee con cui funzionano e produrre un lavoro eccellente. Ma, senza quel "fannullone", gli altri programmatori sono solo macchine di codifica senza idee veramente buone per codificare. Chiunque può creare codice. Non significa che sia buono. Non significa che risolva un problema in modo elegante o innovativo. La persona fannullona può avere idee sorprendenti, semplicemente prive delle capacità di programmazione e della velocità per metterle in atto. Una persona "fannullona" può anche essere una spinta morale per il resto della squadra se è simpatica e lavora bene con gli altri. Non tutti i programmatori possono essere una rockstar che lancia codice come scatole in una fabbrica.

Quindi, darei al ragazzo una valutazione sociale per vedere se vale la pena sprecare tempo in azienda per allenarsi. Se non è motivato, non è un giocatore di squadra e non si preoccupa ... saltalo e assumi qualcun altro. Non ha senso addestrare qualcuno solo per vederlo prendere tutto ciò che gli hai dato per un lavoro diverso 6 mesi - 1 anno dopo.

Come altri hanno già sottolineato, i tuoi problemi si riducono al fatto che non ti è consentito impartire una formazione adeguata ai tuoi dipendenti. Dovresti trovare un modo per dimostrare ai tuoi superiori che la mancanza di formazione è costata più ore di quante ne sarebbero occorse per addestrarli . In altre parole, trascurare di addestrarli correttamente danneggia l'azienda.

Non fare il lavoro dei tuoi subordinati per loro. Se qualcosa non va a buon fine, assegna l'attività a qualcun altro. In questo modo dovrebbe diventare evidente quanti compiti le persone svolgono in un dato periodo di tempo. Ora puoi approssimare le ore di lavoro perse a causa delle differenze di abilità.

Oltre all'introduzione tecnica di base, potresti suggerire di utilizzare il pair programming per aiutare con le differenze di abilità. Ciò fungerebbe anche da misura di controllo della qualità, nel caso in cui siano necessari ulteriori argomenti per vendere questa idea al CTO.

Note a margine: ho dovuto imparare nuove tecnologie nel mio precedente posto di lavoro, inclusi due linguaggi di programmazione completamente diversi. Sebbene i capi fossero degli idioti quando si trattava di spendere soldi, dedicavano comunque risorse all'apprendimento di queste lingue, inclusi gli ebook e ci hanno dato il tempo per implementare grandi applicazioni tutorial - al lavoro.

Stupida analogia: non assumeresti camionisti e chiederesti loro di imparare a guidare i treni nel loro tempo libero.

Non sono d'accordo con alcune delle risposte sopra elencate, in particolare con l'aspettativa che John impari Angular / CSS / HTML durante l'orario lavorativo.

Nello specifico, il campo della tecnologia è un campo vasto, ed è un campo in continua evoluzione. Angular è nato nel 2010 - Sono un Web Engineer dal 2003. Quando ho iniziato Angular non era una cosa. Perché sono ancora rilevante nel mio campo? Perché ho fatto della mia priorità stare al passo con le novità del settore e mantenere le competenze attuali nelle aree pertinenti.

Non penso che dovrebbe essere sempre necessario al 100% per apprendere nuove abilità per il lavoro nel tempo dell'azienda, e non penso che l'azienda sia obbligata a darti quel tempo per imparare. Se vuoi rimanere aggiornato, se vuoi rimanere aggiornato, se vuoi rimanere rilevante e, a volte, se vuoi mantenere il tuo lavoro, devi controllare te stesso, le tue abilità e il lavoro che hai e assicurarti che sono una partita.

Ho iniziato a scherzare con la progettazione di siti Web di mamma Podunk e pop, e ora sto lavorando a un team di intelligenza artificiale in cui ho contribuito notevolmente alla direzione e allo sviluppo della loro tecnologia stack, gestendo un ambiente AWS che non esisteva quando ho iniziato.

Non ho ottenuto quel lavoro dicendo alla mia azienda che avevano bisogno di darmi il tempo di apprendere quelle abilità mentre ero al lavoro.

I bravi sviluppatori e, cosa più importante, i bravi ingegneri sono appassionati di padroneggiare il proprio mestiere e capiscono che ciò significa che più delle 40 ore settimanali di cui hanno bisogno hanno bisogno per essere più immersi nella tecnologia richiesta da usare giorno per giorno.

Questa è la conversazione che avrei avuto con John - e se non avesse espresso inte riposare o tentare di migliorare, non gli offrirei un trasferimento lo libererei. Gli sviluppatori senza la passione di crescere da soli non saranno mai niente di più di quello che sono quando li hai assunti.

La mia risposta non sarà popolare ... Dai opportunità a John, proponi anche una formazione retribuita se necessario, ma lascia che fallisca quando sarà il momento.

Sembra che qui ci siano molte cose molto sbagliate :

• Stai consentendo a qualcuno di rimanere nella tua squadra, che non è qualificato per essere presente
• Quella persona sta derubando qualcun altro che potrebbe essere un membro produttivo ;
• Stai danneggiando il tuo stesso lavoro prendendoti tempo per fare il lavoro di John
• Stai portando il morale basso alla squadra - se John non ha bisogno di esibirsi, perché dovrebbero
• Stai costruendo una serie di lavori comprovati per essere più difficile licenziare John nel presente e nel futuro.

Non stai cercando i tuoi interessi nel breve termine che fa il lavoro di John, e molto meno per gli obiettivi del tuo team a lungo termine.

Se fossi un tuo subordinato, non mi aspetterei che tu facessi il nostro lavoro, ma mi aspetterei che ti occupassi con i capi e sbarazzarsi di un membro della squadra che non può contribuirvi.

A breve termine, dato che hai quella persona, puoi assegnare a John in parte aiuto sulla documentazione e altra parte della giornata / settimana per studiare durante l'orario di lavoro.

Lo farei definire anche tempi e obiettivi. Un tirocinante / assunto dall'università deve fare uno sforzo onesto nei primi mesi e mostrare interesse e un po 'di intelligenza, essere minimamente competente dopo sei mesi e minimamente produttivo per il team intorno ai 9-12 mesi. Di solito anche le persone saranno solo moderatamente competenti su un nuovo ambiente / lavoro, a seconda della complessità, dopo 1 anno a 1 anno e mezzo, al massimo due anni. Il tuo CTO dovrebbe saperlo, o molto probabilmente lo sa, ma vuole solo che tu ottenga il massimo dalla squadra che ha nelle sue mani. I fattori di costo potrebbero giocare una mano su questo.

PS. Ho visto in passato persone al posto di John, che dopo 2 anni di "aiuto" si lamentavano che era giunto il momento di ottenere una promozione ... uno dei casi era sui venticinque anni e si lamentava di non avere un aumentare i tempi in cui non dormiva sul lavoro es quando sveglio. Tornando al caso specifico di John, cercherò di essere sicuro di capire se lo sforzo è genuino, o se pensa ancora di potersela cavare fingendo di lavorare come se fosse ancora all'università. Potrebbe succedere che John non sia abbastanza maturo da capire che ora è nel mondo reale e questo potrebbe spiegare bene la performance irregolare di cui parli.

Quello che stai cercando di fare mostra che non capisci la differenza nel set di competenze del tuo personale e ciò che è necessario.

Uno sviluppatore Java, se non ha esperienza nello sviluppo web, non ha alcuna comprensione del lato client e lato server delle cose.

Il paradigma è diverso da uno standalone Java. Anche se ha lavorato su applet java, sta ancora programmando all'interno di una VM autonoma, non in una in cui un client parla con un server.

Ad esempio, qualsiasi tipo di controllo degli errori sul lato client sono superficiali e vengono semplicemente utilizzati per ridurre i colpi sul server. NON si suppone di fare affidamento, perché bypassare la convalida lato client è assolutamente banale . Qualcosa come un "nome utente", i controlli di base lato client non saranno vuoti e questo è tutto, forse aggiungere una combinazione di requisiti alfanumerici, ma potrebbe anche non funzionare a causa della necessità di supportare lingue diverse.

Sul lato server, controllerò che non sia vuoto e anche qualsiasi tipo di dati che non posso gestire (al di fuori di UTF-8 per esempio), quindi controllerò anche gli attacchi SQL injection (le istruzioni prepare lo risolveranno, ma Voglio rilevarlo e possibilmente inserire nella blacklist l'IP) e probabilmente registrare ripetuti tentativi di traffico di grandi dimensioni per impedire accessi dannosi (hacking, creazione di un nome utente di massa, squat del nome utente, ecc.). Tutte queste opzioni sono solo lato server.

Quindi vuoi anche pensare a come il client comunica con il server e se sarà appropriato entrare in AJAX per una migliore esperienza utente. Tutta questa conoscenza non è banale e un CTO è piuttosto stupido aspettarsi che uno staff possa imparare tutto questo in un paio di mesi.

Penso che ti stiano perdendo le parti fondamentali di ciò che significa essere un team leader. Fare da guida ai membri del tuo team in modo che diventino migliori fa parte del tuo lavoro. Dare loro il supporto per avere successo fa parte del tuo lavoro.

Ad esempio, offri al tuo membro del team junior un esercizio di formazione affinché impari. Dagli quello che pensi sia la giusta quantità di tempo, o meglio ancora, chiedigli quanto tempo ha bisogno. Se il CTO ha un problema con esso, difendilo. Il team conta su di te per proteggerli e guidarli.

Inoltre, non ho il potere di assegnare loro semplicemente il compito di formazione o il compito effettivo del progetto. Faccio ciò che il mio CTO mi ha detto di fare e ogni volta che ho deciso di fornire loro formazione da solo, il CTO mi dice ogni volta che "imparare HTML, CSS, JavaScript non è qualcosa per cui devono dedicare mesi. Insegna loro le basi in 4 ore e dai loro un giorno per svolgere un compito semplice e poi saranno tutti pronti per il progetto. Resto impareranno mentre fanno il progetto. Non abbiamo molto tempo da dedicare alla loro formazione . "

Non lo compro. Se sei il loro leader, hai assolutamente il potere di aiutarli ad avere successo. Se il tuo CTO ti dice di fare diversamente, allora questo è un problema tra te e il tuo CTO. Lascia fuori il tuo membro del team. Il tuo lavoro è aiutarlo. Educa il tuo CTO. Devi tenergli testa. Ecco perché adesso sei pagato un sacco di soldi.

A volte i manager si sbagliano. A volte i manager hanno aspettative irrealistiche. Soprattutto CTO. I CTO vogliono tutto, lo vogliono adesso, lo vogliono perfetto e vogliono che non costi nulla. Si affidano a te per spiegare loro come funziona effettivamente.

Devi mostrare al tuo CTO il compromesso tra il dare a questo dipendente il tempo necessario per imparare, ovvero:

1. Meno tempo disponibile per la creazione di funzionalità ora, ma più capacità in seguito.
2. Più tempo disponibile ora, ma non verrà eseguito in tempo o con la qualità corretta.

Si tratta di prevedibilità e velocità. Non solo per il singolo, ma a livello di squadra. Se ogni membro del team deve continuare ad aiutare questa persona perché non sa come fare il proprio lavoro, allora il colpo di produttività è di tutti.

Mostrare i fatti al tuo CTO in questo modo 1) lo persuaderà / lei 2) dimostra la tua competenza, quindi probabilmente si tireranno indietro e ti lasceranno fare le cose a modo tuo.

Secondo me, il tempo per coinvolgere il tuo CTO La decisione sulle prestazioni di questo dipendente è se hai esaurito i tuoi sforzi e credi che questa persona non avrà mai successo nella tua squadra. Dovrebbe essere l'ultima risorsa. Non vuoi che gli altri membri della tua squadra si preoccupino costantemente che tu li getti sotto l'autobus quando qualcosa va storto. Devi proteggere la tua squadra. Licenziare o rivolgersi al tuo capo, che probabilmente è più o meno la stessa cosa, dovrebbe essere l'ultima risorsa assoluta.