A capo di una squadra, sono prepotente?

12

Sono in quella che mi sembra una posizione molto strana. Sono "team lead" nel ruolo di un particolare progetto, Sr. Software Engineer, nel titolo di lavoro. Nella mia squadra ho 4 sviluppatori, uno dei quali svolge un ruolo simile in un altro progetto, ma ora al mio è stata data 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 è così sicuro di quello comunque.

Ho cercato di ottenere chiarimenti sul motivo per cui il mio ruolo è esattamente diverse volte. È stato difficile per me capire dove inizia e dove finisce la mia autorità, se ne avessi persino una. La risposta con cui sto lavorando è che sono "il capo tecnico" del team. Ciò sembra significare che la mia autorità è al di sopra delle decisioni tecniche riguardanti l'architettura, la progettazione e gli standard di processo / codifica in quanto riguardano il codice prodotto stesso.

Oggi è venuto fuori qualcosa e i risultati del codice che ho delegato a uno dei membri del mio team sono stati mostrati al resto della compagnia nel nostro incontro di Scrum show-it-all-off. La persona rappresentante del cliente si esibisce. Oggi mi è stato mostrato qualcosa di veramente in disaccordo e nessuno mi aveva mai chiesto se volevo dire qualcosa 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 progetto, arrotondate, non arrotondate) hanno fornito campi di accesso per ogni permutazione. Abbiamo quindi il valore in unità arrotondate, unità di progettazione arrotondate, unità di documenti non circoscritte, unità di progettazione senza soluzione di continuità. Ogni record con cui l'utente desidera lavorare ha molti di questi valori e ognuno è permutato in questo modo.

Lo odio davvero.

Le persone a cui abbiamo mostrato questo vogliono essere sicuri che l'API che usiamo per i report sia la stessa del modo in cui facciamo cose come esportare i dati in Excel. Sfortunatamente, ora stiamo guadagnando questo slancio in una direzione che ritengo sia veramente, molto brutta.

Mi sono un po 'turbato al prossimo incontro e ho chiesto alle due persone che avevano fatto questo: "Perché non sono stato coinvolto in questa decisione ??" È un problema che continua a venire e ho un momento difficile sembra solo che le persone della squadra che dovrei portare mi chiedano se voglio essere coinvolto. A volte non lo faccio e penso che tutto ciò che faranno andrà bene. Altre volte lo faccio. A meno che la gente non mi chieda, è difficile persino sapere che sta succedendo qualcosa che ha bisogno del mio contributo e non mi danno questa opportunità.

Sfortunatamente, la mia autorità non si estende alle persone che dicono: "La prossima volta che andrai a fare qualcosa del genere senza nemmeno parlarmi, sarai disciplinato". Questo è un problema di "PR" che è un settore che chiaramente non è nel mio ambito di autorità. Per me va bene, visto che non voglio avere a che fare con quel tipo di schifo se qualcun altro lo desidera.

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

Naturalmente penso che ho ragione ... lo faccio sempre. Non dico cose che penso siano BS. Penso che avrei dovuto essere contattato per questo problema e ho chiesto se avessi un'idea migliore. La mia direzione per questo sarebbe stato in realtà 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 ulteriore accesso in futuro, se lo si desidera. Non avrei mai approvato o raccomandato l'attuale implementazione e non credo che avrebbe dovuto vedere la luce del giorno.

La domanda è, sono io che sono irragionevole?

Bene, noi due ne abbiamo parlato e abbiamo convenuto che entrambi abbiamo "lasciato cadere la palla" e sembra che siamo sulla stessa pagina. Lunedì mattina ... Cercheremo di assicurarci che il mio ruolo sia chiaro nel team e che sì, deciderò quando ci sarà un cambiamento di progetto o di attività che deve accadere; Mi viene proposto e sono d'accordo o decido che ho bisogno di guardare più a fondo. Poi ci sono altre cose su cui posso provare a lavorare per assicurarmi che sappiano che possono venire da me.

    
posta Crazy Eddie 13.06.2011 - 22:03
fonte

