Dirigere una squadra, sono prepotente?

Sono in quella che mi sembra una posizione molto strana. Sono "team leader" nel ruolo di un particolare progetto, Sr. Software Engineer nel titolo di lavoro. Nel mio team ho 4 sviluppatori, uno dei quali svolge un ruolo simile in un altro progetto, ma ora al mio è stata data la priorità, quindi sta lavorando al mio. Ho anche 2 tester, uno dei quali è un manager. Un altro membro del team è il "Rappresentante del cliente" che fa parte di un dipartimento completamente indipendente. Ho anche un Manager che è direttamente sopra di me e credo anche al di sopra del Manager of Test che fa parte del mio team ... non ne sono così sicuro.

Ho cercato di ottenere chiarimenti sul perché il mio ruolo è esattamente diverse volte. È stato difficile per me capire dove inizia e finisce la mia autorità, se ne ho anche una. La risposta con cui sto attualmente lavorando è che sono il "capo tecnico" del team. Ciò sembra significare che la mia autorità ha preso decisioni tecniche riguardo all'architettura, al design e agli standard di processo / codifica in quanto relativi al codice del prodotto stesso.

Oggi è emerso qualcosa e i risultati del codice che ho delegato a uno dei membri del mio team sono stati mostrati al resto dell'azienda nella nostra riunione show-it-off di Scrum. Il rappresentante del cliente fa lo spettacolo. Oggi è stato messo in mostra qualcosa con cui non ero affatto d'accordo e nessuno mi aveva mai chiesto se volevo dire la mia in quello che è successo. In breve, al fine di fornire la capacità di un utente di visualizzare un valore in un report nei seguenti modi (unità "doc", unità di progettazione, arrotondate, non arrotondate) hanno fornito campi di accesso per ciascuna permutazione. Quindi abbiamo il valore in unità doc arrotondate, unità di progettazione arrotondate, unità doc non arrotondate, unità di progettazione non arrotondate. Ogni record con il quale l'utente vorrà lavorare ha molti di questi valori e ognuno è permesso in questo modo.

Lo odio davvero.

Le persone che abbiamo mostrato questo vogliono assicurarsi che l'API che utilizziamo per i report sia uguale al modo in cui facciamo cose come esportare i dati in Excel. Sfortunatamente, ora stiamo guadagnando questo slancio in una direzione che penso sia davvero, davvero brutta.

Mi sono arrabbiato un po 'alla prossima riunione e ho chiesto alle due persone che l'avevano fatto: "Perché non sono stato coinvolto in questa decisione ??" È un problema che continua a sorgere e ho difficoltà a far entrare le persone nella squadra che dovrei portare a chiedermi se voglio essere coinvolto. A volte non lo faccio e penso che qualunque cosa escano andrà bene. Altre volte lo faccio. A meno che la gente non me lo chieda, anche se è difficile sapere che sta succedendo qualcosa che ha bisogno del mio contributo e non mi danno questa opportunità.

Sfortunatamente, la mia autorità non si estende al dire alla gente: "La prossima volta che vai via e fai qualcosa del genere da solo senza nemmeno parlarmi, sarai disciplinato". Questo è un problema di "PR" che è un'area che chiaramente non rientra nella mia portata di autorità. In realtà va bene per me dal momento che non voglio avere a che fare con quel tipo di schifezze se qualcun altro è disposto.

Oggi, però, il mio manager, di fronte a tutti (che immagino sia in parte anche colpa mia per averlo sollevato in quel modo) mi ha detto che non posso essere coinvolto in ogni decisione e che devo delegare.

Ovviamente penso di aver ragione .... Lo faccio sempre. Non dico cose che penso siano BS. Penso che avrei dovuto affrontare questo problema e chiedermi se avevo un'idea migliore. La mia direzione per questo sarebbe stata in realtà quella di decidere solo su UN valore da fornire per ora, poiché questa era in realtà le fasi iniziali di una nuova funzionalità e discutere le opzioni per fornire un ulteriore accesso in futuro, se desiderato. Non avrei mai approvato o raccomandato l'implementazione attuale e non credo davvero che avrebbe dovuto vedere la luce del giorno.

La domanda è: sono io quello irragionevole?

Bene, ne abbiamo parlato in due e concordato sul fatto che entrambi "abbiamo lasciato cadere la palla" e sembriamo essere sulla stessa pagina. Lunedì mattina ... Cercheremo di assicurarmi che il mio ruolo sia chiaro nella squadra e che sì, potrò decidere quando c'è un cambio di progettazione o di attività che deve avvenire; Mi viene proposto di concordare o decidere che devo guardare più in profondità. Poi ci sono altri bit su cui posso provare a lavorare per assicurarmi che sappiano che possono venire da me.

