Come gestire uno sviluppatore che ha scarse capacità comunicative

Gestisco un piccolo team di sviluppatori su un'applicazione che si trova a metà del suo ciclo di vita, all'interno di una grande azienda. Questo purtroppo significa che esiste comunemente una suddivisione 30/70 delle attività di programmazione in "altri lavori tecnici". Questo lavoro include:

• Lavorare con i team DBA / Unix / Network / Loadbalancer su varie attività
• Effettuare e gestire ordini per hardware o infrastruttura in diverse regioni
• Esecuzione di test che non sono stati ancora migrati in CI
• Analisi
• Supporto / indagine

È giusto dire che gli sviluppatori preferirebbero tutti programmare, piuttosto che svolgere questi compiti più banali, quindi provo a distribuire i divertenti lavori di programmazione in modo uniforme tra il team.

Gran parte del team è stato assunto perché, sebbene non abbiano le capacità di programmazione d'élite per scrivere il proprio compilatore / motore di gioco / sistema di trading ad alta frequenza ecc., Sono buoni comunicatori che "possono fare cose", lavorare con altri team e in qualche modo navigare nella complessa burocrazia qui. Sono buoni sviluppatori, ma sono anche un buon personale tecnico a tutto tondo.

Tuttavia, un membro del team ha probabilmente capacità di codifica superiori alla media, ma capacità di comunicazione inferiori alla media. Tradizionalmente, il precedente responsabile dello sviluppo tendeva a assegnargli le attività di programmazione e non quelle più banali sopra elencate. Tuttavia, non ritengo che ciò sia corretto per il resto del team, che ha mostrato un'attitudine per lo sviluppo di un insieme di competenze completo che è comunemente richiesto in un dipartimento IT di grandi aziende.

Cosa dovrei fare in questa situazione? Se continuo a dargli più lavoro di programmazione, so che sarà fatto più velocemente (e al contrario, mi aspetterei che completasse l'altro lavoro più lentamente). Ma va contro i miei principi e promuove l'idea che puoi ritagliarti una "nicchia confortevole" semplicemente facendo il cattivo con i compiti che non ti piacciono.

Voglio chiarire che non sto cercando di affrontare questo problema a causa di un rancore, o che ho un "chip sulla spalla", come è stato menzionato. Sto cercando consigli su come mantenere una squadra a tutto tondo, che è felice e motivato. Osservando la varietà di risposte a questa domanda, sembra che ci siano molte opinioni diverse su come raggiungere questo obiettivo.

Sembra che tu stia facendo troppi sforzi per avere individui a tutto tondo e non abbastanza per avere una squadra a tutto tondo .

Non c'è niente di sbagliato nell'essere bravo in qualcosa - in effetti, probabilmente è per questo che è stato assunto! Dovresti essere grato di avere qualcuno che è bravo a programmare per cominciare.

Hai dichiarato:

... va contro i miei principi e promuove l'idea che puoi ritagliarti una "nicchia confortevole" semplicemente facendo il cattivo con i compiti che non ti piacciono.

Se fosse un programmatore mediocre, sarei d'accordo. Ma non l'hai detto. Hai detto che era un buon programmatore. Non è cattivo con gli altri compiti per uscirne - si limita a concentrare i suoi sforzi per diventare un programmatore migliore. Non c'è niente di sbagliato in questo.

Come manager, non è tuo compito assicurarti che tutti siano "ben arrotondati". È tuo compito assicurarti che s *** sia fatto. E non lo stai facendo. In effetti, stai prendendo decisioni che impediscono di fare le cose.

Qualunque problema tu abbia, devi superarlo - stai rendendo la tua squadra meno produttiva.

Stai prendendo un po 'di calore qui nelle altre risposte per la tua decisione di "fare qualcosa" per questo ragazzo, ma ho capito appieno quello che stai dicendo. Se gli altri membri del team "preferiscono tutti codificare, piuttosto che svolgere questi compiti più banali", saranno infastiditi dal fatto che stai ricompensando le cattive prestazioni del povero comunicatore dandogli solo i compiti che tutti vogliono.

Immagina di essere uno dei "bravi comunicatori" della squadra le cui abilità sono paragonabili al dev in questione. Gestisci le chiamate, lavori con altro personale non IT che conosce a malapena un mouse da una tastiera, elabora piani per la disconnessione dell'utente e altro ancora, tutto perché il tuo capo dice di farlo. Lo scontroso dev, nel frattempo, perché ha "scarse capacità comunicative", riesce a sedersi tutto il giorno nel suo cubo ignorando gli utenti che lavorano solo su cose "divertenti".

Ora hai detto che lo scontroso devoto ha abilità "sopra la media", ma non hai detto che era il migliore. Ciò significa che forse 1/3 della tua squadra, quei bravi sviluppatori di comunicatori che sono il livello di abilità dello sviluppatore scontroso o superiore, si sentono tutti incazzati.

Vale la pena perdere un po 'di produttività dal tuo MIGLIOR PERSONALE PERFORMANTE perché sono infastiditi dal burbero-dev? Dovrai decidere.

A meno che tu non voglia licenziare il ragazzo, ti suggerisco di adottare uno di questi approcci:

1) Mentor per essere un comunicatore migliore. Solo tu puoi dire se questo è fattibile. Potresti scoprire che tenerlo un po 'di più potrebbe aiutare. Alcune persone sono terrorizzate dalle interazioni commerciali formali ed esprimono il fatto di essere incazzate quando gli viene chiesto di farlo.

