Quali tratti hanno in comune i migliori manager con cui hai lavorato? [chiuso]

Ho ascoltato il podcast di Scott Hanselman e Rob Conery, This Developer's Life .

Nell'ultimo episodio, discutono i tratti della personalità:

1.0.4 - Essere medio.

Cosa rende le persone importanti nel nostro settore? Che dire aggressivo? Fiducioso? Qual è la differenza? Preferiresti avere un sergente istruttore per un capo o un maestro di zen? Parliamo con Cyra Richardson e Giles Bowkett.

Mi ha fatto pensare, quali tratti avevano in comune i migliori manager con cui hai lavorato?

EDIT: Solo per chiarire, dato che ci sono stati alcuni voti stretti, mi interessa sapere se ci sono tratti comuni ai gestori di sviluppatori che non sono necessariamente quei tratti richiesti da un dirigente di un'altra professione.

Per quanto riguarda il fatto che questo sia legato alla programmazione o no, beh, non voglio porre questa domanda su un sito che non riguarda la programmazione perché, francamente, non sono così interessato a ciò che le persone che producono lattine di zuppa per vivere voglio dai loro manager perché sono interessato a ciò che gli sviluppatori vogliono dai loro manager.

Nella mia esperienza, è stata una combinazione di quanto segue:

1. Misure in base a risultati / output, anziché input.
2. Leader motivante e di ispirazione che puoi rispettare e guardare in alto.
3. Sensibile alle esigenze dei membri del team - supporto / formazione / carriera, ecc.
4. Risolve rapidamente i conflitti, diffonde situazioni difficili.
5. Comprende il tuo lavoro: potrebbero essere in grado di svolgere effettivamente il tuo lavoro, ma ti hanno assunto per farlo.
6. Gestisce / filtra le cose che non sono importanti o compromettono la produttività dei team.

Joel Spolsky lo chiama " Livello di astrazione ". Fai quello che serve per farmi programmare. Fammi sapere cosa sta succedendo in azienda, ma tienimi fuori dalla politica. Anche se devo ancora farlo, ammetti almeno che la richiesta è bull sh! T.

Qualcuno che combatterà battaglie politiche per me e rimuoverà gli ostacoli che mi impediscono di fare le cose.

Periodo.

Essere disposti ad ascoltare le persone che lavorano per loro.

Ho avuto manager molto tecnicamente inclini e ne ho avuti alcuni che non sapevano nemmeno del multitasking ("oh wow! Dove hai imparato quel trucco Alt-Tab?"), Ma la cosa che tutti quelli In realtà mi è piaciuto lavorare perché avevano in comune il fatto che sapevano di non sapere tutto ed erano disposti ad ascoltare quando quelli di noi facevano effettivamente il lavoro che avrebbero dovuto gestire idee, problemi o suggerimenti presentati su quel lavoro.

Protegge la sua squadra e si assume le sue responsabilità

Uno nel tuo team si arresta in modo anomalo su un server con dati di produzione. Il tuo manager si assumerà la piena responsabilità. Alla fine rifiuterà di dire al suo superiore che ha fatto l'errore e di stare di fronte ai suoi uomini.

Gestiscono in base agli obiettivi, non al tempo, e si preoccupano principalmente del raggiungimento di tali obiettivi

Invece di preoccuparsi per quanto tempo sono seduto alla mia scrivania, si preoccupano di ciò di cui ho bisogno per svolgere un determinato compito. Se questo significa rimuovere ostacoli o ostacoli o permettermi di lavorare per lunghe ore / fine settimana, sono disposti a compensare il tempo. Se lavoro prima del previsto e ho bisogno di un po 'di tempo per gli appuntamenti con il medico o le attività familiari, sono flessibili e comprensivi.

Voglio certamente essere ritenuto responsabile sul lavoro, ma dovrebbe essere per quello che ottengo, non per quanto tempo trascorro alla mia scrivania.

Tienimi fuori dalle riunioni in cui non ho bisogno di partecipare. Se i manager riuscissero a farlo, sarebbero infinitamente più preziosi.

Riconoscimento che sono assunto e pagato per prendere decisioni.

Ti supportano quando dici NO

Uno dei tratti più demotivanti di un manager è la mancanza di coraggio per difendere il suo popolo e inchinarsi sempre di fronte al proprio capo, anche se ciò influisce sul prodotto o sulla squadra.

niente urla per favore ... semplicemente no. (non importa quanto sei stressato per la grande scadenza, stupidi tester, ecc.)

Qualcuno che mi lascia fare il mio lavoro.

Comprendere in cosa consiste la programmazione. Saresti sorpreso di quanti manager non sanno nulla della questione.

Riconoscimento che sono assunto e pagato per prendere decisioni.