Sembra che tu debba monitorare i commit delle fonti. Perforce ha questa capacità in modo nativo, Git ce l'ha con gli ami, altri sono sicuro che abbiano i loro metodi. Non è necessario eseguire il nitpick di ogni commit, ma almeno avere una notifica e diffonderli ti darà una breve occhiata a tutto ciò che sta andando nel tuo progetto.

Per quanto riguarda il tuo manager che dice che devi delegare, non sono così sicuro che sarei d'accordo - con un team di quattro sviluppatori, dovresti essere in grado di gestirlo. Ancora, potrei schierarmi con lui (o lei). Naturalmente, anche nelle attività delegate, dovresti chiedere aggiornamenti di stato o procedure dettagliate sulle modifiche di progettazione, ecc.

Nulla di negativo dovrebbe mai essere sollevato nelle riunioni - sembra che sia tu che il tuo manager abbiate lasciato cadere la palla su questo. La cosa peggiore in assoluto che potresti mai fare ad un pari è metterli in imbarazzo. Come lead (come con il tuo manager), devi essere accessibile e affidabile. Sminuire qualcuno porterà a risentimento, che contaminerà la tua capacità di guidare la tua squadra (oltre a portare a dipendenti scontenti).

Io odio sentire la parola "disciplina" da qualcuno in un ruolo da protagonista. La disciplina (almeno in questo contesto) è negativa e non produttiva. Lavorare con qualcuno (personalmente e non in un ambiente di riunione), scoprire perché hanno fatto qualcosa e fornire alternative se non si è d'accordo con le soluzioni proposte è ciò che dovrebbe essere fatto. A volte, scoprirai che la persona con cui lavori è giusta e il tuo istinto è sbagliato. Perché? Hanno trascorso più tempo su quel problema specifico di te.

Qualcos'altro che mi preoccupa è "Penso sempre di avere ragione". IMO, questo è l'atteggiamento peggiore possibile da qualsiasi vantaggio. Si dovrebbe , ovviamente, essere sicuri nelle vostre abilità, ma rendersi conto che se non sei profondo scollo a un problema specifico, quindi più volte che non, i vostri suggerimenti stanno venendo fuori del posteriore (non importa quanta esperienza hai) e non può Sii il migliore. Se qualcuno che si sta concentrando su un problema specifico offre un'alternativa, allora è il tuo lavoro (bene, così come il loro, a seconda del loro livello di esperienza) per dimostrare perché il tuo è meglio, non solo per dire "Sono il protagonista e Penso sempre di avere ragione ", che è ciò che la tua frase mi porta a credere.

Per concludere

Sì, sei irragionevole su alcuni punti, ma altri no. Come risultato, mi aspetto che se ci sono cambiamenti di funzionalità o di architettura che sono almeno passati da te.

Tuttavia, è anche tuo compito garantire la qualità generale del sistema e del codice, cosa che devi fare da solo. La tua azienda utilizza recensioni di codice? I tuoi programmatori progettano su cosa stanno lavorando prima di entrare nel codice? In caso contrario, potresti voler iniziare a utilizzare questo tipo di meccanismi di controllo della qualità.

Potresti essere controllato per la gestione, e in tal caso stai fallendo (il che potrebbe non essere una brutta cosa; molti di noi sono buoni sviluppatori e sarebbero cattivi gestori, e preferirei piuttosto programmare che gestire programmatori).

I manager spesso non hanno l'autorità per tutto ciò che dovrebbero fare. Fare comunque le cose è un segno di un buon manager. Devi trovare il modo per indurre le persone a fare le cose senza fare alcun tipo di azione disciplinare. (Nota: denigrare le persone in pubblico non è vero. Lodare in pubblico, criticare in privato e mostrare un certo interesse per i propri subordinati come persone.)

I manager devono anche delegare, anche quando fa male. Probabilmente trascorrerai più tempo a risolvere questo problema di quanto non avresti speso a scriverlo da solo, e va bene. Una volta che hai risolto il problema, le persone che lo hanno fatto avrebbero dovuto imparare qualcosa e hanno meno probabilità di fare le cose nel modo sbagliato in futuro.

Il modo giusto di affrontare qualcosa di simile è in privato, prima chiedendo agli sviluppatori perché hanno fatto il display in quel modo. Non in una riunione, e non assumendo in anticipo che hai ragione e che hanno torto (anche se hai ragione e hanno torto). Dai loro la possibilità di spiegare. Ciò non significa che devi seguire la loro decisione; tu, dopo tutto, sei il capo tecnico. Significa che devi dare loro dei motivi per farlo a modo tuo e dovresti affrontare tutti i problemi fondamentali che mostrano durante quell'incontro privato.