2) Incentivare la "buona comunicazione", con denaro o altri benefici. Metti in chiaro che apprezzi davvero i buoni comunicatori e quindi i tuoi sviluppatori non saranno così infastiditi, ma la ricompensa deve essere reale e significativa. "Il pranzo con il direttore del distretto" non lo taglierà. Nemmeno un premio "star player / kudos / attaboy" è solo un pezzo di carta. Devono essere soldi extra, ferie extra, un po 'di tempo flessibile, qualche riconoscimento serio con i superiori che controllano gli aumenti salariali, ecc

Prima di tutto, dare la colpa ai membri del tuo team ... denota scarse capacità manageriali.

Voglio dire, se ha davvero scarse capacità comunicative, mi dispiace molto per la sua vita sociale, ma davvero, sul lavoro questo non è tanto un suo problema quanto un tuo . E ammettiamolo, in realtà potrebbe essere annoiato dal tuo noioso ambiente di lavoro, o avere problemi privati ​​che influenzano la sua performance, o essere segretamente complotto per ucciderti tutti.

La comunicazione richiede almeno due, e dopotutto, quello con le abilità dei poveri potresti essere tu. Non importa che il resto dei membri del team vada d'accordo abbastanza bene, potrebbero tutti compensare (anche inconsapevolmente) per qualche carenza di comunicazione che hai e ignorare beato.

E comunque, non andare in giro a chiedere a Internet di persone che sono seduti a tre scrivanie da te, vai al ragazzo e chiedigli se c'è davvero qualcosa che non va e se può essere risolto. (o qualcosa di noioso che può essere ottimizzato o migliorato)

Forse odia solo la sua posizione sulla scrivania (sta affrontando i bagni?) E questo lo mette di cattivo umore.

Suggerimento: ascolta la risposta, come se fosse un essere umano senziente, non una risorsa umana.

(ad esempio: prova a spiegargli in dettaglio la necessità di determinate pratiche e il significato di determinate decisioni, alcune persone scavano dettagli, dato che danno loro la sensazione di avere un capitano che non sta guidando la nave verso le scogliere)

Le persone sono diverse. Come manager, devi trattare le persone in modo diverso (ma equamente!) Per ottenere il massimo dalla tua squadra.

Detto questo, è probabilmente utile per lo sviluppatore con scarse competenze trasversali lavorare su di essi. Vorrei scoprire quale cosa non codificante piaccia (o che vorrebbe fare) allo sviluppatore che coinvolge più di quelle soft skills. Coinvolgili in tale compito e idealmente miglioreranno le abilità trasversali come effetto collaterale.