Non sono un dipendente del servizio di ristorazione di $ 7 / ora. Sono qui per prendere decisioni. Se mi viene detto ogni dettaglio di cosa fare, potrei anche essere una dattilografa.

(Deep) Empathy Skill.

Devo andare da questo punto di vista dei peggiori capi per cui ho lavorato - un bravo NON avrebbe queste qualità:

Incapacità di prendere una decisione _ la cosa peggiore che abbia mai affrontato era un capo che cambiava idea ogni volta che qualcuno gli parlava. Abbiamo cambiato direzione 4-5 volte al giorno su un progetto triennale.

Ruba il merito delle cose che fanno i membri del team. Una volta il mio capo ha ricevuto un enorme premio che gli hanno dato pubblicamente. Tutto quello che hanno detto che ha fatto, l'ho fatto davvero. Inutile dire che questo è demotivante all'estremo.

Panico quando le cose non vanno bene. Ancora peggio quando il panico lo rende cattivo. Questo non aiuta a fare le cose, davvero.

Accoltella all'indietro il suo stesso popolo. Lui prende il merito, noi abbiamo la colpa. E non ci supporta nella catena di comando quando dovrebbe.

Non ha alcuna comprensione del processo di sviluppo del software e non si preoccupa nemmeno di imparare abbastanza per sapere che stiamo usando C # (o altra lingua di tua scelta). Pensa che tutto possa essere fatto in un breve periodo di tempo e che una semplice modifica all'esterno di una pagina User_interface significa che non ci vorrà molto tempo per l'implementazione. Il tipo di persona che si siede su un cambiamento fino al giorno prima della scadenza e poi dice "Oh, per come dobbiamo fare ..." e tutto ciò che chiede è qualcosa che cambia l'architettura fondamentale.

Micromanages o non riesce affatto. Entrambi sono ugualmente cattivi. Ho avuto troppi capi che non sapevano che c'era un problema con un dipendente fino a tardi e tutti gli altri hanno dovuto pagare il prezzo per sistemare il pasticcio. Ho anche avuto dei capi che dovevo dire loro di smettere di darmi fastidio ogni cinque minuti o che non avrebbero mai fatto.

È politicamente ingenuo. Se il tuo capo non sta andando bene politicamente con le persone sopra di lui, avrai difficoltà a trovare le persone di cui hai bisogno, avrai gli spazi peggiori e sei nel gruppo più probabilità di perdere il lavoro in un licenziamento o perché è un modo semplice per sbarazzarsi di lui. I capi devono essere bravi in ​​politica d'ufficio.

Qualcuno che pensa di poter dimezzare le ore di un progetto (perché al cliente non piacerà quel numero) e saremo in grado di farlo in quel lasso di tempo senza corrispondenti cambiamenti di requisiti.

Credito dove credito dovuto e sufficiente conoscenza per poterlo assegnare

Avrei aggiunto gli ascolti bene, ma ho invece votato a favore.

1. Se c'è qualcuno che si prende costantemente il merito delle funzionalità presenti nelle biblioteche sviluppate internamente, open source o di terze parti, ciò dovrebbe essere abbattuto, non premiato.
2. Se a qualcuno vengono assegnate tutte le responsabilità dei bug perché sta effettivamente scrivendo unit test e trovandoli, dovrebbe essere ricompensato, non punito. Trovare i bug non è lo stesso che scriverli in primo luogo.
3. Se uno sviluppatore o un gruppo di sviluppatori si rompono il culo per fissare le scadenze, dovrebbero essere lodati, non i gestori per aver escogitato le scadenze in primo luogo.

Si fidano della loro gente per portare a termine il lavoro e non provano a "mandare gatti".

Dai alla loro gente spazio per fare errori (ovviamente non enormi) e imparare da loro.

Qualcuno che ascolta bene

e

Qualcuno che ha intenzione di parlare con me almeno una volta alla settimana

Ho avuto buoni manager e cattivi. Questi sono alcuni tratti che ho notato in cattivi gestori:

Levati di mezzo in modo che tu possa fare il tuo lavoro

Un buon manager farà in modo che tu abbia l'attrezzatura giusta per scrivere il codice.

Micro-gestisce i dettagli sbagliati

Questo tipo di manager ti farà arrabbiare per non aver allegato una firma alla tua e-mail ignorando il lavoro extra che hai fatto prima di quella e-mail.

Non ha interesse nel processo di sviluppo

Questo è davvero un brutto segno per un manager responsabile degli sviluppatori di software. Non gli interessa indagare su altri approcci di sviluppo, non saprà quale numero di versione dovrebbe essere la prossima versione del software, non leggerà blog come Joel su Software o qualsiasi cosa relativa alla gestione di sviluppatori, come Peopleware.

Pensa che sia lì per me a cui riferire