Inoltre, i manager hanno la responsabilità di ciò che viene fuori dalla loro gente. Dovresti cercare di non essere accecato da tutto ciò che fanno, in particolare di fronte a un cliente. Ciò può comportare il tenere traccia dei check-in del codice o avere brevi mini-conferenze con i tuoi sviluppatori (anche se devi stare attento a ciò, non vuoi interromperli quando sono nella zona). Forse dovresti parlare con tutti gli sviluppatori il pomeriggio prima dell'incontro con il rappresentante del cliente.

Non prenderlo sul personale

È uno sforzo di squadra. Sei il capo tecnico, non l'unico ragazzo del progetto. Dovresti concentrarti su come far imparare il team dagli errori o cambiare il processo.

Guida e impara

Parte di qualsiasi posizione di leadership, incluso un vantaggio tecnico, è capire che fai il meglio che puoi con le persone che hai. Più il team lavora insieme, più sapranno quando far crescere le cose e quando no. Assicurati solo di non cadere nella trappola del dettare alla tua squadra. Rivedi cosa è andato storto e cosa è andato bene su base settimanale. Comunica con il tuo team se vuoi che facciano le cose diversamente. La misura punitiva dovrebbe sempre essere l'ultima risorsa e di solito significa che devi licenziare qualcuno o hai fallito nel tuo ruolo.

Rivedere prima della presentazione del cliente

Se sei il capo di un progetto, perché non hai esaminato la funzionalità e l'implementazione prima che fosse presentato?

Se è sbagliato, risolvilo

Spiega chiaramente perché qualcosa non va e cambiarlo. È più costoso, ma se è effettivamente sbagliato, risolvilo. Se non è sbagliato, è solo diverso da come volevi fare le cose, poi di nuovo; capisci che non sei l'unico a lavorare al progetto.

C'erano delle specifiche che documentano ciò che dovrebbe essere implementato? Dato un requisito troppo aperto, gli sviluppatori spesso riempiono gli spazi vuoti (o richiedono microgestione) con qualsiasi cosa ritengano appropriata.

Quindi alla fine vai dal tuo manager con "Quindi, invece di lavorare su ciò che è nelle specifiche, hanno deciso di fare invece [funzionalità]. Ora siamo dietro, a causa di una funzionalità che non è stata approvata in primo luogo."

Quindi puoi iniziare a lavorare sull'eliminazione della funzione una volta che gli sviluppatori sono stati riassegnati.

modifica> E no, non credo che tu sia prepotente. Il loro lavoro finisce per essere il tuo culo.

Mi trovo spesso nella stessa posizione e sollevarlo nelle riunioni e nelle discussioni non sembra arrivare da nessuna parte. A volte come ultima risorsa prima di rassegnarmi ad andare con la decisione presa (albiet non la mia), invio un'email alle parti interessate dichiarandola in bianco e nero con i miei motivi per cui.

Quindi archiverei quell'e-mail in modo da assicurarmi di averlo per riferimento futuro nel caso fosse necessario più in basso quando un manager o un cliente chiede perché qualcosa è stato fatto in quel modo o perché un cambiamento costa così tanto da risolvere.

Penso che tu abbia sbagliato a sollevarlo come hai fatto, come hai riconosciuto. Non sbagli a dire che dovresti avere qualche input sulla progettazione a questo livello, ma non sono sicuro di come ti aspetti di implementarlo in modo ragionevole. Le persone non gestiranno un tuo progetto se lo considerano semplice; dal momento che possono sbagliarsi altrettanto facilmente sul fatto che sia semplice quanto sul progetto stesso, non troverai persone che si offrono volontarie per mostrarti tutti i loro progetti sbagliati. A questo punto sono per lo più curioso delle tue abitudini lavorative e dei tuoi schemi di comunicazione, ma in realtà non importa come tutto ciò a volte sarai solo accecato da queste cose. A corto di una diligente revisione di ogni commit, non sono sicuro di come tu possa dimostrarlo.

Mi sento troppo spesso così emotivamente:

 I of course think I'm right....I always do. 

ma ho il senso intellettuale di sapere che a volte sbaglio. So anche quando scegliere una rissa: non puoi discutere di tutto, e talvolta un accordo inaspettato da parte tua può fare miracoli.

Cos'è un vero leader?

È qualcuno che può licenziare un subordinato, qualsiasi subordinato. (ma non è necessario assumerne uno nuovo)

A volte, la maggior parte delle persone viene "taggata" come leader di qualche progetto ma, senza il potere del fuoco qualcuno, è più una "guida" / "insegnante" che un vero leader.

Ma ancora una volta, può succedere che tu possa essere un leader del team ma non guidare il tuo progetto attuale. Il caso peggiore è quando il cliente guida il progetto. A questo punto, se il progetto fallisce (e fallirà), non è tua responsabilità.