Le persone spesso non sono cattive in qualcosa per uscire dal lavoro; sono cattivi perché non gli piacciono o hanno un'attitudine per questo. Non puoi aiutare il secondo, quindi lavora sul primo.

La divisione 30/70 potrebbe essere il punto in cui iniziano tutti i problemi. Non ho mai visto sviluppatori contenti di dividere in quel modo.

Ho visto gli sviluppatori sentirsi a proprio agio con il 10, il 15% di altri lavori (e sono stato felice anche io perché è divertente quando la dose è giusta) ma il 30% è troppo. Preferirei che altri membri del team preferissero non esprimere la propria opinione rispetto a chi non ama "il 30% di altri lavori".

Penso anche che sia importante adattare la tua "matematica della produttività" a cifre più realistiche. Non aggiungerà mai fino al 100% a causa di inevitabili perdite a "cambi di contesto".

• ^{30 + 70, che sommano fino al 100% di produttività quando si passa dalla programmazione ad altri lavori , non accadranno mai nella vita reale; è più probabile circa 20 + 50 o anche 20 + 40. I cambi di contesto sono particolarmente dolorosi per gli sviluppatori di software: se sei interessato, consulta questo articolo per una bella spiegazione del perché: NON svegliare il programmatore!
  I programmatori che apprezzano la loro produttività sarebbero naturalmente scontenti di perdite del genere.}

Per quanto riguarda l' esecuzione di test parte del lavoro, hai preso in considerazione l'idea di passarlo ai tester? Il fatto che i programmatori possano farlo (penso che qualsiasi programmatore esperto dovrebbe essere in grado di farlo) non significa che dovrebbero farlo . Anche i tester possono farlo, e lo fanno meglio, e non subiranno perdite di produttività a "cambi di contesto".

Un altro punto che mi fa domandare come si utilizzano le risorse di QA è la tua menzione di supporto / investigazione . Tester professionisti con cui lavoravo tendono ad avere "prima voce" in cose del genere.

• ^{Come ex tester, li capisco abbastanza bene - i problemi di produzione sono stati per me (come tester) una preziosa fonte di dati per conoscere la copertura dei test ("questo problema è stato adeguatamente coperto dai miei test?") E per prioritizzazione dei difetti ("ok, è stato coperto dai test e riportato prima del rilascio, ma allora ho impostato la priorità / gravità appropriata?").}

È abbastanza facile per un buon tester scoprire quando passare agli sviluppatori l'indagine sul problema del supporto e ciò non accade molto spesso. I motivi per sovraccaricare gli sviluppatori con questo semplicemente sfuggono alla mia mente. Come ho già scritto, sicuramente possono farlo (generalmente mi aspetto che uno sviluppatore senior sappia come fare qualsiasi cosa il QA), ma ciò non significa che dovrebbero .

Ho 2 cose da dire su questo

1. Hai reclutato un programmatore o uno sviluppatore di software?
   Quando stai prendendo in considerazione uno sviluppatore di software, tutte le cose che hai menzionato sono parte integrante dello sviluppo del software. Non puoi ignorare nessuna di queste se non ti sei reclutato per un compito specifico. IMO Il 50% dello sviluppo totale del software è in codice, mentre tutto è progettazione, analisi, prove, documentazione, ecc.

2. Nessuno è nato perfetto.
   Non riesco proprio a trovare una persona brava in tutto. Devi farli lottare e far loro imparare le cose.

Come manager devi ottenere il meglio da loro, sono d'accordo, ma a lungo termine potresti incontrare dei problemi. Assegna loro compiti leggeri in modo che tendano ad afferrarli. Esci da loro la sensazione di non essere bravo in questo / non posso permettermi di farlo . Soprattutto trattate tutti allo stesso modo che otterranno il risultato più efficiente dal vostro team.

Se tutti i membri del tuo staff hanno lo stesso titolo / descrizione del lavoro e la descrizione del lavoro include tutto ciò che hai elencato, allora questo programmatore ha bisogno di affinare queste altre abilità assegnando più di queste altre attività non programmatore. Allo stesso modo, gli altri membri del personale non avranno le proprie capacità di programmazione affinate se devono lavorare continuamente su attività non di programmazione (utilizzarlo o perderlo).

