Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Capitolo Leadership #231

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Capitolo Leadership #231

wants to merge 2 commits into from

Conversation

EMCestari
Copy link
Member

Ciao a tutti, ho creato un draft per il capitolo sulla Leadership.

In particolare @elgorditosalsero e @AngeloAvv visto che anche voi volevate lavorarci fatemi sapere se vi torna o se volete proporre cambiamenti/aggiungere qualcosa! :)

@EMCestari EMCestari mentioned this pull request May 17, 2024
@corradopetrelli
Copy link
Member

Ha dato errore perchè non sono stati rispettati i livelli del markdown passando da un H1 direttamente ad un H3.
Per risolvere basta sostituire gli ### con ##

@EMCestari EMCestari marked this pull request as ready for review June 13, 2024 16:18
@Cadienvan Cadienvan changed the title Capitolo Leadership - Draft Capitolo Leadership Jun 13, 2024

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
Copy link
Member

@Cadienvan Cadienvan Jun 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.


### 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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 supportarci con le etichette e i job title, stiamo pur certi che rimarremo 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.


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?)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- 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 (, 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 (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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- 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


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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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 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 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.


- **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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- È 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 deve essere sulle Soft Skill

@Il-Libro-Open-Source/drafting-group correggetemi se sbaglio ma ci siamo detti che gli inglesismi sono implicitamente singolari e plurali senza la s finale.


- 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
Copy link
Member

@Cadienvan Cadienvan Jun 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- 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 momenti di incontro e confronto noti come 1:1 con tutte le persone del Team nonché un forte allineamento con Tech Lead e - qualora ci siano - Product manager

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ho voluto spiegare cosa sia un 1:1 qualora qualcuno non ne fosse a conoscenza, non sono però convintissimo della definizione data..


- Da organigramma, le persone dei team che gestisce sono formalmente a suo riporto

- **VP (o Head of) of Engineering**
Copy link
Member

@Cadienvan Cadienvan Jun 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- **VP (o Head of) of Engineering**
### VP (o Head) of Engineering


- **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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- 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

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### DUAL LADDER
## Dual Ladder


- 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**
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- **Engineering Manager**
### Engineering Manager


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**
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- **Tech Leader**
### Tech Leader

Prendete una decisione oggi, e non sapete di preciso quando e che risultati otterrete.


### DIVERSI TIPI DI LEADER TECH
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### DIVERSI TIPI DI LEADER TECH
## Diversi tipi di leader tech

@@ -0,0 +1,105 @@
# TecnoLeadership

### LA GRATIFICAZIONE RITARDATA
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### LA GRATIFICAZIONE RITARDATA
## LA GRATIFICAZIONE RITARDATA


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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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_.

Copy link
Member

@Cadienvan Cadienvan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mi piace moltissimo, e conoscendoti rispecchia molto la tua filosofia. Ho messo alcuni suggerimenti di forma o di chiarificazione di alcuni termini. Farei solo una cosa:
Introduzione relativa al fatto che parliamo di un capitolo "personale" e che come è giusto che sia deve essere paragonato e confrontato con la propria esperienza e il proprio modo di pensare. Creerebbe il giusto mood per la lettura.

Per il resto top! Come sempre, sentiti libero di accettare ciò che ti torna e di rifiutare ciò che non torna!

Copy link
Member

@BrianAtzori BrianAtzori left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Che dire, questo è veramente un ottimo capito, fantastico, tra l'altro -cosa non scontata- molto scorrevole e ben scritto! Non ho trovato errori o ripetizioni ✅

Copy link
Member

@AngeloAvv AngeloAvv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mi piace! Ho aggiunto qualche integrazione, spunto di riflessione e correzione! Nice work 💪


### 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.


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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non sono convinto della punteggiatura

Suggested change
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.


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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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, 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 vorrebbe passare a quello manageriale.


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”.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Italianizzerei termsheet


### 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non mi faceva impazzire

Suggested change
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.


- **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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- È 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 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Integro:

Suggested change
- 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 funzionino bene, in particolare nell'oliare i rapporti fra i membri del team, eliminando o riducendo se possibile gli attriti e favorendo la coesione e lo scambio di vedute fra le componenti del gruppo. 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


- 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Integro:

Suggested change
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.
- 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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dici che potrebbe aver senso introdurre anche il ruolo dell'Engineering Director?


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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

- 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?”
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Che ne pensi se parlassimo del principale inconveniente: il micromanagement?

@Cadienvan Cadienvan linked an issue Sep 7, 2024 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[🆕]: Leadership
5 participants