10 risposte

17

Sembra che tu debba monitorare i commit della fonte. Perforce ha questa capacità in modo nativo, Git ce l'ha attraverso i ganci, altri sono sicuro che hanno i loro metodi. Non devi fare il pasticcio di ogni commit, ma almeno averli notificati e diffonderli ti darà un breve sguardo su tutto ciò che sta succedendo nel tuo progetto.

Per quanto riguarda il tuo manager che dice che è necessario delegare, non sono così sicuro di essere d'accordo - con un team di quattro sviluppatori, dovresti essere in grado di gestirlo. Più altro, potrei essere schierato con lui (o lei). Ovviamente, anche nelle attività delegate, dovresti chiedere aggiornamenti di stato o istruzioni dettagliate sulle modifiche alla progettazione, ecc.

Niente negativo dovrebbe ever essere inserito nelle riunioni - sembra che sia tu che il tuo manager abbiate lasciato cadere la palla su questo. La cosa peggiore in assoluto che tu possa mai fare a un pari è imbarazzante. Come guida (come con il tuo manager), devi essere accessibile e affidabile. Sminuire qualcuno porterà al risentimento, che metterà a rischio la tua capacità di guidare la tua squadra (oltre a portare a dipendenti scontenti).

I odio ascoltare la parola "disciplina" da chiunque abbia un ruolo principale. Disciplinare (almeno in questo contesto) è negativo e non produttivo. Lavorare con qualcuno (personalmente e non in una riunione), scoprire perché hanno fatto qualcosa e fornire alternative se non siete d'accordo con le loro soluzioni proposte è quello che dovrebbe essere fatto. A volte, scoprirai che la persona con cui stai lavorando è giusta e il tuo istinto è sbagliato. Perché? Hanno dedicato più tempo a quel problema specifico di quello che hai.

Qualcos'altro che mi preoccupa è "Penso sempre che abbia ragione". IMO, questo è l'atteggiamento peggiore da qualsiasi vantaggio. dovresti ovviamente avere fiducia nelle tue capacità, ma renditi conto che se non tieni il collo in profondità in un problema specifico, allora più volte, i tuoi suggerimenti stanno uscendo dalla tua parte posteriore (non importa quanta esperienza hai) e potrebbero non essere i migliori. Se qualcuno che è che si concentra su un problema specifico fornisce un'alternativa, allora è il tuo lavoro (beh, così come il loro, a seconda del proprio livello di esperienza) a dimostra perché la tua è migliore, non solo dire "Sono il protagonista e penso sempre che ho ragione", che è ciò che la tua frase mi porta a credere.

Per completare l'operazione

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

Tuttavia, è anche il tuo lavoro per garantire la qualità complessiva del sistema e del codice, che devi fare da solo. La tua azienda utilizza le revisioni del codice? I tuoi programmatori hanno progettato ciò su cui stanno lavorando prima di entrare nel codice? Altrimenti, potresti voler iniziare a utilizzare questo tipo di meccanismi di controllo della qualità.

    
risposta data 13.06.2011 - 22:23
fonte
9

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 dei cattivi manager, e preferirei programmare piuttosto che gestire i programmatori ).

I manager spesso non hanno l'autorità per tutto ciò che devono fare. Fare le cose comunque è un segno di un buon manager. Hai bisogno di trovare modi per convincere la gente 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 interesse per i tuoi subordinati come persone.)

I manager devono anche delegare, anche quando fa male. Probabilmente trascorrerai più tempo a gestire questo problema rispetto a quanto avresti speso scrivendolo tu stesso, e va bene. Una volta affrontato, le persone che lo hanno fatto dovrebbero aver imparato qualcosa e sono meno propensi a fare le cose nel modo sbagliato in futuro.

