-
-
Notifications
You must be signed in to change notification settings - Fork 26
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
base: main
Are you sure you want to change the base?
Capitolo Leadership #231
Conversation
Ha dato errore perchè non sono stati rispettati i livelli del markdown passando da un H1 direttamente ad un H3. |
There was a problem hiding this 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!
There was a problem hiding this 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 ✅
There was a problem hiding this 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 💪
@EMCestari porto in bozza per darti il tempo di ri-lavorare i contenuti quando il tempo lo consentirà! |
Co-authored-by: Michael Di Prisco <[email protected]> Co-authored-by: Angelo Cassano <[email protected]>
Co-authored-by: Michael Di Prisco <[email protected]>
Co-authored-by: Michael Di Prisco <[email protected]>
Co-authored-by: Angelo Cassano <[email protected]>
Co-authored-by: Michael Di Prisco <[email protected]>
Co-authored-by: Michael Di Prisco <[email protected]>
Co-authored-by: Angelo Cassano <[email protected]>
Co-authored-by: Angelo Cassano <[email protected]>
@AngeloAvv @BrianAtzori buondì! Enry dovrebbe aver integrato tutte le modifiche, io lo tolgo dalla review e richiedo review formale a tutti! |
Lato mio ci sono ancora alcuni thread non risolti, non so se sono sfuggiti durante le operazioni di merging (sono diventate obsolete) |
Ciao @AngeloAvv è rimasto solo un punto, il resto l'ho controllato e mi sembra tutto integrato! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ho più che altro lasciato dei commenti secondo il mio modesto punto di vista.
|
||
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. | |
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. |
Mi sembra più sensata una virgola. Ma non sono solito usare trattini quindi il mio vuole essere solo un commento di confronto.
|
||
### 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- È 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. |
|
||
### 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- È 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 | ||
|
||
- 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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 |
|
||
- 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. | |
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 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. |
Prima di questo punto non mi pare si parli di altri bias. Si potrebbe rimuovere "altro" secondo me. Che ne pensi?
|
||
- 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?” |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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?” | |
- 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?” |
Un piccolo dettaglio: con la virgola mi sembra la frase scorra meglio.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ottimo capitolo (non che avessi dubbi). Ho sistemato un po' di generi, ed espresso qualche dubbio su alcune frasi che non mi tornano. Al netto di questo, è una buona partenza per comprendere meglio il ruolo della leadership, anche se sarebbe interessante aggiungere -in futuro- dei riferimenti "pratici" su come lavorare in quella direzione, per chi aspira a farlo. Magari errori comuni... ti ricorda qualcosa @EMCestari ? 🙄
|
||
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Primo avvertimento quindi: il feedback non è immediato, né quando è positivo né quando è negativo. | |
> Primo avvertimento quindi: il feedback non è immediato, né quando è positivo né quando è negativo. |
|
||
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 considerando un _contesto sano_, no?) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sai che questo va contro la linea di pensiero della maggior parte dei grandi nomi del settore? Per dirne una: https://nunoalexandre.com/2016/01/06/the-zone-and-interruptions
Bada bene, il mio è un commento puramente soggettivo, e la flow zone può far più male che bene. Ma poi, come in tutto, dipende...
|
||
- 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Questa frase non mi è chiarissima... Il context switch "aiuta" ad avere una visione più ampia? O è una condizione in cui il/la manager si trova di frequente?
|
||
- 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. | |
Qui urge un disclaimer: “visione più ampia”, non equivale a “visione migliore”, e non equivale a “essere una 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. |
|
||
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 avere un livello di zoom diverso, guardare le cose dall’alto. Questo non è necessariamente più semplice, e non è necessariamente più difficile. |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. | |
Peggio ancora, si dovesse ricadere nel meccanismo del micromanagement. Un/a manager con l'ossessione del controllo a tutti i costi ha il potere di rovinare un team in poco tempo. |
|
||
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. | |
Quello che un/a buon/a manager dovrebbe fare è creare un ambiente in cui le competenze specialistiche possano brillare, generare valore ed evolvere insieme alle Persone che le coltivano. |
|
||
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! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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! | |
Ci sono persone che lavorano come tecnici/che _non_ vogliono diventare manager, e fanno bene a perseguire il loro sogno di carriera: diventare sempre più bravi/e nella loro area di competenza! |
|
||
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_. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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/a manager di pari livello; sono sempre le competenze e il valore portato all’azienda che dovrebbero fungere da discriminante, non il _job title_. |
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! :)