Ma penso ancora che la tua priorità principale dovrebbe probabilmente rispettare le tue scadenze (cosa che potresti comunque riuscire a fare mentre distribuisci il lavoro in modo uniforme).

EDIT: Se hai una piccola squadra, probabilmente ha senso avere tutti i membri in grado di indossare più cappelli. Se hai una squadra abbastanza grande, probabilmente ha senso avere gruppi specializzati in diverse aree. Dal tuo post sembra che tu non abbia una squadra abbastanza grande per avere gruppi di specialisti.

Dal tuo post originale non è chiaro cosa manchi esattamente delle capacità comunicative di questo sviluppatore. Una mancanza di interesse nell'andare alle riunioni o svolgere attività di pianificazione / coordinamento (ad esempio) non indica necessariamente scarse capacità comunicative. Forse lo sviluppatore sente semplicemente che questo tipo di lavoro è un lavoro da manager e riduce la sua produttività come sviluppatore? O forse ritiene che ci sia un eccessivo sovraccarico organizzativo e questa è una forma di protesta contro ciò che ritiene sia solo tempo sprecato? Dopotutto, il problema opposto in cui le persone parlano tutto il giorno e non fanno mai nulla è abbastanza comune in ufficio.

È importante che parli con questo sviluppatore in modo non conflittuale e cerchi di capire perché evita i compiti di non programmazione. Probabilmente non è un singolo motivo, potrebbe avere tanti motivi diversi quanti sono i diversi tipi di attività. Assicurati che capisca che lo scopo della conversazione è in modo da poter imparare a migliorare efficacemente la produttività del team e la soddisfazione del lavoro per tutti i membri del team (non sei pronto a prenderlo). Questo è il momento per te di ascoltare, di non discutere o cercare di affrontare le sue preoccupazioni con reazioni istintive. Probabilmente dovresti anche incontrare gli altri membri del team, forse stanno benissimo nel lasciare che questo ragazzo faccia il lavoro degli sviluppatori pesanti mentre si concentrano sul lato più chiacchierone della professione.

Dopo questo incontro, passa un po 'di tempo a pensare alle conversazioni che hai avuto e prova a considerare la prospettiva di questo dipendente con una mente aperta. Forse i tuoi sentimenti iniziali erano corretti e gli mancano alcune abilità importanti che dovresti spingerlo a sviluppare. O forse ha fatto alcune valide sfide ai tuoi presupposti. Forse puoi lavorare con altri team per formalizzare alcuni processi e ridurre la necessità di comunicazioni ridondanti. Forse altre squadre non stanno tirando il loro peso e devi fare una chiacchierata amichevole con la loro gestione. Ci sono molte possibilità che potresti non prendere in considerazione.

Infine, e, soprattutto, avere una conversazione di follow-up con le persone o una riunione di gruppo, se appropriato. Se hai identificato problemi organizzativi reali che sono in tuo potere per influenzare, informa i tuoi dipendenti delle azioni che intendi intraprendere per migliorare la loro situazione lavorativa. Se ritieni ancora che il singolo dipendente abbia torto, siediti con lui e spiega quali cambiamenti hai bisogno da lui e perché. Gli sviluppatori tendono a rispondere bene alle spiegazioni logiche / pratiche. "Non è giusto per i tuoi colleghi darti tutto il lavoro divertente. Vorremmo che tutti voi fossero puri sviluppatori, ma questa non è la realtà della situazione, quindi dobbiamo condividere il peso del lavoro schifoso."

Certo, se questo ragazzo è solo un coglione scontroso, si rifiuta di dirti perché è infelice, non risponderà alla ragione e non è ben rispettato dai suoi colleghi ... beh ... è il momento del Piano di miglioramento delle prestazioni.