E il caso peggiore è quando esistono due leader del progetto.

Come militari, le catene di comando sono tutto (non così radicale come "morire per un progetto" ma abbastanza vicino). Per questo motivo, il tuo manager ha rotto il tuo status, ha abbassato la morale della "tua" gente e non ha aiutato affatto.

Sì, il tuo capo ha ragione: non puoi essere coinvolto in ogni decisione. In effetti è impossibile catturare tutto come questo se non lo fai da solo. Penso che sia da lì che vieni - senti che non puoi avere una buona padronanza dell'intero progetto a meno che non sia coinvolto in ogni piccolo dettaglio, ma non puoi essere coinvolto in ogni piccolo dettaglio senza sopraffarti (che demoralizzerà totalmente il squadra e probabilmente ti bruciano).

La risposta non è preoccuparsi delle cose che vanno male - lo fanno sempre - invece di preoccuparsi di risolverle in seguito, in modo costruttivo.

Se continui a seguire la comunicazione, non solo puoi delegare, ma puoi lasciare che i tuoi senior si allontanino e facciano ciò che sanno è necessario senza trattenerli sempre con recensioni, discussioni e tentativi sbagliati di controllarli. Fidati di loro per fare la cosa giusta ed essere lì per "chattare" su ciò che sta succedendo in modo da poter essere tenuto al corrente (e infilarti il ​​naso quando ne senti il ​​bisogno).

Hai diversi problemi. Prima il tuo manager si è schierato dalla parte del tuo team e ti ha detto di delegare di più. Ciò dimostra una mancanza di fiducia nella tua capacità di guidare la squadra. Mostra infatti che, sebbene tu abbia il titolo di capo tecnologico, in realtà non sei il capo tecnico perché non hai autorità. Devi sederti con il tuo manager e avere un cuore a cuore per questo. Nessuno può riuscire in una posizione di leadership tecnica senza il supporto del suo manager e senza l'autorità di modificare le decisioni di progettazione prese dal team senza il suo consenso. Non hai l'autorità per fare il tuo lavoro. Il tuo capo deve capire che sei in una posizione senza vincita e che deve darti il ​​suo sostegno pubblico per migliorare. La responsabilità senza autorità è la peggior situazione possibile in cui trovarti.

Successivamente, la tua squadra ti ha nascosto. Devi parlarne con loro. Dovresti avere una discussione di progettazione con loro prima che facciano qualsiasi sviluppo e molto prima che facciano qualsiasi presentazione pubblica. Va bene delegare parte del progetto (anche se tu, non loro, puoi decidere cosa pensi che dovrebbe essere delegato), ma non va bene per loro di procedere senza informarti. Hanno perso la tua fiducia nascondendoti, ora devono imparare un comportamento migliore. Devi verificare frequentemente con loro per assicurarti che non ti nascondano di nuovo e, in tal caso, dovresti fare una sorta di segnalazione formale del problema alle risorse umane. I lead non sono popolari, quando gli sviluppatori li aggirano deliberatamente dopo che gli è stato detto di non farlo, quindi meritano conseguenze. Non non importa se gli piaci o no, ma chiaramente al momento non ti rispettano. Devono avere delle conseguenze per il loro comportamento inappropriato o peggiorerà. Tuttavia, non è possibile risolvere questa parte del problema finché non si risolve il problema del supporto di gestione.

Successivamente hai fatto esplodere pubblicamente, devi scusarti pubblicamente. Questo ti aiuterà a ricostruire la tua reputazione.

Quindi devi prendere da parte ognuna delle persone privatamente e dire loro le conseguenze per il loro continuo comportamento scorretto (una volta che hai ottenuto il consenso del tuo manager per permetterti di dare loro conseguenze). Elogio pubblico e sostegno, le critiche private dovrebbero essere la tua regola. Potrebbe anche essere necessario effettuare il check-in con loro più frequentemente al di fuori delle riunioni del gruppo in modo che non possano accecarti.

Ora, dal momento che sia quelli sopra che quelli sotto credono chiaramente di essere qualcuno che può essere ignorato e non informato, è necessario fare un'anima seria cercando te stesso su ciò che li sta facendo mancare di rispetto. Devi anche decidere se non saresti più felice di non essere un capo tecnologico o se dovresti trasferirti in un posto dove avrai l'autorità di andare con la responsabilità. Se decidi di voler rimanere nell'isposizione, dovrai chiedere alle persone di livellare con te sul perché ti trattano così male. Sarà doloroso e probabilmente non vorrai sentire la risposta, ma devi sapere perché sei percepito nel modo in cui ti percepiscono chiaramente.