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 19 commits into
base: main
Choose a base branch
from
Open

Capitolo Leadership #231

wants to merge 19 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
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
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!

BrianAtzori
BrianAtzori previously approved these changes Jun 26, 2024
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 💪

docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Outdated Show resolved Hide resolved
docs/it/leadership.md Show resolved Hide resolved
@Cadienvan Cadienvan linked an issue Sep 7, 2024 that may be closed by this pull request
@Cadienvan
Copy link
Member

@EMCestari porto in bozza per darti il tempo di ri-lavorare i contenuti quando il tempo lo consentirà!

@Cadienvan Cadienvan marked this pull request as draft November 11, 2024 08:45
docs/it/leadership.md Outdated Show resolved Hide resolved
Co-authored-by: Michael Di Prisco <[email protected]>
Co-authored-by: Angelo Cassano <[email protected]>
@Cadienvan
Copy link
Member

@AngeloAvv @BrianAtzori buondì! Enry dovrebbe aver integrato tutte le modifiche, io lo tolgo dalla review e richiedo review formale a tutti!

@Cadienvan Cadienvan marked this pull request as ready for review January 11, 2025 09:23
@AngeloAvv
Copy link
Member

Lato mio ci sono ancora alcuni thread non risolti, non so se sono sfuggiti durante le operazioni di merging (sono diventate obsolete)

docs/it/leadership.md Outdated Show resolved Hide resolved
@Cadienvan
Copy link
Member

Ciao @AngeloAvv è rimasto solo un punto, il resto l'ho controllato e mi sembra tutto integrato!
Lo porto dentro, dimmi se ora ti torna!

Copy link
Member

@sensorario sensorario left a 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.
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 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.
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
- È 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
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 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
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 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.
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
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?”
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 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.

Copy link
Member

@serenasensini serenasensini left a 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.
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
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?)
Copy link
Member

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

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.
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
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.
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
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.
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 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.
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
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.
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
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!
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
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_.
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/a manager di pari livello; sono sempre le competenze e il valore portato all’azienda che dovrebbero fungere da discriminante, non il _job title_.

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
7 participants