Anche se stai cercando di gestire una squadra e vuoi mantenere tutti motivati ​​(avere un senso di correttezza aiuta), ma stai sacrificando il progetto non avendo la tua migliore programmazione programmatore? Voglio dire, non è questo il punto.

Non hai paura di sottoutilizzare e / o rischiare di perdere il tuo miglior sviluppatore? Il tuo compito è cercare di alleviare questo tipo di doveri da tutti.

Essere trattati allo stesso modo non significa che trattate tutti allo stesso modo. Se gli altri vogliono allentare i compiti di non programmazione per poter assegnare più compiti di programmazione, non corrono il rischio di essere bravi in ​​nessuno dei due?

EDIT: Oltre ai tuoi sentimenti personali, non hai identificato un problema. Ad un certo punto la mancanza di comunicazione ostacola un programmatore. Altri mostreranno risentimento e il loro lavoro potrebbe risentirne. Finora, sembra che tu sia l'unico ad avere un problema. A meno che non ci sia qualcos'altro che non stai condividendo?

EDIT 2 Alla fine, tutti chiederanno un favore speciale. Questa persona fa meno comunicazioni e più codifica (cosa che dovrebbe per tutti gli account). Qualcun altro vuole venire un po 'più tardi. Un altro dovrà saltare una riunione per rispettare una scadenza. Una persona grafica ottiene un monitor più grande. Quando poni troppa enfasi sul mantenimento del punteggio, dimentichi ciò che è importante.

Sono un amministratore di Linux scontroso che fa molto scripting ed è stato notato che ho scarse capacità comunicative. Assomiglio molto al tuo ragazzo. In effetti, questa è l'unica area su cui mi baso nelle recensioni sulle prestazioni. D'altra parte, sto guidando continuamente il mio team nell'innovazione e nella risoluzione dei problemi, e ho creato e aperto la strada alla nuova piattaforma che stiamo implementando e ho salvato il mio team molto tempo e la mia azienda un un sacco di soldi essendo autorizzato a essere me stesso.

Al mio ex capo è stato chiesto alla sua famiglia / moglie E al senior management della nostra azienda di lasciare la sua posizione ... contemporaneamente. Ha lavorato instancabilmente per bilanciare le responsabilità in modo equo e si è caricato molto. Durante qualsiasi interazione con qualcuno al di fuori del dipartimento, se c'era stato un malinteso sulla comunicazione che gli era tornato in mente, era veloce, ah, a correggerlo punitamente. Era scarso nella "gestione verso l'alto", quindi il nostro team è stato l'ultimo a reperire risorse fino a quando non si è verificata un'emergenza, quindi la società ha pagato in eccesso i fornitori con lanci di vendita chiari per l'hardware non testato senza consultare il team che avrebbe utilizzato quegli strumenti. Nel tentativo di creare un team "ben bilanciato", ha gestito le nostre liste di attività e ha cercato di bilanciare le attività in modo che i membri del team potessero migliorare le proprie competenze in aree in cui non erano eccezionali, che ha provocato MOLTO codice errato o implementazioni scarsamente progettate. Mentre a persone diverse dall'autore sono state specificamente assegnate attività di supporto per quel codice non funzionante in modo da poter "apprendere", le implementazioni, il codice e i test scarsamente progettati hanno creato molta scarsa volontà tra i membri del team e in realtàaumento delle occorrenze del "gioco della colpa", che è una strada veloce verso uno stato di squadra tossico.

Il mio attuale capo è un individuo calmo e raccolto che è arrivato dal ruolo di amministratore junior e si è fatto strada. Prende buone decisioni e si affida fortemente ai membri del team per stabilire le proprie priorità. È un eccellente comunicatore e reagisce con calma e in concerto con il suo supervisore a qualsiasi problema di comunicazione, idea o necessità espressa dal mio team. "Lavora verso l'alto" instancabilmente. È lento ad apportare importanti modifiche all'architettura e consulta a fondo l'intero team prima di apportare modifiche al nostro ambiente ed è a proprio agio nel fare affidamento sulle specialità dei membri del nostro team.