Il modo giusto per gestire qualcosa di simile è in privato, in primo luogo chiedendo agli sviluppatori perché hanno fatto il display in questo modo. Non in riunione, e non assumendo in anticipo che hai ragione e che hanno torto (anche se hai ragione e hanno torto). Dare loro la possibilità di spiegare. Ciò non significa che devi andare con la loro decisione; dopotutto, sei il capo tecnico. Significa che devi dare loro ragioni per farlo a modo tuo, e dovresti affrontare tutti i problemi fondamentali che si presentano durante quella riunione privata.

Inoltre, i manager hanno la responsabilità di ciò che esce dalla loro gente. Dovresti cercare di non essere accecato da qualsiasi cosa facciano, soprattutto di fronte a un cliente. Ciò potrebbe comportare il tenere traccia dei check-in del codice o avere una rapida mini-conferenza con i tuoi sviluppatori (anche se devi stare attento a questo, non vuoi interromperli quando sono nella zona). Forse dovresti parlare con tutti gli sviluppatori il pomeriggio prima dell'incontro con il rappresentante del cliente.

    
risposta data 13.06.2011 - 23:02
fonte
4

Non prenderlo di persona

È uno sforzo di squadra. La tua guida tecnica, non l'unico ragazzo del progetto. Dovresti concentrarti sul fatto che il team impari dagli errori o cambi il processo.

Guida e impara

Una parte di qualsiasi posizione dirigenziale, inclusa una guida tecnica, è capire che fai il meglio che puoi con le persone che hai. Più la squadra lavora insieme, più sapranno quando portare le cose e quando no. Assicurati solo di non cadere nella trappola di dettare alla tua squadra. Controlla 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 essere sempre l'ultima risorsa e in genere significa che devi licenziare qualcuno o hai fallito nel tuo ruolo.

Rivedi prima della presentazione del cliente

Se sei il responsabile di un progetto, perché non hai rivisto la funzionalità e l'implementazione prima di presentarla?

Se è sbagliato, risolvilo

Spiega chiaramente perché qualcosa è sbagliato e cambialo. È più costoso, ma se è veramente sbagliato, risolvilo. Se non è sbagliato, solo diverso da come volevi che le cose fossero fatte, poi di nuovo; capisci che non sei l'unico che lavora al progetto.

    
risposta data 13.06.2011 - 22:25
fonte
3

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

Quindi finisci per andare dal tuo manager con "Quindi invece di lavorare su ciò che è nelle specifiche, hanno deciso di fare invece [feature]. Ora siamo indietro, a causa di una funzionalità che non è stata approvata nel primo luogo ".

Quindi puoi iniziare a lavorare sulla rimozione della feature una volta che gli sviluppatori sono stati riassegnati.

Modifica > E no, non penso che tu stia prepotente. Il loro lavoro finisce per essere il tuo culo.

    
risposta data 13.06.2011 - 22:16
fonte
2

Mi trovo spesso nella stessa posizione e lo faccio crescere in riunioni e le discussioni non sembrano arrivare da nessuna parte. A volte come ultima risorsa prima di rassegnarmi ad andare con la decisione presa (albiet non mio), invio una mail alle parti interessate affermando questo in bianco e nero con le mie ragioni per cui.

Quindi archiverei quell'email in modo da assicurarmi di averla per riferimento futuro nel caso in cui fosse necessario più avanti quando un manager o un cliente chiede perché qualcosa è stato fatto in quel modo, o perché un cambiamento costa così tanto da risolvere.

    
risposta data 13.06.2011 - 22:33
fonte
2

Penso che tu abbia sbagliato a farlo apparire come hai fatto tu, come hai riconosciuto. Non hai torto nel dire che dovresti avere qualche input sul design a questo livello, ma non sono sicuro di come pensi che sia ragionevole implementarlo. Le persone non eseguiranno un progetto da te se lo considerano semplice; Dal momento che possono essere altrettanto facilmente sbagliati sul fatto che è semplice quanto riguarda il design stesso, non troverete persone che si offrono volontariamente per mostrarvi tutti i loro progetti sbagliati. A questo punto sono per lo più curioso delle tue abitudini di lavoro e dei tuoi schemi di comunicazione, ma a prescindere da come tutto ciò venga fatto a volte sarai solo accecato da queste cose. In mancanza di una revisione diligente di ogni commit, non sono sicuro di come provarlo.

    
risposta data 13.06.2011 - 22:47
fonte
1