Questo tipo di manager inizia a fare in modo che la gente gli riferisca di tutto.

Misallocates time

Dato un mese per consegnare un progetto di sviluppo dall'inizio alla fine, questo manager assegnerà 3/4 del mese al team di progettazione e requisiti per generare documenti di 1000 righe e aspettarsi che il team di sviluppo lo realizzi in una settimana. Esaminerà anche i requisiti fino a quando non saranno "perfetti", aggiungendo abbondanti dettagli fino a quando il documento diventa inutilizzabile. Ma più avanti nel processo di sviluppo troverai bug nella documentazione di progettazione e requisiti e ti rendi conto che l'enfasi sul cercare di scrivere il documento perfetto è stato un errore.

Penso che le due caratteristiche più importanti siano la comprensione di base dei principi di gestione e l'essere "uno di noi". Sfortunatamente, i due non tendono ad accadere insieme troppo spesso, ma quando lo fanno, hai trovato una brava persona per cui lavorare.

Dove lavoro, il nostro project manager è un ex sviluppatore. È bravo a definire le priorità e a dirigere il lavoro - le cose che un manager deve sapere - ma ha anche una buona idea di cosa sta succedendo quando devo fare una domanda su come implementare qualcosa che richiede sia una visione a livello di gestione da lui e input tecnici da parte mia.

Il capo ha anche entrambi questi skillset. In realtà è uno sviluppatore attuale , che occasionalmente lavora sulla base di codice e si impegna, quando altre responsabilità non lo trascinano via da esso. Si assicura che abbiamo un buon ambiente di lavoro, perché sa intuitivamente come è un buon ambiente di lavoro per noi: sono le condizioni in cui vorrebbe lavorare!

Combatte per me. Non avrei dovuto affrontarlo con l'IT. Mi dà gli strumenti di cui ho bisogno. Comunica la politica aziendale. Prende decisioni quando viene richiesto e rimane fuori quando non lo è.

Disclaimer: in precedenza ho ricoperto ruoli manageriali, ma attualmente non lo sono. Da ciò posso sicuramente dire che può essere piuttosto difficile trovarsi anche dall'altra parte del tavolo.

Qualcuno che è chiaro in ciò che deve essere fatto, mi permette di elaborare i dettagli tecnici, fornisce il contesto quando necessario e non cambia i requisiti quando ho più di metà lavoro.

Due cose:

1) È (o abbastanza recentemente era) uno sviluppatore.
2) Gestisce sia verso l' alto che verso il basso .

Il punto 1 ti darà, come sviluppatore, un manager che capisce veramente qual è il tuo lavoro e in che cosa consiste e comprende ciò di cui hai bisogno (e anche che non ti serve) per svolgere il tuo lavoro al meglio delle tue capacità. Se non sono uno sviluppatore ora (e in realtà non dovrebbero effettivamente essere uno sviluppatore pratico ora perché sono un manager - e questo è un lavoro a tempo pieno stesso) dovrebbero avere precedenti esperienze di sviluppo, ma dovrebbe essere abbastanza recentemente (cioè negli ultimi anni) in modo da avere almeno familiarità con linguaggi, strumenti, metodi e tecniche di sviluppo moderni.

Il punto 2 vi darà un manager che accetta le sue responsabilità, scudi la sua squadra dalla politica dell'ufficio e le distrazioni inutili e combatte per la sua squadra ad essere fornito con le cose che devono (permettendo così il punto 1) e in grado di gestire le aspettative da parte delle imprese e di quelli al di sopra di lui (questo è ancora più importante in una grande azienda in cui esistono molti livelli e livelli di gestione tra te (lo sviluppatore) e i responsabili delle decisioni aziendali (senior management)).

In breve, avere tratto (1) ti dà un manager che capisce di cosa hai bisogno per fare il tuo lavoro, e avere tratto (2) ti dà un manager che ti fornirà ciò di cui hai bisogno.

Joel Spolsky's Talk at Yale (e l'articolo correlato " Command and Conquer and the Herd Of Coconuts ") afferma in modo molto succinto:

Nel parlare della (cattiva) gestione di Giunone:

"L'ipotesi era che i manager esistano per dire alla gente cosa fare".

Nel parlare della gestione (generalmente buona) di Microsoft:

"I manager esistono per togliersi di mezzo i mobili in modo che il vero talento possa fare un lavoro brillante."

Voglio qualcuno che sia capace (e abbia il coraggio di) di riconoscere e sbarazzarsi del deadwood. Queste persone stanno danneggiando il prodotto e rallentando il completamento, togliendoli di mezzo! Troppi manager o non riescono a riconoscere chi è un cattivo sviluppatore (o pensano che quello con la scrivania disordinata sia cattivo o il ragazzo che sembra iniziare molto nello spazio anche se può effettivamente essere lo sviluppatore più intelligente o più produttivo) o non vuoi essere quello che dice a qualcuno che viene lasciato andare e quindi lascia che il deadwood rimanga anno dopo anno causando danni e malcontento tra i competenti.