Sotto il nuovo manager, i nostri tempi di fermo sono scesi quasi a zero (il che ha anche ridotto la percentuale di tempo che dedichiamo per le attività di supporto da circa il 40% a circa il 10%), la soddisfazione del nostro team ha superato il tetto e siamo sulla buona strada per passare da una "rottura della banca su nuovo hardware ogni tre o cinque anni" a un piano di acquisizione continua che dovrebbe far risparmiare all'azienda circa un bel milione all'anno in cinque anni. Quel piano era un programma di base che non sarebbe mai accaduto sotto il precedente manager, ma è stato attivamente spinto al senior management dal nuovo manager e dipendeva dal trovare MOLTE sinergie nei set di abilità del team. Il CIO ci ha detto in modo informale che ora siamo l'unica squadra della compagnia che "tiene davvero insieme" e che lui " interferirà con il nostro ambiente di lavoro il meno possibile e trasferirà il maggior numero di risorse verso aree problematiche che identifichiamo il più possibile. Ciò è stato vero, e sta portando il nostro "costo" di supporto ancora più in basso, sebbene abbia interrotto i carichi di lavoro di alcuni altri team - ma ha anche ridotto i "costi" di supporto di quei team.

Guarda, il posto in cui gli sviluppatori possono migliorare le proprie competenze è a scuola o nel tempo libero. Il posto per loro per produrre cose è nel tempo della tua azienda. Il modo migliore per produrre cose è produrre ciò che sanno meglio. Quando lavorano in aree in cui uno sviluppatore non si trova a proprio agio, dovrebbero richiamare un secondo sviluppatore specializzato e lavorare in gruppo, oppure lo sviluppatore specializzato dovrebbe scrivere il codice e produrre documentazione e diagrammi. Indirizza le attività di supporto alle persone che hanno scritto il codice. Sì, questo aumenta quello che chiamiamo il tuo "fattore bus": la probabilità che il tuo reparto colpisca un dosso se lo specialista dovesse essere colpito da un autobus. (O licenziato, o cambiare lavoro, o ...) La verità è che la tua perdita di produttività da quella paura è ordini di grandezza superiori alla perdita effettiva quando un "evento di autobus" succede. Ciò che generalmente accade durante un "evento di autobus" è che l'erede del lavoro dello specialista lo rifà a sua immagine in modo da poterlo supportare nel modo più efficace, risolvendo in genere un sacco di problemi e riducendo ulteriormente il tempo dedicato al supporto e la vita va avanti sopra.

Assegna cose alle persone che possono farle meglio. Falli supportare e documentare il loro lavoro. Promuovi la loro creatività e consenti loro di concentrarsi senza distrazioni o microgestione. Tutto il resto è la scuola di gestione BS, che purtroppo sembra che la tua compagnia stia nuotando. Ciò non significa che anche la tua squadra abbia bisogno di nuotare.

Dal punto di vista di un'azienda, un buon manager promuove i valori dell'azienda mentre esegue le attività in base a tali valori. Dal punto di vista di un dipendente IT, un buon manager consente al team di fare ciò che è giusto fare nel modo più rapido e pulito possibile e funge da barriera fecale contro i dirigenti senior spingendo i valori che hanno imparato durante le lezioni di MBA nel fine settimana fino alla gola dei minori. Sei un uomo di compagnia e questo potrebbe non essere il migliore per la tua squadra. Quelli con "buone" capacità comunicative sono semplicemente troppo educati per dirlo.

• Assicurati che il dipendente sappia quanto siano importanti le capacità comunicative per la sua descrizione del lavoro. Lavora con lui / lei per migliorare.
• Non insistere sul fatto che siano bravi come gli altri membri del team in tali compiti.
• Assegna compiti in base ai principi in cui credi. Trova un equilibrio tra un'assegnazione efficiente dei compiti alle abilità e correttezza / divertimento.

Queste sono solo idee riassuntive, si spera che qualcuno rubi questi punti e li pieghi in una delle altre risposte. ;-)

Le prestazioni sono tutto. Dagli i compiti di programmazione. Parla con il resto del dipartimento. Facoltativamente, porta qualcuno a svolgere attività com o incarica qualcuno solo su attività com. Non pensare alla programmazione del divertimento. Tutto è "divertente" dal tuo POV.