Anch'io mi sento così emotivamente:

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

ma ho il senso intellettualmente di sapere che di tanto in tanto mi sbaglio. So anche quando scegliere un combattimento - non puoi discutere di tutto, e a volte un accordo inaspettato da parte tua può fare miracoli.

    
risposta data 13.06.2011 - 22:14
fonte
1

Che cos'è un vero leader?

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

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

Ma di nuovo, può capitare che tu possa essere un leader del team ma non guidare il tuo attuale progetto. Il caso peggiore è quando il cliente guida il progetto. A questo punto, se il progetto fallisce (e fallirà), allora non è una 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, il tuo manager ha violato il tuo stato, ha abbassato la morale delle "tue" persone e non ha aiutato affatto.

    
risposta data 13.06.2011 - 23:02
fonte
1

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

La risposta non è preoccuparsi di cose che vanno male - lo fanno sempre - invece di preoccuparsi di correggerle in un secondo momento, in modo costruttivo.

Se continui a seguire le comunicazioni, non solo puoi delegare, ma puoi lasciare che le persone anziane vadano fuori e facciano quello che sanno essere necessario senza sempre trattenerle con recensioni, discussioni e tentativi malintenzionati per controllarle. Fidati di loro per fare la cosa giusta, e sii lì per "chattare" su ciò che sta accadendo in modo che tu possa essere tenuto al corrente (e ficcare il naso quando senti che è davvero necessario).

    
risposta data 14.06.2011 - 10:34
fonte
0

Hai diversi problemi. Prima il tuo manager si è schierato dalla tua squadra e ti ha detto di delegare di più. Questo dimostra una mancanza di fiducia nella tua capacità di guidare la squadra. Di fatto mostra che mentre tu hai il titolo di lead tecnologico, in realtà non sei il leader tecnologico perché non hai autorità. Devi sederti con il tuo manager e avere un cuore a cuore per questo. Nessuno può avere successo in una posizione di comando tecnica senza il supporto del suo manager e senza l'autorizzazione a cambiare le decisioni di progettazione prese dal team senza il suo consenso. Non hai l'autorità per svolgere 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 peggiore situazione possibile per trovarti dentro.

Successivamente, la tua squadra ti ha accecato. Devi parlarne con loro. Dovresti avere la discussione del design con loro prima che facciano qualsiasi sviluppo e molto prima che facciano una presentazione pubblica. È giusto delegare parte del design (anche se tu, non loro, puoi decidere cosa dovresti delegare), ma non è giusto che procedano senza informarti. Hanno perso la tua fiducia accecandoti, ora devono imparare un comportamento migliore. Devi controllare frequentemente con loro per assicurarti che non ti stiano accecando di nuovo e se lo fanno, dovresti fare una sorta di segnalazione formale del problema alle Risorse Umane. I lead non sono portati ad essere popolari, quando gli sviluppatori deliberatamente li circondano dopo essere stati avvisati di non farlo, quindi meritano conseguenze. Non importa se ti piacciono o no ma chiaramente al momento non ti rispettano. Hanno bisogno di avere conscenze per il loro comportamento inappropriato o semplicemente peggioreranno. Tuttavia, non è possibile correggere questa parte del problema finché non si risolve il problema del supporto di gestione.

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

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

Ora, francamente, dal momento che entrambi quelli sopra e sotto, tu ritieni chiaramente che sei qualcuno che può essere ignorato e non informato, devi fare un po 'di ricerca seria su ciò che sta causando loro di mancarti di rispetto. Devi anche decidere se non saresti più felice di non essere un capo tecnico o se dovresti trasferirti in un posto dove il tuo avrà l'autorità di assumersi la responsabilità. Se decidi di voler rimanere nell'isposizione, dovrai chiedere alle persone di stare 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.

    
risposta data 14.06.2011 - 00:27
fonte

Leggi altre domande sui tag