From 22be9804fb5201ad5f1e0321b57186b8d7b09329 Mon Sep 17 00:00:00 2001 From: Enrico Maria Cestari Date: Fri, 17 May 2024 14:03:54 +0200 Subject: [PATCH 01/17] Capitolo Leadership - Draft --- docs/it/leadership.md | 105 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 docs/it/leadership.md diff --git a/docs/it/leadership.md b/docs/it/leadership.md new file mode 100644 index 00000000..a7941839 --- /dev/null +++ b/docs/it/leadership.md @@ -0,0 +1,105 @@ +# TecnoLeadership + +### LA GRATIFICAZIONE RITARDATA + +Forse avete giocato a FIFA. Oppure a PES, o ad un altro gioco di calcio. Se questo è il vostro caso, conoscete _quella sensazione_. Sapete cosa provate quando fate gol, soprattutto se farlo è stato difficile, ha richiesto tanto impegno, se la squadra avversaria era forte e vi siete dovuti mettere alla prova con tutte le vostre forze. + +Le/I developer provano una sensazione simile, ogni volta che risolvono un problema. Ogni volta che il loro codice _funziona come vogliono_. Per quanto i sistemi informatici siano complessi, per quanto anche un singolo programma possa esserlo, se qualcosa non funziona chi sviluppa sa che _il computer ha ragione_. Magari non riesce subito a capire perché, ma sa che sta facendo qualcosa di sbagliato. Ha un feedback immediato, e può rimettersi al lavoro per comprendere cosa non sta girando e perché, e sistemarlo. + +Ecco, questa dal punto di vista di chi scrive è la più grande differenza tra un mestiere come quello della developer e quello di una manager. + +Quando decidiamo di passare ad un ruolo manageriale, entriamo in contatto con dei sistemi ancora più complessi da prevedere: le Persone e le Organizzazioni di Persone. Improvvisamente, il feedback smette di essere immediato, e i risultati delle nostre azioni li vediamo ad una distanza di tempo enormemente più grande (certo, se insulto deliberatamente un collega probabilmente avrò subito un feedback negativo circa la mia azione, ma converrete che si tratta di un caso limite - ed anche in quel caso potremmo sorprenderci circa l’imprevedibilità delle reazioni umane). + +Quella sensazione del “gol”, del momento liberatorio, quella voglia di urlare di soddisfazione, quel meccanismo di ricompensa, semplicemente nel mestiere del manager non c’è. È rimandata nel tempo, e questo è il primo aspetto su cui tendo a mettere in guardia una persona che da un ruolo tecnico vuole passare a quello manageriale. + +Potreste esclamare: “Ma ci sono dei momenti tremendamente esaltanti nella carriera manageriale, soprattutto quando le cose vanno bene!”, ed è certamente vero, ma è comunque una sensazione diversa. Quando, durante la prima esperienza di fundraising io e il team con cui lavoravo siamo arrivati a chiudere l’accordo con i finanziatori, la nostra idea era di festeggiare in stile “Champions League appena vinta”. In realtà, eravamo talmente stanchi dopo le lunghe ore dal notaio, e talmente perplessi circa i termsheet complessi che avevamo dovuto studiare ed apprendere in tempi brevi, che la sensazione fu sì di grande soddisfazione, ma comunque non “esplosiva”. + +A livello neurologico, questo meccanismo è ben documentato: quando completiamo un task con successo, il nostro cervello rilascia dopamina, il neurotrasmettitore responsabile di quella sensazione di realizzazione e piacere. Non a caso, i game designer più bravi usano con caparbietà questa dinamica cerebrale nella creazione dei loro videogiochi, per tenerci agganciati e spingerci a continuare a giocare. + +Primo avvertimento quindi: il feedback non è immediato, né quando è positivo né quando è negativo. + +Prendete una decisione oggi, e non sapete di preciso quando e che risultati otterrete. + + +### DIVERSI TIPI DI LEADER TECH + +Altro punto da chiarire: cos’è, ma soprattutto cosa fa un “leader” in ambito tecnologico? Se proviamo a supportarci con le etichette e i job title, stiamo pur certi di rimanere confusi. CTO, Engineering Manager, VP of Engineering, Head of, Tech Leader, Staff Engineer, Principal Engineer - aggiungete a piacere ed attribuite a ciascuno un significato piuttosto arbitrario. + +Fatto questo, traslate la vostra mappatura in un’altra azienda, e vi renderete conto di dover ricominciare da capo. + +Due criteri che chi scrive ritiene più utile adottare per definire meglio la tipologia di “tech leadership” sono: + +1. Il livello di astrazione rispetto alla materia prima, cioè ai dettagli implementativi ed operativi necessari per rendere concrete le idee da realizzare + +2. La trasversalità ed ampiezza degli argomenti da toccare + +**Nota bene**: no, il “numero di persone a riporto” non lo metto tra i parametri. Sia perché detesto il termine “riporti” (ricorda uno stile manageriale che sicuramente funzionava bene nei film di Fantozzi ma non nel nostro contesto), sia perché la quantità di persone di un team dovrebbe essere frutto di un ragionamento molto ampio che complicherebbe inutilmente la descrizione. + +Partendo dai due concetti espressi si può arrivare ad un’altra distinzione chiave tra un ruolo tecnico ed uno manageriale: + +- Un/a developer in un contesto sano dovrebbe mantenersi in uno stato di flow più lungo possibile concentrandosi unicamente sul codice per lunghi periodi di tempo, e magari su una stessa regione del dominio applicativo (si, lo so, nella pratica accade di rado - ma stiamo ragionando di un _contesto sano_, no?) + +- Una persona con un ruolo manageriale non può adottare lo stesso approccio, ma deve accettare sia un context switching frequente tra compiti anche molto diversi che anche una visione più ampia a livello di domini ed ambiti di azione + +Qui urge un disclaimer: “visione più ampia”, non equivale a “meglio”, e non equivale a “persona di livello più importante”. Ritengo che per garantire un approccio costruttivo nel mondo tecnologico sia necessario uscire da questi stereotipi o bias inconsci. Ne parlerò meglio nella sottosezione relativa al Dual Ladder. + +Visione più ampia significa livello di zoom diverso, guardare le cose dall’alto. Questo non è necessariamente più semplice, e non è necessariamente più difficile. + +Immaginiamo di essere su un elicottero. Un buon leader deve sapersi muovere su più “aree geografiche” assicurandosi che ciascuna di esse si mostri armoniosa ed in buone condizioni. In alcuni casi è necessario scendere di quota e osservare più da vicino - e raramente l’elicottero dovrebbe atterrare. Quando se ne presenta bisogno, l’intento non è solo quello di “risolvere un problema”, ma soprattutto gettare le basi affinché tale intervento non sia più necessario in futuro. + +Vediamo come classificare dei possibili “ruoli” di leadership in relazione ai diversi livelli di astrazione e trasversalità - ma ricordiamoci che non sono regole o dogmi, anche se un pò di standardizzazione potrebbe aiutare in fase di recruiting e comprensione tra aziende diverse: + +- **Tech Leader** + + - È uno/a sviluppatore di elevata seniority e capacità tecnica - la sua astrazione dal codice e dall’operatività non è totale, il suo ambito e trasversalità riguardano l’intero dominio applicativo del team in cui lavora. + + - Il suo ruolo è quello di garantire la qualità del codice e delle scelte tecnologiche del suo team, sia scrivendo codice che soprattutto assicurandosi che le altre persone del team lo facciano nel migliore dei modi. + + - Non ha persone formalmente a riporto, ma deve indubbiamente guadagnarsi il rispetto e la fiducia dei suoi compagni di squadra grazie alla sua autorevolezza. Rispetto ad un Senior Developer, in ogni caso, il suo ruolo gli conferisce anche l’autorità per prendere delle decisioni (limitatamente all’ambito tecnico) nel momento in cui il team non dovesse riuscire a farlo in autonomia. + +- **Engineering Manager** + + - È una figura manageriale - anche se in alcuni contesti gli Engineering Manager scrivono ancora codice, chi scrive ritiene che non dovrebbe essere il caso in un team del tutto funzionale; il focus di questi ruoli deve essere sulle Soft Skills + + - La trasversalità è più ampia di quella di un Tech Lead o di un developer, in quanto la conoscenza deve estendersi sugli ambiti di dominio di tutti i team gestiti + + - Il suo ruolo è quello di People Manager degli sviluppatori di uno o più team - è inevitabile che debba conoscere le tematiche tecnologiche, soprattutto in ottica di comprensione delle complessità che i tecnici affrontano nel day by day, ma la sua missione principale è assicurarsi che le dinamiche nei suoi team funzionino bene. Imperativi in questo senso sono i 1:1 con tutte le persone del Team nonché un forte allineamento con i Tech Lead e (nel caso ci siano), i Product manager + + - Da organigramma, le persone dei team che gestisce sono formalmente a suo riporto + +- **VP (o Head of) of Engineering** + + - Il livello di astrazione aumenta; un tipo di figura di questo tipo non ha senso che sia coinvolta nella scrittura o nella revisione diretta di codice + + - La trasversalità è ampia: tendenzialmente questa figura deve avere una vista sull’intero dominio ingegneristico aziendale + + - Questo tipo di figura ha senso quando l’organizzazione diventa complessa, e ci sono diversi Engineering Manager con tanti team di sviluppo, ciascuno dei quali ha un prodotto (o una fetta di prodotto) da gestire e portare avanti + +Ho volutamente tenuto fuori il CTO (o CIO o chiamatelo come preferite), perché dal mio punto di vista questa figura è ancora diversa e non legata esclusivamente alla parte di Engineering. Questo è un altro bias molto frequente. In questo caso il livello di astrazione è ancora più alto e la trasversalità si estende ai processi dell’intera azienda, sia per quanto riguarda la cosiddetta “digitalizzazione” dell’organizzazione che anche per tutte le qustioni finanziarie ed amministrative, nonché gli allineamenti con gli executive ed il board o, in caso di aziende che richiedono finanziamenti, coinvolgimento in fase di fundraising. + + +### DUAL LADDER + +Nel paragrafo precedente ho esplicitato come il tema della “visione più ampia” che generalmente un manager ha o dovrebbe avere non debba essere visto come una sorta di “aumento di livello di competenza”. + +Per reiterare l’importanza di questo concetto tengo a parlare di un punto molto caro a chi scrive: il principio del dual ladder. In ambito tecnologico fatico a vedere un approccio diverso che possa avere successo. Partiamo da tre concetti chiave da tenere a mente: + +- Il software engineering ricade nell’ambito di _knowledge work_, in cui le competenze specialistiche sono estremamente variegate e complesse. + +- Un manager non potrà mai essere un _superset_ delle conoscenze di tutto il suo Team, e qualora ciò dovesse accadere allora la prima domanda da porsi sarebbe “quali sono le carenze del Team?” + +- Le skill manageriali sono notevolmente diverse da quelle richieste ad un tecnico (di nuovo, non più o meno complesse - _diverse_) ed il tempo per formarsi è limitato per tutti, ergo bisogna scegliere. + +Tradizionalmente, in molte aziende si sono visti schemi di crescita lineari o piramidali, in cui “prima si parte dal lavoro operativo, poi si diventa bravi a farlo e allora si può diventare manager di altri”. + +Questo approccio può funzionare in alcuni casi, soprattutto quando il lavoro operativo è sufficientemente semplice e ripetibile da essere “insegnato” da un singolo esperto ad un team più junior, che a quel punto può essere coordinato. + +Ma nell’ambito tecnologico, a causa dei due principi visti prima, questo approccio non scala. + +Quello che un buon manager dovrebbe fare è creare un ambiente in cui le competenze specialistiche possano brillare, generare valore ed evolvere insieme alle Persone che le coltivano. + +Alcuni tecnici _non_ vogliono diventare manager, e fanno bene a perseguire il loro sogno di carriera: diventare sempre più bravi nella loro area di competenza! + +Da un punto di vista aziendale, se si crede in questi presupposti, è importante creare un sistema incentivante anche per chi non vuole crescere in un percorso manageriale. Le figure tecniche devono sentire riconosciuto e premiato il loro continuo perfezionamento, a prescindere dal fatto che rimangano “individual contributor”. Quando parlo di sistema incentivante intendo ovviamente un percorso di carriera, che possa portare alle stesse soddisfazioni (anche a livello retributivo) di un manager di pari livello; sono sempre le competenze e il valore portato all’azienda che dovrebbero fungere da discriminante, non il job title. + +Il Dual Ladder è una buona soluzione a questo punto, in quanto prevede dei “livelli” di crescita sia per le figure tecniche che per quelle manageriali; molti partono da una base comune ed operativa e poi si biforcano, il che è comunque sensato perché anche un manager di persone Tech deve conoscere la lingua ed il modo di lavorare di quel tipo di Team - guai a mettere un manager generalista in un ruolo di Engineering Manager. \ No newline at end of file From 2381eb1b0a7e2b8101d8211ab5d7b9c7a81f39e4 Mon Sep 17 00:00:00 2001 From: Enrico Maria Cestari Date: Sat, 4 Jan 2025 11:21:06 +0100 Subject: [PATCH 02/17] Apply suggestions from code review Co-authored-by: Michael Di Prisco Co-authored-by: Angelo Cassano --- docs/it/leadership.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/it/leadership.md b/docs/it/leadership.md index a7941839..e975a37a 100644 --- a/docs/it/leadership.md +++ b/docs/it/leadership.md @@ -1,16 +1,16 @@ # TecnoLeadership -### LA GRATIFICAZIONE RITARDATA +## LA GRATIFICAZIONE RITARDATA -Forse avete giocato a FIFA. Oppure a PES, o ad un altro gioco di calcio. Se questo è il vostro caso, conoscete _quella sensazione_. Sapete cosa provate quando fate gol, soprattutto se farlo è stato difficile, ha richiesto tanto impegno, se la squadra avversaria era forte e vi siete dovuti mettere alla prova con tutte le vostre forze. +Forse avete giocato a FIFA. Oppure a PES, o ad un altro gioco di calcio. Se questo è il vostro caso, conoscete _quella sensazione_. Sapete cosa si prova quando fate gol, soprattutto se farlo è stato difficile, ha richiesto tanto impegno, se la squadra avversaria era forte e vi siete dovuti mettere alla prova con tutte le vostre forze. -Le/I developer provano una sensazione simile, ogni volta che risolvono un problema. Ogni volta che il loro codice _funziona come vogliono_. Per quanto i sistemi informatici siano complessi, per quanto anche un singolo programma possa esserlo, se qualcosa non funziona chi sviluppa sa che _il computer ha ragione_. Magari non riesce subito a capire perché, ma sa che sta facendo qualcosa di sbagliato. Ha un feedback immediato, e può rimettersi al lavoro per comprendere cosa non sta girando e perché, e sistemarlo. +Le/I developer provano una sensazione simile ogni volta che risolvono un problema, ogni volta che il loro codice _funziona come vogliono_. Per quanto i sistemi informatici siano complessi, per quanto anche un singolo programma possa esserlo, se qualcosa non funziona, chi sviluppa sa che _il computer ha ragione_. Magari non riesce subito a capire perché, ma sa che sta facendo qualcosa di sbagliato. Ha un feedback immediato, e può rimettersi al lavoro per comprendere cosa non sta girando e perché, e sistemarlo. -Ecco, questa dal punto di vista di chi scrive è la più grande differenza tra un mestiere come quello della developer e quello di una manager. +Ecco, questa dal punto di vista di chi scrive è la più grande differenza tra un mestiere come quello del/della developer e quello di un/una manager. Quando decidiamo di passare ad un ruolo manageriale, entriamo in contatto con dei sistemi ancora più complessi da prevedere: le Persone e le Organizzazioni di Persone. Improvvisamente, il feedback smette di essere immediato, e i risultati delle nostre azioni li vediamo ad una distanza di tempo enormemente più grande (certo, se insulto deliberatamente un collega probabilmente avrò subito un feedback negativo circa la mia azione, ma converrete che si tratta di un caso limite - ed anche in quel caso potremmo sorprenderci circa l’imprevedibilità delle reazioni umane). -Quella sensazione del “gol”, del momento liberatorio, quella voglia di urlare di soddisfazione, quel meccanismo di ricompensa, semplicemente nel mestiere del manager non c’è. È rimandata nel tempo, e questo è il primo aspetto su cui tendo a mettere in guardia una persona che da un ruolo tecnico vuole passare a quello manageriale. +Quella sensazione del “gol”, del momento liberatorio, quella voglia di urlare di soddisfazione, quel meccanismo di ricompensa, nel mestiere del manager semplicemente non esiste. È rimandata nel tempo, e questo è il primo aspetto su cui tendo a mettere in guardia una persona che da un ruolo tecnico vuole passare a quello manageriale. Potreste esclamare: “Ma ci sono dei momenti tremendamente esaltanti nella carriera manageriale, soprattutto quando le cose vanno bene!”, ed è certamente vero, ma è comunque una sensazione diversa. Quando, durante la prima esperienza di fundraising io e il team con cui lavoravo siamo arrivati a chiudere l’accordo con i finanziatori, la nostra idea era di festeggiare in stile “Champions League appena vinta”. In realtà, eravamo talmente stanchi dopo le lunghe ore dal notaio, e talmente perplessi circa i termsheet complessi che avevamo dovuto studiare ed apprendere in tempi brevi, che la sensazione fu sì di grande soddisfazione, ma comunque non “esplosiva”. @@ -100,6 +100,6 @@ Quello che un buon manager dovrebbe fare è creare un ambiente in cui le compete Alcuni tecnici _non_ vogliono diventare manager, e fanno bene a perseguire il loro sogno di carriera: diventare sempre più bravi nella loro area di competenza! -Da un punto di vista aziendale, se si crede in questi presupposti, è importante creare un sistema incentivante anche per chi non vuole crescere in un percorso manageriale. Le figure tecniche devono sentire riconosciuto e premiato il loro continuo perfezionamento, a prescindere dal fatto che rimangano “individual contributor”. Quando parlo di sistema incentivante intendo ovviamente un percorso di carriera, che possa portare alle stesse soddisfazioni (anche a livello retributivo) di un manager di pari livello; sono sempre le competenze e il valore portato all’azienda che dovrebbero fungere da discriminante, non il job title. +Da un punto di vista aziendale, se si crede in questi presupposti, è importante creare un sistema incentivante anche per chi non vuole crescere in un percorso manageriale. Le figure tecniche devono sentire riconosciuto e premiato il loro continuo perfezionamento, a prescindere dal fatto che rimangano _individual contributor_. Quando parlo di sistema incentivante intendo ovviamente un percorso di carriera, che possa portare alle stesse soddisfazioni (anche a livello retributivo) di un manager di pari livello; sono sempre le competenze e il valore portato all’azienda che dovrebbero fungere da discriminante, non il _job title_. Il Dual Ladder è una buona soluzione a questo punto, in quanto prevede dei “livelli” di crescita sia per le figure tecniche che per quelle manageriali; molti partono da una base comune ed operativa e poi si biforcano, il che è comunque sensato perché anche un manager di persone Tech deve conoscere la lingua ed il modo di lavorare di quel tipo di Team - guai a mettere un manager generalista in un ruolo di Engineering Manager. \ No newline at end of file From de414c636193f2de6ce5721568c91b144c442b5a Mon Sep 17 00:00:00 2001 From: Enrico Maria Cestari Date: Sat, 4 Jan 2025 11:21:47 +0100 Subject: [PATCH 03/17] Apply suggestions from code review Co-authored-by: Michael Di Prisco Co-authored-by: Angelo Cassano --- docs/it/leadership.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/docs/it/leadership.md b/docs/it/leadership.md index e975a37a..923b43f9 100644 --- a/docs/it/leadership.md +++ b/docs/it/leadership.md @@ -78,11 +78,11 @@ Vediamo come classificare dei possibili “ruoli” di leadership in relazione a Ho volutamente tenuto fuori il CTO (o CIO o chiamatelo come preferite), perché dal mio punto di vista questa figura è ancora diversa e non legata esclusivamente alla parte di Engineering. Questo è un altro bias molto frequente. In questo caso il livello di astrazione è ancora più alto e la trasversalità si estende ai processi dell’intera azienda, sia per quanto riguarda la cosiddetta “digitalizzazione” dell’organizzazione che anche per tutte le qustioni finanziarie ed amministrative, nonché gli allineamenti con gli executive ed il board o, in caso di aziende che richiedono finanziamenti, coinvolgimento in fase di fundraising. -### DUAL LADDER +## Dual Ladder Nel paragrafo precedente ho esplicitato come il tema della “visione più ampia” che generalmente un manager ha o dovrebbe avere non debba essere visto come una sorta di “aumento di livello di competenza”. -Per reiterare l’importanza di questo concetto tengo a parlare di un punto molto caro a chi scrive: il principio del dual ladder. In ambito tecnologico fatico a vedere un approccio diverso che possa avere successo. Partiamo da tre concetti chiave da tenere a mente: +Per reiterare l’importanza di questo concetto colgo l'occasione per tornare a parlare di un punto molto caro al sottoscritto: il principio del dual ladder. In ambito tecnologico fatico a vedere un approccio diverso che possa avere successo. Partiamo da tre concetti chiave da tenere a mente: - Il software engineering ricade nell’ambito di _knowledge work_, in cui le competenze specialistiche sono estremamente variegate e complesse. @@ -94,7 +94,10 @@ Tradizionalmente, in molte aziende si sono visti schemi di crescita lineari o pi Questo approccio può funzionare in alcuni casi, soprattutto quando il lavoro operativo è sufficientemente semplice e ripetibile da essere “insegnato” da un singolo esperto ad un team più junior, che a quel punto può essere coordinato. -Ma nell’ambito tecnologico, a causa dei due principi visti prima, questo approccio non scala. +Ma nell’ambito tecnologico, a causa dei tre principi visti prima, questo approccio non scala. +Il Command and Control (dire alle persone che sviluppano come fare le cose) porta nella maggior parte dei casi a disfunzionalità, calo di motivazione, deresponsabilizzazione e anche a far perdere valore all'azienda, in quanto le competenze pregiate degli individui non vengono utilizzate nel processo decisionale. + +Peggio ancora, si dovesse ricadere nel meccanismo del micromanagement. Un manager con l'ossessione del controllo a tutti i costi ha il potere di rovinare un team in poco tempo. Quello che un buon manager dovrebbe fare è creare un ambiente in cui le competenze specialistiche possano brillare, generare valore ed evolvere insieme alle Persone che le coltivano. From 74420b329482c19f19294059de3c6f3eb8e5b996 Mon Sep 17 00:00:00 2001 From: Enrico Maria Cestari Date: Sat, 4 Jan 2025 11:26:36 +0100 Subject: [PATCH 04/17] Apply suggestions from code review --- docs/it/leadership.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/leadership.md b/docs/it/leadership.md index 923b43f9..90d7adf9 100644 --- a/docs/it/leadership.md +++ b/docs/it/leadership.md @@ -12,7 +12,7 @@ Quando decidiamo di passare ad un ruolo manageriale, entriamo in contatto con de Quella sensazione del “gol”, del momento liberatorio, quella voglia di urlare di soddisfazione, quel meccanismo di ricompensa, nel mestiere del manager semplicemente non esiste. È rimandata nel tempo, e questo è il primo aspetto su cui tendo a mettere in guardia una persona che da un ruolo tecnico vuole passare a quello manageriale. -Potreste esclamare: “Ma ci sono dei momenti tremendamente esaltanti nella carriera manageriale, soprattutto quando le cose vanno bene!”, ed è certamente vero, ma è comunque una sensazione diversa. Quando, durante la prima esperienza di fundraising io e il team con cui lavoravo siamo arrivati a chiudere l’accordo con i finanziatori, la nostra idea era di festeggiare in stile “Champions League appena vinta”. In realtà, eravamo talmente stanchi dopo le lunghe ore dal notaio, e talmente perplessi circa i termsheet complessi che avevamo dovuto studiare ed apprendere in tempi brevi, che la sensazione fu sì di grande soddisfazione, ma comunque non “esplosiva”. +Potreste esclamare: “Ma ci sono dei momenti tremendamente esaltanti nella carriera manageriale, soprattutto quando le cose vanno bene!”, ed è certamente vero, ma è comunque una sensazione diversa. Quando, durante la prima esperienza di fundraising io e il team con cui lavoravo siamo arrivati a chiudere l’accordo con i finanziatori, la nostra idea era di festeggiare in stile “Champions League appena vinta”. In realtà, eravamo talmente stanchi dopo le lunghe ore dal notaio, e talmente perplessi circa i documenti complessi che avevamo dovuto studiare ed apprendere in tempi brevi, che la sensazione fu sì di grande soddisfazione, ma comunque non “esplosiva”. A livello neurologico, questo meccanismo è ben documentato: quando completiamo un task con successo, il nostro cervello rilascia dopamina, il neurotrasmettitore responsabile di quella sensazione di realizzazione e piacere. Non a caso, i game designer più bravi usano con caparbietà questa dinamica cerebrale nella creazione dei loro videogiochi, per tenerci agganciati e spingerci a continuare a giocare. From e11fc8466a0de6c6c552088cc4216604484b7b44 Mon Sep 17 00:00:00 2001 From: Enrico Maria Cestari Date: Sat, 4 Jan 2025 11:27:29 +0100 Subject: [PATCH 05/17] Apply suggestions from code review Co-authored-by: Michael Di Prisco Co-authored-by: Angelo Cassano --- docs/it/leadership.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/it/leadership.md b/docs/it/leadership.md index 90d7adf9..20b1f428 100644 --- a/docs/it/leadership.md +++ b/docs/it/leadership.md @@ -21,11 +21,11 @@ Primo avvertimento quindi: il feedback non è immediato, né quando è positivo Prendete una decisione oggi, e non sapete di preciso quando e che risultati otterrete. -### DIVERSI TIPI DI LEADER TECH +## Diversi tipi di leader tech -Altro punto da chiarire: cos’è, ma soprattutto cosa fa un “leader” in ambito tecnologico? Se proviamo a supportarci con le etichette e i job title, stiamo pur certi di rimanere confusi. CTO, Engineering Manager, VP of Engineering, Head of, Tech Leader, Staff Engineer, Principal Engineer - aggiungete a piacere ed attribuite a ciascuno un significato piuttosto arbitrario. +Altro punto da chiarire: cos’è, ma soprattutto cosa fa un “leader” in ambito tecnologico? Se proviamo a ragionare con le etichette e i job title, è matematicamente certo che ne usciremo più confusi di prima. CTO, Engineering Manager, VP of Engineering, Head of, Tech Leader, Staff Engineer, Principal Engineer - aggiungete a piacere ed attribuite a ciascuno un significato piuttosto arbitrario. -Fatto questo, traslate la vostra mappatura in un’altra azienda, e vi renderete conto di dover ricominciare da capo. +Fatto questo, traslate lo stesso ruolo in un’altra azienda, e vi renderete conto di dover ricominciare da capo. Due criteri che chi scrive ritiene più utile adottare per definire meglio la tipologia di “tech leadership” sono: From 922ea8624e4dcb988875d7ea1b59721744bc8142 Mon Sep 17 00:00:00 2001 From: Enrico Maria Cestari Date: Sat, 4 Jan 2025 11:28:00 +0100 Subject: [PATCH 06/17] Apply suggestions from code review Co-authored-by: Michael Di Prisco --- docs/it/leadership.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/leadership.md b/docs/it/leadership.md index 20b1f428..cdf91e4d 100644 --- a/docs/it/leadership.md +++ b/docs/it/leadership.md @@ -37,7 +37,7 @@ Due criteri che chi scrive ritiene più utile adottare per definire meglio la ti Partendo dai due concetti espressi si può arrivare ad un’altra distinzione chiave tra un ruolo tecnico ed uno manageriale: -- Un/a developer in un contesto sano dovrebbe mantenersi in uno stato di flow più lungo possibile concentrandosi unicamente sul codice per lunghi periodi di tempo, e magari su una stessa regione del dominio applicativo (si, lo so, nella pratica accade di rado - ma stiamo ragionando di un _contesto sano_, no?) +- Un/a developer in un contesto sano dovrebbe mantenersi in uno stato di flow più lungo possibile concentrandosi unicamente sul codice per lunghi periodi di tempo, e magari su una stessa regione del dominio applicativo (sì, lo so, nella pratica accade di rado - ma stiamo ragionando di un _contesto sano_, no?) - Una persona con un ruolo manageriale non può adottare lo stesso approccio, ma deve accettare sia un context switching frequente tra compiti anche molto diversi che anche una visione più ampia a livello di domini ed ambiti di azione From 021f67dd691fcc30040978858d4b597096c61367 Mon Sep 17 00:00:00 2001 From: Enrico Maria Cestari Date: Sat, 4 Jan 2025 11:28:23 +0100 Subject: [PATCH 07/17] Apply suggestions from code review Co-authored-by: Michael Di Prisco --- docs/it/leadership.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/leadership.md b/docs/it/leadership.md index cdf91e4d..daf6c041 100644 --- a/docs/it/leadership.md +++ b/docs/it/leadership.md @@ -39,7 +39,7 @@ Partendo dai due concetti espressi si può arrivare ad un’altra distinzione ch - Un/a developer in un contesto sano dovrebbe mantenersi in uno stato di flow più lungo possibile concentrandosi unicamente sul codice per lunghi periodi di tempo, e magari su una stessa regione del dominio applicativo (sì, lo so, nella pratica accade di rado - ma stiamo ragionando di un _contesto sano_, no?) -- Una persona con un ruolo manageriale non può adottare lo stesso approccio, ma deve accettare sia un context switching frequente tra compiti anche molto diversi che anche una visione più ampia a livello di domini ed ambiti di azione +- Una persona con un ruolo manageriale non può adottare lo stesso approccio, ma deve accettare sia un context switching frequente tra compiti anche molto diversi che una visione più ampia a livello di domini ed ambiti di azione Qui urge un disclaimer: “visione più ampia”, non equivale a “meglio”, e non equivale a “persona di livello più importante”. Ritengo che per garantire un approccio costruttivo nel mondo tecnologico sia necessario uscire da questi stereotipi o bias inconsci. Ne parlerò meglio nella sottosezione relativa al Dual Ladder. From 747595a99203288ad9159dfd880ca8d3a5339bc9 Mon Sep 17 00:00:00 2001 From: Enrico Maria Cestari Date: Sat, 4 Jan 2025 11:28:53 +0100 Subject: [PATCH 08/17] Apply suggestions from code review --- docs/it/leadership.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/leadership.md b/docs/it/leadership.md index daf6c041..8252076e 100644 --- a/docs/it/leadership.md +++ b/docs/it/leadership.md @@ -39,7 +39,7 @@ Partendo dai due concetti espressi si può arrivare ad un’altra distinzione ch - Un/a developer in un contesto sano dovrebbe mantenersi in uno stato di flow più lungo possibile concentrandosi unicamente sul codice per lunghi periodi di tempo, e magari su una stessa regione del dominio applicativo (sì, lo so, nella pratica accade di rado - ma stiamo ragionando di un _contesto sano_, no?) -- Una persona con un ruolo manageriale non può adottare lo stesso approccio, ma deve accettare sia un context switching frequente tra compiti anche molto diversi che una visione più ampia a livello di domini ed ambiti di azione +- Una persona con un ruolo manageriale non può adottare lo stesso approccio, ma dovrebbe accettare sia un context switching frequente tra compiti anche molto diversi che una visione più ampia a livello di domini ed ambiti di azione Qui urge un disclaimer: “visione più ampia”, non equivale a “meglio”, e non equivale a “persona di livello più importante”. Ritengo che per garantire un approccio costruttivo nel mondo tecnologico sia necessario uscire da questi stereotipi o bias inconsci. Ne parlerò meglio nella sottosezione relativa al Dual Ladder. From 8fae9e6a123f130b992a58cd13cf024526f3aa2f Mon Sep 17 00:00:00 2001 From: Enrico Maria Cestari Date: Sat, 4 Jan 2025 11:29:31 +0100 Subject: [PATCH 09/17] Apply suggestions from code review Co-authored-by: Michael Di Prisco --- docs/it/leadership.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/leadership.md b/docs/it/leadership.md index 8252076e..6738ace0 100644 --- a/docs/it/leadership.md +++ b/docs/it/leadership.md @@ -45,7 +45,7 @@ Qui urge un disclaimer: “visione più ampia”, non equivale a “meglio”, e Visione più ampia significa livello di zoom diverso, guardare le cose dall’alto. Questo non è necessariamente più semplice, e non è necessariamente più difficile. -Immaginiamo di essere su un elicottero. Un buon leader deve sapersi muovere su più “aree geografiche” assicurandosi che ciascuna di esse si mostri armoniosa ed in buone condizioni. In alcuni casi è necessario scendere di quota e osservare più da vicino - e raramente l’elicottero dovrebbe atterrare. Quando se ne presenta bisogno, l’intento non è solo quello di “risolvere un problema”, ma soprattutto gettare le basi affinché tale intervento non sia più necessario in futuro. +Immaginiamo di essere su un elicottero. Un buon leader dovrebbe sapersi muovere su più “aree geografiche” assicurandosi che ciascuna di esse si mostri armoniosa ed in buone condizioni. In alcuni casi è necessario scendere di quota e osservare più da vicino - e raramente l’elicottero dovrebbe atterrare. Quando se ne presenta il bisogno, l’intento non deve essere solo quello di “risolvere un problema”, ma soprattutto gettare le basi affinché tale intervento non sia più necessario in futuro. Vediamo come classificare dei possibili “ruoli” di leadership in relazione ai diversi livelli di astrazione e trasversalità - ma ricordiamoci che non sono regole o dogmi, anche se un pò di standardizzazione potrebbe aiutare in fase di recruiting e comprensione tra aziende diverse: From 40a93b1bca9ff76c0fd3bef30f4617531c883d37 Mon Sep 17 00:00:00 2001 From: Enrico Maria Cestari Date: Sat, 4 Jan 2025 11:30:08 +0100 Subject: [PATCH 10/17] Apply suggestions from code review Co-authored-by: Michael Di Prisco --- docs/it/leadership.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/it/leadership.md b/docs/it/leadership.md index 6738ace0..1f7c71af 100644 --- a/docs/it/leadership.md +++ b/docs/it/leadership.md @@ -49,7 +49,7 @@ Immaginiamo di essere su un elicottero. Un buon leader dovrebbe sapersi muovere Vediamo come classificare dei possibili “ruoli” di leadership in relazione ai diversi livelli di astrazione e trasversalità - ma ricordiamoci che non sono regole o dogmi, anche se un pò di standardizzazione potrebbe aiutare in fase di recruiting e comprensione tra aziende diverse: -- **Tech Leader** +### Tech Leader - È uno/a sviluppatore di elevata seniority e capacità tecnica - la sua astrazione dal codice e dall’operatività non è totale, il suo ambito e trasversalità riguardano l’intero dominio applicativo del team in cui lavora. @@ -57,7 +57,7 @@ Vediamo come classificare dei possibili “ruoli” di leadership in relazione a - Non ha persone formalmente a riporto, ma deve indubbiamente guadagnarsi il rispetto e la fiducia dei suoi compagni di squadra grazie alla sua autorevolezza. Rispetto ad un Senior Developer, in ogni caso, il suo ruolo gli conferisce anche l’autorità per prendere delle decisioni (limitatamente all’ambito tecnico) nel momento in cui il team non dovesse riuscire a farlo in autonomia. -- **Engineering Manager** +### Engineering Manager - È una figura manageriale - anche se in alcuni contesti gli Engineering Manager scrivono ancora codice, chi scrive ritiene che non dovrebbe essere il caso in un team del tutto funzionale; il focus di questi ruoli deve essere sulle Soft Skills @@ -67,9 +67,9 @@ Vediamo come classificare dei possibili “ruoli” di leadership in relazione a - Da organigramma, le persone dei team che gestisce sono formalmente a suo riporto -- **VP (o Head of) of Engineering** +### VP (o Head) of Engineering - - Il livello di astrazione aumenta; un tipo di figura di questo tipo non ha senso che sia coinvolta nella scrittura o nella revisione diretta di codice + - Il livello di astrazione aumenta; un tipo di figura di questo tipo non dovrebbe essere coinvolta nella scrittura o nella revisione diretta di codice - La trasversalità è ampia: tendenzialmente questa figura deve avere una vista sull’intero dominio ingegneristico aziendale From e776364d9d128952f5bc3feec1431bcb33073a6c Mon Sep 17 00:00:00 2001 From: Enrico Maria Cestari Date: Sat, 4 Jan 2025 11:30:35 +0100 Subject: [PATCH 11/17] Apply suggestions from code review Co-authored-by: Angelo Cassano --- docs/it/leadership.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/it/leadership.md b/docs/it/leadership.md index 1f7c71af..bf3e343f 100644 --- a/docs/it/leadership.md +++ b/docs/it/leadership.md @@ -53,9 +53,11 @@ Vediamo come classificare dei possibili “ruoli” di leadership in relazione a - È uno/a sviluppatore di elevata seniority e capacità tecnica - la sua astrazione dal codice e dall’operatività non è totale, il suo ambito e trasversalità riguardano l’intero dominio applicativo del team in cui lavora. - - Il suo ruolo è quello di garantire la qualità del codice e delle scelte tecnologiche del suo team, sia scrivendo codice che soprattutto assicurandosi che le altre persone del team lo facciano nel migliore dei modi. + - Il suo ruolo è quello di garantire la qualità del codice e delle scelte tecnologiche del suo team, in particolare nel processo di scrittura, durante il quale si scelgono gli algoritmi e le strutture dati pertinenti. Inoltre, deve assicurarsi che le altre persone del team facciano tutto questo nel migliore dei modi. - Non ha persone formalmente a riporto, ma deve indubbiamente guadagnarsi il rispetto e la fiducia dei suoi compagni di squadra grazie alla sua autorevolezza. Rispetto ad un Senior Developer, in ogni caso, il suo ruolo gli conferisce anche l’autorità per prendere delle decisioni (limitatamente all’ambito tecnico) nel momento in cui il team non dovesse riuscire a farlo in autonomia. + + - E' una figura di riferimento: nel caso in cui gli altri membri del team dovessero avere bisogno di supporto, dovrebbe essere la prima figura nel gruppo a fornire degli spunti affinché si possa risolvere un problema nel modo migliore e nel breve tempo possibile. ### Engineering Manager From ace474c0e9080aa66b9f3a3110791974a9672c0b Mon Sep 17 00:00:00 2001 From: Enrico Maria Cestari Date: Sat, 4 Jan 2025 11:31:05 +0100 Subject: [PATCH 12/17] Apply suggestions from code review Co-authored-by: Michael Di Prisco --- docs/it/leadership.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/leadership.md b/docs/it/leadership.md index bf3e343f..a989371a 100644 --- a/docs/it/leadership.md +++ b/docs/it/leadership.md @@ -61,7 +61,7 @@ Vediamo come classificare dei possibili “ruoli” di leadership in relazione a ### Engineering Manager - - È una figura manageriale - anche se in alcuni contesti gli Engineering Manager scrivono ancora codice, chi scrive ritiene che non dovrebbe essere il caso in un team del tutto funzionale; il focus di questi ruoli deve essere sulle Soft Skills + - È una figura manageriale - anche se in alcuni contesti gli Engineering Manager scrivono ancora codice, chi scrive ritiene che non dovrebbe essere il caso in un team del tutto funzionale; il focus di questi ruoli dovrebbe essere sulle Soft Skill - La trasversalità è più ampia di quella di un Tech Lead o di un developer, in quanto la conoscenza deve estendersi sugli ambiti di dominio di tutti i team gestiti From 020f42a53e414abef7e87b34a7c9425475260e75 Mon Sep 17 00:00:00 2001 From: Enrico Maria Cestari Date: Sat, 4 Jan 2025 11:31:33 +0100 Subject: [PATCH 13/17] Apply suggestions from code review Co-authored-by: Michael Di Prisco --- docs/it/leadership.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/leadership.md b/docs/it/leadership.md index a989371a..56e7ff6a 100644 --- a/docs/it/leadership.md +++ b/docs/it/leadership.md @@ -65,7 +65,7 @@ Vediamo come classificare dei possibili “ruoli” di leadership in relazione a - La trasversalità è più ampia di quella di un Tech Lead o di un developer, in quanto la conoscenza deve estendersi sugli ambiti di dominio di tutti i team gestiti - - Il suo ruolo è quello di People Manager degli sviluppatori di uno o più team - è inevitabile che debba conoscere le tematiche tecnologiche, soprattutto in ottica di comprensione delle complessità che i tecnici affrontano nel day by day, ma la sua missione principale è assicurarsi che le dinamiche nei suoi team funzionino bene. Imperativi in questo senso sono i 1:1 con tutte le persone del Team nonché un forte allineamento con i Tech Lead e (nel caso ci siano), i Product manager + - Il suo ruolo è quello di People Manager degli sviluppatori di uno o più team - è inevitabile che debba conoscere le tematiche tecnologiche, soprattutto in ottica di comprensione delle complessità che i tecnici affrontano nel day-by-day, ma la sua missione principale è assicurarsi che le dinamiche nei suoi team siano positive. Imperativi in questo senso sono i 1:1 (momenti di incontro e confronto individuali tra il manager ed ogni singola persona del Team) nonché un forte allineamento con Tech Lead e - qualora ci siano - Product manager - Da organigramma, le persone dei team che gestisce sono formalmente a suo riporto From cfde4ae939168750f64040910ab0bfa0bdefaf8a Mon Sep 17 00:00:00 2001 From: Enrico Maria Cestari Date: Sat, 4 Jan 2025 11:31:51 +0100 Subject: [PATCH 14/17] Update docs/it/leadership.md Co-authored-by: Angelo Cassano --- docs/it/leadership.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/it/leadership.md b/docs/it/leadership.md index 56e7ff6a..a2a79c13 100644 --- a/docs/it/leadership.md +++ b/docs/it/leadership.md @@ -77,6 +77,8 @@ Vediamo come classificare dei possibili “ruoli” di leadership in relazione a - Questo tipo di figura ha senso quando l’organizzazione diventa complessa, e ci sono diversi Engineering Manager con tanti team di sviluppo, ciascuno dei quali ha un prodotto (o una fetta di prodotto) da gestire e portare avanti + - Nelle aziende più grosse e volutamente più strutturate, l'Head of Engineering assume un ruolo intermedio fra gli engineering manager e il o i VP of Engineering. Non vi sono particolari differenze fra i due ruoli se non l'introduzione di un ulteriore livello di astrazione, che potrebbe avere senso se si vuole logicamente differenziare più business unit aziendali teoricamente indipendenti fra loro. + Ho volutamente tenuto fuori il CTO (o CIO o chiamatelo come preferite), perché dal mio punto di vista questa figura è ancora diversa e non legata esclusivamente alla parte di Engineering. Questo è un altro bias molto frequente. In questo caso il livello di astrazione è ancora più alto e la trasversalità si estende ai processi dell’intera azienda, sia per quanto riguarda la cosiddetta “digitalizzazione” dell’organizzazione che anche per tutte le qustioni finanziarie ed amministrative, nonché gli allineamenti con gli executive ed il board o, in caso di aziende che richiedono finanziamenti, coinvolgimento in fase di fundraising. From 7d6e931d09bf3e3f0b73edf4e19ed5676e00837f Mon Sep 17 00:00:00 2001 From: Enrico Maria Cestari Date: Sat, 4 Jan 2025 11:32:28 +0100 Subject: [PATCH 15/17] Apply suggestions from code review Co-authored-by: Angelo Cassano --- docs/it/leadership.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/it/leadership.md b/docs/it/leadership.md index a2a79c13..861fb693 100644 --- a/docs/it/leadership.md +++ b/docs/it/leadership.md @@ -79,6 +79,8 @@ Vediamo come classificare dei possibili “ruoli” di leadership in relazione a - Nelle aziende più grosse e volutamente più strutturate, l'Head of Engineering assume un ruolo intermedio fra gli engineering manager e il o i VP of Engineering. Non vi sono particolari differenze fra i due ruoli se non l'introduzione di un ulteriore livello di astrazione, che potrebbe avere senso se si vuole logicamente differenziare più business unit aziendali teoricamente indipendenti fra loro. + - Nelle aziende più grosse e volutamente più strutturate, l'Head of Engineering assume un ruolo intermedio fra gli engineering manager e il o i VP of Engineering. Non vi sono particolari differenze fra i due ruoli se non l'introduzione di un ulteriore livello di astrazione, che potrebbe avere senso se si vuole logicamente differenziare più business unit aziendali teoricamente indipendenti fra loro. + Ho volutamente tenuto fuori il CTO (o CIO o chiamatelo come preferite), perché dal mio punto di vista questa figura è ancora diversa e non legata esclusivamente alla parte di Engineering. Questo è un altro bias molto frequente. In questo caso il livello di astrazione è ancora più alto e la trasversalità si estende ai processi dell’intera azienda, sia per quanto riguarda la cosiddetta “digitalizzazione” dell’organizzazione che anche per tutte le qustioni finanziarie ed amministrative, nonché gli allineamenti con gli executive ed il board o, in caso di aziende che richiedono finanziamenti, coinvolgimento in fase di fundraising. From 264aecd1b0200ad8d9f473a51c7f71a91c67780e Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 11 Jan 2025 10:23:20 +0100 Subject: [PATCH 16/17] chore: format --- docs/it/leadership.md | 38 ++++++++++++++++++-------------------- 1 file changed, 18 insertions(+), 20 deletions(-) diff --git a/docs/it/leadership.md b/docs/it/leadership.md index 861fb693..ac7d175b 100644 --- a/docs/it/leadership.md +++ b/docs/it/leadership.md @@ -20,14 +20,13 @@ Primo avvertimento quindi: il feedback non è immediato, né quando è positivo Prendete una decisione oggi, e non sapete di preciso quando e che risultati otterrete. - ## Diversi tipi di leader tech Altro punto da chiarire: cos’è, ma soprattutto cosa fa un “leader” in ambito tecnologico? Se proviamo a ragionare con le etichette e i job title, è matematicamente certo che ne usciremo più confusi di prima. CTO, Engineering Manager, VP of Engineering, Head of, Tech Leader, Staff Engineer, Principal Engineer - aggiungete a piacere ed attribuite a ciascuno un significato piuttosto arbitrario. Fatto questo, traslate lo stesso ruolo in un’altra azienda, e vi renderete conto di dover ricominciare da capo. -Due criteri che chi scrive ritiene più utile adottare per definire meglio la tipologia di “tech leadership” sono: +Due criteri che chi scrive ritiene più utile adottare per definire meglio la tipologia di “tech leadership” sono: 1. Il livello di astrazione rispetto alla materia prima, cioè ai dettagli implementativi ed operativi necessari per rendere concrete le idee da realizzare @@ -43,7 +42,7 @@ Partendo dai due concetti espressi si può arrivare ad un’altra distinzione ch Qui urge un disclaimer: “visione più ampia”, non equivale a “meglio”, e non equivale a “persona di livello più importante”. Ritengo che per garantire un approccio costruttivo nel mondo tecnologico sia necessario uscire da questi stereotipi o bias inconsci. Ne parlerò meglio nella sottosezione relativa al Dual Ladder. -Visione più ampia significa livello di zoom diverso, guardare le cose dall’alto. Questo non è necessariamente più semplice, e non è necessariamente più difficile. +Visione più ampia significa livello di zoom diverso, guardare le cose dall’alto. Questo non è necessariamente più semplice, e non è necessariamente più difficile. Immaginiamo di essere su un elicottero. Un buon leader dovrebbe sapersi muovere su più “aree geografiche” assicurandosi che ciascuna di esse si mostri armoniosa ed in buone condizioni. In alcuni casi è necessario scendere di quota e osservare più da vicino - e raramente l’elicottero dovrebbe atterrare. Quando se ne presenta il bisogno, l’intento non deve essere solo quello di “risolvere un problema”, ma soprattutto gettare le basi affinché tale intervento non sia più necessario in futuro. @@ -51,39 +50,38 @@ Vediamo come classificare dei possibili “ruoli” di leadership in relazione a ### Tech Leader - - È uno/a sviluppatore di elevata seniority e capacità tecnica - la sua astrazione dal codice e dall’operatività non è totale, il suo ambito e trasversalità riguardano l’intero dominio applicativo del team in cui lavora. +- È uno/a sviluppatore di elevata seniority e capacità tecnica - la sua astrazione dal codice e dall’operatività non è totale, il suo ambito e trasversalità riguardano l’intero dominio applicativo del team in cui lavora. + +- Il suo ruolo è quello di garantire la qualità del codice e delle scelte tecnologiche del suo team, in particolare nel processo di scrittura, durante il quale si scelgono gli algoritmi e le strutture dati pertinenti. Inoltre, deve assicurarsi che le altre persone del team facciano tutto questo nel migliore dei modi. - - Il suo ruolo è quello di garantire la qualità del codice e delle scelte tecnologiche del suo team, in particolare nel processo di scrittura, durante il quale si scelgono gli algoritmi e le strutture dati pertinenti. Inoltre, deve assicurarsi che le altre persone del team facciano tutto questo nel migliore dei modi. +- Non ha persone formalmente a riporto, ma deve indubbiamente guadagnarsi il rispetto e la fiducia dei suoi compagni di squadra grazie alla sua autorevolezza. Rispetto ad un Senior Developer, in ogni caso, il suo ruolo gli conferisce anche l’autorità per prendere delle decisioni (limitatamente all’ambito tecnico) nel momento in cui il team non dovesse riuscire a farlo in autonomia. - - Non ha persone formalmente a riporto, ma deve indubbiamente guadagnarsi il rispetto e la fiducia dei suoi compagni di squadra grazie alla sua autorevolezza. Rispetto ad un Senior Developer, in ogni caso, il suo ruolo gli conferisce anche l’autorità per prendere delle decisioni (limitatamente all’ambito tecnico) nel momento in cui il team non dovesse riuscire a farlo in autonomia. - - - E' una figura di riferimento: nel caso in cui gli altri membri del team dovessero avere bisogno di supporto, dovrebbe essere la prima figura nel gruppo a fornire degli spunti affinché si possa risolvere un problema nel modo migliore e nel breve tempo possibile. +- E' una figura di riferimento: nel caso in cui gli altri membri del team dovessero avere bisogno di supporto, dovrebbe essere la prima figura nel gruppo a fornire degli spunti affinché si possa risolvere un problema nel modo migliore e nel breve tempo possibile. ### Engineering Manager - - È una figura manageriale - anche se in alcuni contesti gli Engineering Manager scrivono ancora codice, chi scrive ritiene che non dovrebbe essere il caso in un team del tutto funzionale; il focus di questi ruoli dovrebbe essere sulle Soft Skill +- È una figura manageriale - anche se in alcuni contesti gli Engineering Manager scrivono ancora codice, chi scrive ritiene che non dovrebbe essere il caso in un team del tutto funzionale; il focus di questi ruoli dovrebbe essere sulle Soft Skill - - La trasversalità è più ampia di quella di un Tech Lead o di un developer, in quanto la conoscenza deve estendersi sugli ambiti di dominio di tutti i team gestiti +- La trasversalità è più ampia di quella di un Tech Lead o di un developer, in quanto la conoscenza deve estendersi sugli ambiti di dominio di tutti i team gestiti - - Il suo ruolo è quello di People Manager degli sviluppatori di uno o più team - è inevitabile che debba conoscere le tematiche tecnologiche, soprattutto in ottica di comprensione delle complessità che i tecnici affrontano nel day-by-day, ma la sua missione principale è assicurarsi che le dinamiche nei suoi team siano positive. Imperativi in questo senso sono i 1:1 (momenti di incontro e confronto individuali tra il manager ed ogni singola persona del Team) nonché un forte allineamento con Tech Lead e - qualora ci siano - Product manager +- Il suo ruolo è quello di People Manager degli sviluppatori di uno o più team - è inevitabile che debba conoscere le tematiche tecnologiche, soprattutto in ottica di comprensione delle complessità che i tecnici affrontano nel day-by-day, ma la sua missione principale è assicurarsi che le dinamiche nei suoi team siano positive. Imperativi in questo senso sono i 1:1 (momenti di incontro e confronto individuali tra il manager ed ogni singola persona del Team) nonché un forte allineamento con Tech Lead e - qualora ci siano - Product manager - - Da organigramma, le persone dei team che gestisce sono formalmente a suo riporto +- Da organigramma, le persone dei team che gestisce sono formalmente a suo riporto ### VP (o Head) of Engineering - - Il livello di astrazione aumenta; un tipo di figura di questo tipo non dovrebbe essere coinvolta nella scrittura o nella revisione diretta di codice +- Il livello di astrazione aumenta; un tipo di figura di questo tipo non dovrebbe essere coinvolta nella scrittura o nella revisione diretta di codice - - La trasversalità è ampia: tendenzialmente questa figura deve avere una vista sull’intero dominio ingegneristico aziendale +- La trasversalità è ampia: tendenzialmente questa figura deve avere una vista sull’intero dominio ingegneristico aziendale - - Questo tipo di figura ha senso quando l’organizzazione diventa complessa, e ci sono diversi Engineering Manager con tanti team di sviluppo, ciascuno dei quali ha un prodotto (o una fetta di prodotto) da gestire e portare avanti +- Questo tipo di figura ha senso quando l’organizzazione diventa complessa, e ci sono diversi Engineering Manager con tanti team di sviluppo, ciascuno dei quali ha un prodotto (o una fetta di prodotto) da gestire e portare avanti - - Nelle aziende più grosse e volutamente più strutturate, l'Head of Engineering assume un ruolo intermedio fra gli engineering manager e il o i VP of Engineering. Non vi sono particolari differenze fra i due ruoli se non l'introduzione di un ulteriore livello di astrazione, che potrebbe avere senso se si vuole logicamente differenziare più business unit aziendali teoricamente indipendenti fra loro. +- Nelle aziende più grosse e volutamente più strutturate, l'Head of Engineering assume un ruolo intermedio fra gli engineering manager e il o i VP of Engineering. Non vi sono particolari differenze fra i due ruoli se non l'introduzione di un ulteriore livello di astrazione, che potrebbe avere senso se si vuole logicamente differenziare più business unit aziendali teoricamente indipendenti fra loro. - - Nelle aziende più grosse e volutamente più strutturate, l'Head of Engineering assume un ruolo intermedio fra gli engineering manager e il o i VP of Engineering. Non vi sono particolari differenze fra i due ruoli se non l'introduzione di un ulteriore livello di astrazione, che potrebbe avere senso se si vuole logicamente differenziare più business unit aziendali teoricamente indipendenti fra loro. +- Nelle aziende più grosse e volutamente più strutturate, l'Head of Engineering assume un ruolo intermedio fra gli engineering manager e il o i VP of Engineering. Non vi sono particolari differenze fra i due ruoli se non l'introduzione di un ulteriore livello di astrazione, che potrebbe avere senso se si vuole logicamente differenziare più business unit aziendali teoricamente indipendenti fra loro. Ho volutamente tenuto fuori il CTO (o CIO o chiamatelo come preferite), perché dal mio punto di vista questa figura è ancora diversa e non legata esclusivamente alla parte di Engineering. Questo è un altro bias molto frequente. In questo caso il livello di astrazione è ancora più alto e la trasversalità si estende ai processi dell’intera azienda, sia per quanto riguarda la cosiddetta “digitalizzazione” dell’organizzazione che anche per tutte le qustioni finanziarie ed amministrative, nonché gli allineamenti con gli executive ed il board o, in caso di aziende che richiedono finanziamenti, coinvolgimento in fase di fundraising. - ## Dual Ladder Nel paragrafo precedente ho esplicitato come il tema della “visione più ampia” che generalmente un manager ha o dovrebbe avere non debba essere visto come una sorta di “aumento di livello di competenza”. @@ -101,7 +99,7 @@ Tradizionalmente, in molte aziende si sono visti schemi di crescita lineari o pi Questo approccio può funzionare in alcuni casi, soprattutto quando il lavoro operativo è sufficientemente semplice e ripetibile da essere “insegnato” da un singolo esperto ad un team più junior, che a quel punto può essere coordinato. Ma nell’ambito tecnologico, a causa dei tre principi visti prima, questo approccio non scala. -Il Command and Control (dire alle persone che sviluppano come fare le cose) porta nella maggior parte dei casi a disfunzionalità, calo di motivazione, deresponsabilizzazione e anche a far perdere valore all'azienda, in quanto le competenze pregiate degli individui non vengono utilizzate nel processo decisionale. +Il Command and Control (dire alle persone che sviluppano come fare le cose) porta nella maggior parte dei casi a disfunzionalità, calo di motivazione, deresponsabilizzazione e anche a far perdere valore all'azienda, in quanto le competenze pregiate degli individui non vengono utilizzate nel processo decisionale. Peggio ancora, si dovesse ricadere nel meccanismo del micromanagement. Un manager con l'ossessione del controllo a tutti i costi ha il potere di rovinare un team in poco tempo. @@ -111,4 +109,4 @@ Alcuni tecnici _non_ vogliono diventare manager, e fanno bene a perseguire il lo Da un punto di vista aziendale, se si crede in questi presupposti, è importante creare un sistema incentivante anche per chi non vuole crescere in un percorso manageriale. Le figure tecniche devono sentire riconosciuto e premiato il loro continuo perfezionamento, a prescindere dal fatto che rimangano _individual contributor_. Quando parlo di sistema incentivante intendo ovviamente un percorso di carriera, che possa portare alle stesse soddisfazioni (anche a livello retributivo) di un manager di pari livello; sono sempre le competenze e il valore portato all’azienda che dovrebbero fungere da discriminante, non il _job title_. -Il Dual Ladder è una buona soluzione a questo punto, in quanto prevede dei “livelli” di crescita sia per le figure tecniche che per quelle manageriali; molti partono da una base comune ed operativa e poi si biforcano, il che è comunque sensato perché anche un manager di persone Tech deve conoscere la lingua ed il modo di lavorare di quel tipo di Team - guai a mettere un manager generalista in un ruolo di Engineering Manager. \ No newline at end of file +Il Dual Ladder è una buona soluzione a questo punto, in quanto prevede dei “livelli” di crescita sia per le figure tecniche che per quelle manageriali; molti partono da una base comune ed operativa e poi si biforcano, il che è comunque sensato perché anche un manager di persone Tech deve conoscere la lingua ed il modo di lavorare di quel tipo di Team - guai a mettere un manager generalista in un ruolo di Engineering Manager. From 1670392cbc44b81b9751f60d078b022a00aafa7c Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Mon, 13 Jan 2025 14:36:33 +0100 Subject: [PATCH 17/17] Update docs/it/leadership.md --- docs/it/leadership.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/leadership.md b/docs/it/leadership.md index ac7d175b..656ee9db 100644 --- a/docs/it/leadership.md +++ b/docs/it/leadership.md @@ -36,7 +36,7 @@ Due criteri che chi scrive ritiene più utile adottare per definire meglio la ti Partendo dai due concetti espressi si può arrivare ad un’altra distinzione chiave tra un ruolo tecnico ed uno manageriale: -- Un/a developer in un contesto sano dovrebbe mantenersi in uno stato di flow più lungo possibile concentrandosi unicamente sul codice per lunghi periodi di tempo, e magari su una stessa regione del dominio applicativo (sì, lo so, nella pratica accade di rado - ma stiamo ragionando di un _contesto sano_, no?) +- Un/a developer in un contesto sano dovrebbe mantenersi in uno stato di flow più lungo possibile concentrandosi unicamente sul codice per lunghi periodi di tempo, e magari su una stessa regione del dominio applicativo (sì, lo so, nella pratica accade di rado - ma stiamo considerando un _contesto sano_, no?) - Una persona con un ruolo manageriale non può adottare lo stesso approccio, ma dovrebbe accettare sia un context switching frequente tra compiti anche molto diversi che una visione più ampia a livello di domini ed ambiti di azione