In caso contrario, creerai una situazione estremamente difficile da gestire e meno efficace di quanto potrebbe essere.

Che bella domanda, è il tipo di cosa a cui dovrebbero pensare tutti i team leader, i supervisori, i manager dei tecnici. Mi piace il tuo approccio, tutti dovrebbero avere un compito "divertente". Prendendo avendo inoltre una squadra che può pick-up diversi compiti ed è trasversale impedisce addestrati il principio di rimorchi da provocando il caos 'indesipensible membro del team squadra foglie o addirittura prende boccheggiare una vacanza'.

Ora, come sottolineato da molti post, il lavoro non è giusto e non dovrebbe esserlo. I manager vengono misurati su quanto prezioso lavoro viene svolto.

• I manager abbinano le attività agli individui in base alle competenze.
• I bravi manager abbinano le attività in base alle competenze, alla crescita, all'interesse e alla produttività della squadra.
• I grandi manager convincono la loro squadra a fare questo con un piccolo aiuto e una guida. Vale a dire senza che il manager ci passi tutto il giorno.

Parla con il tuo buon programmatore, chiedigli se ci sono cose che vuole imparare. Quali altri compiti avrebbe accettato ... anche ciò che è meno discutibile per lui. Può aiutare gli altri membri del team nella loro programmazione ... far loro da mentore. Sì, lo so che la comunicazione è un problema, quindi forse dovrebbe lavorarci su.

Un altro modo per impacchettarlo è avere un elenco di attività e lasciare che ogni membro dello staff scelga qualcosa. Lascia che sia il tuo buon programmatore a scegliere per primo. Se lo avverti in anticipo e gli mostri l'elenco dei compiti ancora meglio.

Se ottieni resistenza, che quasi sempre fai con il cambiamento, trova un punto di forza, qualcosa di valore per lui, perché ne trarrà beneficio. Infine puoi solo dirgli di farlo per la squadra.

Aspettatevi anche errori e una minore produttività per iniziare, questo è un segno che le persone stanno imparando. Questo progetto potrebbe risentirne, ma il prossimo sarà migliore.

In conclusione, è tuo compito assicurarti che le cose vengano completate, ma allo stesso modo sta aumentando il tuo personale e se riesci a coinvolgerli nel processo ancora meglio. Alcuni potrebbero dire che il modo migliore per garantire che le cose vengano fatte è un team che sa cosa deve fare e possiede i risultati.

Modifica: Oh e continua a provare, i consigli di cui sopra provengono da anni di errori, ma ho sempre saputo che volevo aiutare il mio team a crescere e sapevo che la produttività è il re, quindi ho continuato a provare nuove cose quando l'ultimo tentativo fallì.

La migliore risposta è già stata accettata, ma sono sorpreso che nessuno abbia sottolineato che "l'assegnazione delle attività" non è l'unica cosa con cui il manager può lavorare. Avere un "programmatore above avg" che ha anche "capacità di comunicazione superiori a avg" dovrebbe (a parità di tutte le altre cose) essere uno sviluppatore più pagato / più senior rispetto a qualcuno con capacità di programmazione simili e capacità di comunicazione deboli. Questo può aiutare a compensare qualsiasi "favoritismo" percepito dalla squadra. (In alcune organizzazioni, avere competenze superiori in media in "Analisi dei requisiti" e competenze medie in altre aree può valere molto di più per l'azienda a causa del tipo di lavoro svolto. Come manager, devi decidere come gestirlo .)

Un'altra cosa a cui prestare attenzione: dare alla persona in questione nient'altro che compiti di programmazione porterà all'isolamento a lungo termine. Assicurati di continuare a dare loro alcune delle altre attività (ma quelle che possono fare bene, non impostarle per un feedback negativo !!) in modo che siano entrambe visibili e abbiano visibilità con gli altri dipartimenti / team.

