Tecnico o Manager
Attenzione: questa non e' una storia. Nel senso che parlero' del mio precedente lavoro e mi rifieriro' a fatti avvenuti, ma non c'e' una "storia" dietro.
Mi spiego meglio: da come si e' intuito (sic) non (ho) avevo molta simpatia per quello che rivestiva i panni del mio 'capo', ma lui aveva le sue ragioni. Ragioni che spiegano le sue azioni, ma non le giustificano. Se uno va a fare una rapina, puo' spiegare la cosa con la mancanza di soldi o simile, ma questo non lo giustifica. Spiega solamente il perche' viene fatta una certa cosa.
E per spiegare perche' il mio "capo" non agiva come un "capo", dobbiamo andare indietro nel tempo e parlare, in generale, di come nascono le aziende. Non solo quelle di informatica.
Quando quella che sarebbe diventata, un giorno, la ditta per la quale lavoravo venne creata, fu per un accordo tra due persone principalmente. Quello che sarebbe diventato il Grande Capo (GC), che aveva i soldi e vedeva un modo di farne di piu' e quello che sarebbe poi diventato il CTO che aveva capacita' tecniche da vendere e voleva continuare a divertirsi con i suoi giocattoli preferiti: i computers e BSD. I due trovarono un accordo.
GC comincio' con il radunare un gruppo di sviluppatori, project manager e grafici e li mise a produrre siti web, CTO comincio' a costruire l'infrastruttura su cui si sarebbero basati i siti che l'altra parte costruiva. Quando CTO si rese conto che non riusciva a stare dietro a tutto quanto, assunse un paio di persone, ma continuava a fare le cose di suo e si aspettava che quelli che aveva assunto facessero, piu' o meno, la stessa cosa.
Ora, se siete attenti avrete capito immediatamente la differenza di approccio dei due. Uno agiva da Manager, l'altro agiva da Tecnico. CTO rimase sempre un Tecnico alla base. Quando si ponevano dei problemi lui cominciava a pensare a come sviluppare del software o a come organizzarlo in modo da aggirare il problema, GC cominciava a pensare a "come possiamo sub-appaltare la cosa". Sono due strategie molto diverse.
Attenzione: non dico che una delle due sia giusta e l'altra sbagliata. Ma sono drasticamente diverse ed in certi casi una delle due funziona bene mentre l'altra funziona bene in altri casi.
Poi, un bel giorno, GC decise che era il momento di fare un altro passo avanti. Si mise d'accordo con altri 3 e l'intera azienda improvvisamente divenne una Holding. Incomincio' cioe' ad acquisire in toto altre societa', i loro clienti ed il loro personale.
CTO si ritrovo' di colpo non a capo di una mezza dozzina di tecnici, ma a capo di diversi dipartimenti con un centinaio di persone che lui non aveva mai visto prima. E scopri' che doveva cominciare a fare veramente il CTO e smetterla di giocare.
Allo stesso tempo, qualcuno doveva assumersi l'onere di "dirigere" quello che era il vecchio gruppo di tecnici.
Questo onere venne delegato a DB, che era (credo) quello con la piu' elevata anzianita' di servizio.
Ora, il delegare l'incarico a DB e' stata una azione molto logica, purtroppo pero', piu' che la logica si sarebbe dovuto guardare alla funzionalita' della cosa. Il problema e' che il lavoro di un tecnico e quello di un "manager" (o Team Leader, che e' la stessa roba alla fine) sono molto diversi tra loro.
Tanto tempo fa, lessi un libro Fantasy, non mi ricordo bene il titolo ma non ha molta importanza, nel libro ad un certo punto il vecchio mago che stava addestrando il suo apprendista gli disse "se vuoi fare il mago, devi fare il mago". La frase li' per li' non ha molto senso, ma il significato e' chiaro. Se vuoi (o devi) ricoprire un certo incarico, devi cominciare a fare il lavoro che tale incarico comporta. Il compito di un soldato e' combattere. Il compito di un generale e' dire al soldato dove andare, chi combattere e per quanto tempo, non e' andare lui a combattere.
Il compito di un Manager, e' gestire il lavoro e dare ordini al personale, non fare lui il lavoro. Quello e' il compito del Tecnico.
Il manager deve:
- decidere quali attivita' devono essere svolte e con quali priorita'
- decidere CHI dei suoi tecnici e' meglio assegnare a quali lavori e con quali priorita'
- levarsi dalle palle e lasciare i tecnici al lavoro
- controllare se i lavori sono stati fatti, se ci sono dei problemi e chi prendere a calci in culo
- riprendere da 1.
Avendo ricoperto il ruolo di "team leader" e "lead developer" per qualche tempo, posso dire senza tema di essere smentito che... NON E' FACILE MANCO PER UN CAZZO!
Seriamente, il lavoro di un manager e' molto piu' impegnativo del lavoro di un tecnico e richiede la massima disciplina per essere portato a termine con successo. Non solo bisogna essere in grado di organizzare il PROPRIO lavoro, bisogna anche essere in grado di organizzare il lavoro di tutti gli altri in modo tale che tutte le attivita' si incastrino insieme con un perfetto gioco di Tetris per massimizzare il punteggio.
Bisogna pensare a tutte le possibili cose che possono andare (e probablimente andranno) male ed a come minimizzare i problemi.
Bisogna considerare come fare "crescere" il personale senza irritarlo o frustrarlo inutilmente e senza che il lavoro di tutti gli altri ne soffra.
E bisogna ripetersi in continuazione che NO, TU NON DEVI FARE IL LAVORO, DEVI FARLO FARE AGLI ALTRI. E' troppo facile dire "questa cosa la faccio io che ci metto di meno". Se nessun altro sa farla, forse e' il momento di spendere un po' di tempo spiegando cose e pensando a corsi di aggiornamento tecnico per tutto il resto del 'team', perche' TU NON SEI ETERNO.
Devi conoscere i tuoi sottoposti, sapere in cosa sono bravi ed in cosa sono meno bravi, sapere quanto puoi chiedere e sapere quando puoi chiedere e sapere come dividere le attivita' tra le varie persone.
E per ultimo, se tu chiedi ad uno dei tuoi tecnici di darti la sua opinione su una cosa tecnica, ASCOLTA QUELLO CHE CAZZO TI DICE. Magari la sua opinione e' completamente l'opposto di quello che volevi sentirti dire, ma magari ha ragione anche lui.
Tutto questo e', in una parola "fare il manager". E come si puo' intuire, e' il contrario di quello che DB faceva e/o voleva fare.
Cosa succede quando un tecnico viene spostato di ruolo a "manager" e non riesce a capire che il suo compito non e' piu' fare il tecnico? Ecco... Succede quello che e' successo a me.
Io riferivo al "manager" dei problemi organizzativi e quindi di "management" (l'attivita' X che doveva essere fatta non e' stata fatta ed adesso siamo in ritardo, l'attivita' Y e' stata fatta con il culo e deve essere rifatta...) mentre DB cercava soluzioni tecniche (usiamo il tool K per tenere traccia delle attivita', usiamo uno script per verificare il funzionamento della cosa...) invece di applicare soluzioni organizzative (assegnare l'attivita ad una persona e CONTROLLARE CHE SIA SVOLTA).
Il risultato e' che qualcuno, ad un certo punto, decide di andarsene.
Una delle cose "divertenti" (nel senso non-divertente del termine) e' che ad un certo punto DB domando' -a me- che cosa avrebbe dovuto fare al riguardo un certo problema. Al che io gli risposi di fare il suo lavoro: di fare il manager. Ed al suo commento che "non e' cosi' facile", io risposi "se non vuoi fare il manager, vai dal tuo manager (che non ho idea di chi sia e non mi interessa saperlo) e digli che tu non vuoi fare il manager e che scelga qualcun altro". Perche' quella e' l'unica cosa logica da fare se ti viene appioppato un lavoro che non e' quello che tu sei capace di fare e non vuoi impararlo.
Davide
02/07/2017 13:36