Non voglio essere imbarazzato da un manager che non sa nemmeno quali lingue o backend del database o altri strumenti critici utilizziamo. Ho avuto una domanda (di fronte al cliente) in quale lingua abbiamo programmato dopo essere stati coinvolti nel progetto per 3 anni! Non mi aspetto che le persone che sono in gestione da molto tempo siano ancora al corrente di tutto, ma almeno dovrebbero sapere cosa stiamo usando. E dovrebbero essere abbastanza furbi da non chiedere cose del genere davanti agli altri se non lo fanno.

Voglio un manager che abbia coraggio. Non accettare quella scadenza non realistica senza respingere, non lasciare che le persone maltrattino i tuoi dipendenti o lascia che gli sviluppatori rouge seguano la loro strada misteriosa senza essere tirati indietro. Non mancate di dirmi se sto facendo qualcosa di sbagliato perché temete che potrei arrabbiarmi. I gestori esistono in parte per gestire le cattive notizie, voglio uno che può.

Voglio un manager che capisca che ho una vita familiare, che capisce che gli sviluppatori sfiniti commettono errori e ci vuole più tempo per fare un progetto che lavora 60 ore a settimana di 40.

Soprattutto voglio un manager che riconosca il buon lavoro e sia verbalmente riconoscente sia per me di persona che per la catena verso i suoi capi. Anche se lo odio davvero quando pensano che il cattivo lavoro sia un buon lavoro e premiano le persone sbagliate!

La cordialità sarebbe qualcosa che avrei messo lì. Non mi piace avere paura se il mio capo decide di visitare il mio cubicolo ogni volta . La mia performance potrebbe essere un po 'migliore se mi sento come se stessi aiutando un amico che a volte chiede un favore qua e là, ad es. Per realizzare un progetto entro una scadenza, potrei dover rimanere in ufficio per un certo numero di ore che altrimenti non potrei voler fare.

La competenza sulla gestione di più cose sarebbe un altro aspetto che cercherò sebbene questo possa essere visto come un tratto evidente in una certa misura. Le capacità di risoluzione dei conflitti e di riconciliazione sarebbero anche qualcosa che vorrei sapere che il mio manager è in grado di gestire in quanto potrebbero esserci momenti in cui è sviluppatore contro sviluppatore o sviluppatore contro analista in termini di problemi che richiedono che qualcuno abbia ragione, che potrebbero non essere né in alcuni casi, poiché alcuni aspetti del lavoro possono avere più interpretazioni.

Qualcuno che capisce che lo sviluppo non è un lavoro di fabbrica. L'inserimento in più ore al giorno non ha probabilità di ottenere una resa significativamente più elevata. I programmatori hanno bisogno di alzare il naso dalla mola piuttosto spesso e semplicemente non pensare a cosa stanno lavorando per risolvere un problema e fare le cose.

Un buon manager è disposto a farmi dire di no . Si rendono conto che lo sviluppo del software è un problema malvagio . Pertanto, anche se il manager è più compattato di me tecnicamente, si rendono conto che potrei conoscere meglio il problema semplicemente perché sto implementando la soluzione. Allo stesso tempo, mi fanno sapere quando mi manca il contesto. Molte volte, i manager possono prendere decisioni in base a cose che sanno di no. In tal caso, dovrebbero compilarmi i dettagli o almeno farmi sapere che sanno qualcosa che io non conosco.

Ho lavorato in alcuni posti in cui la gestione era esplicitamente non tecnica. Il mio attuale datore di lavoro ha una politica secondo cui un manager che prende una decisione tecnica è motivo di rimozione. (Questa non è una piccola azienda di cui non hai mai sentito parlare, circa un terzo di te gestisce il nostro prodotto). In parte a causa di questa politica, almeno secondo me, i dirigenti qui sono molto più "forti" rispetto ad altri datori di lavoro. Dal momento che non sono coinvolti nel processo decisionale tecnico, non vi è la costante serie di decisioni tecniche "da leggermente a molto sbagliate" prese dalla direzione e prendono solo decisioni di "livello di linea di prodotto".

I migliori manager che ho avuto sono quelli che "interferiscono" con gli sviluppatori. Un buon manager può dire la differenza tra una "riunione obbligatoria" e una riunione obbligatoria e te lo farà sapere.

Un'abilità di gestione di base è quella di far sentire gli sviluppatori in controllo del loro ambiente, questo può essere un promemoria o un'illusione, a seconda dell'azienda, ma è un'abilità di vitale importanza.