Infine ... controlla con gli altri membri del team se vedono periodicamente delle disparità nelle assegnazioni del team. Questa potrebbe essere una grande preoccupazione per te, ma # 15 nell'elenco di tutti gli altri.

Poiché secondo la tua valutazione questo programmatore è il migliore del team, in un certo senso è "giusto" dare a quella persona il lavoro desiderato (come risultato di aver dimostrato di essere in grado di farlo al meglio). Dopotutto, c'erano probabilmente persone che avrebbero voluto lavorare in questa compagnia ma non erano affatto assunte - ma nessuno dirà che non è "giusto" per loro che non riescono a fare questo codice.

Penso che un approccio equo sarebbe quello di dire a un altro membro del team meno abile che vuole fare più codice: "stiamo lasciando (così e così) il comando su questo. Forse puoi prendere il comando su la prossima cosa che succederà, se puoi dimostrare di aver appreso le abilità xey ".

Come alcuni degli altri che hanno risposto, capisco la tua posizione e avrei ambizioni simili.

Mentre è un caso dire che ha senso assegnare compiti alle persone più attrezzate per eseguirli, è anche sensato ampliare le competenze delle persone al fine di fornire un team dinamico e flessibile.

Se questo ragazzo è tenuto a fare elementi non codificanti nel suo ruolo, ma le sue capacità comunicative sono più scarse di quanto siano realmente necessarie, deve migliorare. Partendo dal presupposto che abbiate una sorta di sistema di revisione / valutazione dello sviluppo, questo è il momento di sollevare il problema.

Le questioni chiave sono mappare chiaramente ciò di cui hai bisogno, valutare se possiede le competenze per conformarsi e elaborare un piano di formazione che gli consenta di farlo. La formazione non deve necessariamente essere formale, ma è necessario aiutarlo ad acquisire le competenze richieste.

Se semplicemente non può essere disturbato, alla fine arriverebbe a una questione disciplinare. Se non ha la capacità, nonostante abbia provato e supportato da te, allora potrebbero essere disponibili misure disciplinari (che direi che sarebbero dure e controproducenti) ma allo stesso modo potresti semplicemente accettare che non lo è tagliato per determinati compiti.

Parlare con il ragazzo sarà uno dei primi porti di scalo . Potresti scoprire che gli manca la fiducia o l'intuizione. Potresti anche scoprire che è molto reattivo e apprezzerà l'opportunità di migliorarsi.

Dovresti assumere un giovane per fare tutto il lavoro grugnito e far sapere a tutti che hanno bisogno di aiutarlo con tutto ciò con cui chiede aiuto.

Saranno più propensi a disturbare il programmatore "sopra la media" a causa delle loro abilità e il resto della squadra riceverà un nuovo lacchè. Il giovane impara da zero e alla fine la compagnia finisce con un impiegato ben arrotondato.

Aspettarsi che tutti abbiano le stesse capacità comunicative è razionale quanto aspettarsi che insegnerai all'uomo paralizzato a correre più veloce del resto della squadra.

Le persone sono diverse, hanno abilità diverse e debolezza diversa. Licenziare un grande programmatore solo perché non riesce a mettersi al passo con gli altri nelle abilità comunicative sarebbe come licenziare un paralitico perché non può camminare veloce come gli altri. Sarebbe ingiusto da un punto di vista etico e sarà contro i tuoi stessi interessi economici: portare a termine il lavoro.

All'inizio dovresti, se non l'hai fatto in passato, leggere la sindrome di Asperger . Le scarse abilità sociali sono il principale indicatore di quella sindrome.

In secondo luogo, puoi assumere e licenziare chiunque tu voglia, ma se non riesci a far fronte ai punti di forza e alle debolezze dei tuoi dipendenti, finirai con un gruppo di programmatori medi, perché i migliori se ne andranno (se non vengono licenziati prima) .

C'è un film, Adam , in cui il geniale programmatore viene licenziato solo perché ha scritto qualcosa che non ci si aspettava. La sua idea poteva portare molti soldi al datore di lavoro, ma non poteva sfruttare l'occasione perché era concentrato sui suoi "principi".