Diventare manager migliori? Si può fare! (parte 2)

Small Talk con Luca Sartoni

Trascrizione dello Small Talk del 26 giugno 2023 con Luca Sartoni - si parla di Effective Management Workshop, un corso ideato da Luca per diventare manager efficaci.

L'intervista, pubblicata in due parti (qui puoi leggere prima parte), è stata leggermente modificata per adattarla al formato scritto.

Avanscoperta: nuova domanda dal pubblico. Alessandra chiede: "quando ci sono microteam, dove i ruoli non sono chiari né troppo ben definiti e la figura dell'imprenditori ricopre più ruoli, si può parlare comunque di effective management?".

Luca: si può, anzi si deve, soprattutto in quelle circostanze in cui le persone hanno delle responsabilità che sono definite ma a volte non formalmente. Nell'azienda in cui ero la definizione di team lead era nell'organigramma, ma la definizione di squad lead esisteva solo nella pratica, non era neanche rispecchiata nell' organigramma.
Quando ti capita di lavorare in gruppi abbastanza piccoli hai appunto questa sovrapposizione di ruoli e a volte c'è l'imprenditore che ricopre più ruoli decisionali e di responsabilità, però la verità è che hai un gruppo di persone che devono collaborare bene.

Le tecniche di effective management aiutano tutti: chi le riesce a padroneggiare contribuisce al successo dell'intero gruppo, ed è per quello che questo workshop tende a essere utile sia al nuovo manager sia a chi vorrebbe diventare manager, sia a chi lo è già.

Ma non è un trucco che abbiamo inventato per essere disponibili a tutti, perché noi siamo molto verticali in questo workshop - ci tengo a chiarirlo.
Questo workshop ha sì alcuni elementi di comunicazione, ma non è un workshop che fa tutto, è estremamente verticale: io ti faccio diventare efficace in quelle attività e in quelle hard skill che sono necessarie in particolare a chi è in una posizione di management per eccellere.
Ora, queste hard skill sono ancora soft skill per chi è individual contributor, e per chi è in una posizione di management più alta queste sono ancora più importanti.

In una circostanza come questa, dove ci sono questi ruoli confusi, diventare ancora più cristallini nella comunicazione aiuta tantissimo. Diventare ancora più chiari nella definizione delle aspettative l'uno con l'altro, tra sottoposti e manager o tra collaboratori e manager, diventa ancora più efficiente ed efficace al fine globale del successo.

Come dico spesso,

è molto meglio avere un disaccordo esplicito piuttosto che una comprensione implicita.

Purtroppo, da un punto di vista culturale, noi veniamo sempre spinti, fin da bambini, a cercare l'implicito, ossia piuttosto che vedervi litigare, fate silenzio. Questo è quello che si dice normalmente i bambini: quando iniziano a essere molto accesi tra di loro, si impone il silenzio.

Invece il mio approccio è esattamente l'opposto: quando io guardo un gruppo e quel gruppo è silenzioso, parto da l'idea che ci sia un problema.
Il problema fondamentale è che le persone non si parlano, ma sono sicuro che ci sono tanti disaccordi, e soprattutto sono sicuro anche che ci sono tante incomprensioni implicite, cioè ci si aspetta dagli altri cose di cui non si è parlato, e all'interno di queste cose di cui non si è parlato a volte ci sono proprio delle incomprensioni che sono fondamentali.

Sarà sicuramente capitato a chiunque ci sta guardando di andare a una persona a dire: "hai fatto quella cosa che ti ho chiesto?", e questa dice: "sì, certo", per poi accorgervi che invece ha fatto tutt'altra cosa rispetto a quello che avevate chiesto. Si tratta di un classico esempio di incomprensione implicita: non avete litigato con quella persona, semplicemente avevate capito due cose diverse.

Nel workshop vedremo una serie di tecniche che servono a mitigare questo tipo di situazioni, a renderle molto meno frequenti e quindi a raggiungere un'efficacia maggiore all'interno di un team.

Avanscoperta: Emanuele ci chiede: "in un team piccolo, di 3-4 persone, il/la project manager può essere anche operativo sul progetto dato che fa parte del team di sviluppo in qualità di dev: c'è qualche aspetto su cui porre attenzione?"

Luca: per rispondere a questa domanda vi racconterò esattamente cosa mi è successo, ossia qual è stato il problema che ho incontrato, come l'ho risolto e la risposta che ne deriva.

A un certo punto dirigevo cinque team, ed erano team ad alta performance: nella scala di performance aziendali, erano considerati tra i top ten in termini di performance e risultati contro aspettative - erano davvero al top.
A un certo punto però uno di questi team inizia ad avere un problema: non rispettano le consegne, sono in ritardo sui progetti... c'è qualcosa che non va. Inoltre era un team nuovo per me, erano entrati nella mia division da poche settimane quando questa cosa è venuta fuori, e quindi io dovevo capire esattamente come andare a risolvere questo problema analizzando le informazioni che avevo.
Sono andato a guardare tutto lo storico di performance review che erano state fatte negli ultimi anni e ho visto una cosa interessante: il team aveva sempre delle performance review eccellenti, cioè tutti venivano sempre valutati al top delle performance. Solo che ogni tanto c'era un puntino rosso, che indicava che quella persona aveva avuto un problema, tipo uno aveva avuto problemi di onboarding, un'altra in un certo periodo era sempre in ritardo, un'altra aveva avuto un problema relativo alla qualità del codice, che non era al passo con gli standard che avevamo... però ogni volta che c'era un puntino rosso, questo poi tornava verde alla performance review successiva, e da lì in poi tutto diventava di nuovo perfetto. Il team lead aveva un recovery rate al 100% di queste circostanze.

Allora ho iniziato a investigare un po' meglio, soprattutto il lavoro del team lead. Ed era successo che questo questo team lead, prima di diventare team lead, fosse un ingegnere del software. Una circostanza piuttosto comune.

Qual è una delle caratteristiche principali degli ingegneri, dei designer e in generale di tutti gli individual contributor, incluso me, all'interno del nostro settore? Che siamo campioni mondiali di spiegazioni.

Quando qualcuno arriva e ci dice: "c'è un problema", noi siamo bravissimi a dedicare un po' di tempo all'analisi del problema e a spiegarlo. Per esempio, se qualcuno mi dicesse: "questa interfaccia non converte abbastanza utenti alla vendita", io spiego che il problema sono i tassi di conversione, il fatto che alcuni browser non supportano questa tecnologia, il fatto che il database non sia sempre affidabile e ogni tanto crasha, il fatto che l'infrastruttura non sia sufficientemente solida", e lo spiego molto bene.

Cosa succede quando questo atteggiamento ce l'ha una persona che diventa manager? Che tende a pensare che sia qualcosa che quando si diventa manager sparisca, o sia tutto sommato tollerabile.
Quindi ogni volta che qualcuno aveva un problema di performance all'interno del suo team, questo manager era perfettamente in grado di trovare un problema e descriverlo nella performance review, solo che poi non faceva il passo successivo: per quella persona era sufficiente spiegare al suo collaboratore che qualcosa non andava bene per concludere il suo ciclo di gestione del problema, e non andava a fare un follow-up successivo per controllare che chi era in ritardo avesse smesso di essere in ritardo, chi scriveva codice con bug facesse poi codice di qualità, ecc.
Per quel manager era sufficiente descrivere bene il problema nella performance review, e volta successiva saltare il problema a piè pari, dato che se n'era già parlato.

La prima cosa a cui fare attenzione quando si è in questo ruolo un po' ibrido in cui sì, sei team lead, ma ci si aspetta che una certa percentuale del tuo tempo sia ancora dedicata all'attività operativa, è: inizia a renderti conto che i problemi che hai con le persone sono una classe di problemi completamente diversi rispetto ai problemi che hai con la tecnologia. E sono problemi che vanno affrontati, non solo con strumenti diversi, ma con un approccio mentale completamente nuovo.

Quando si tratta di sistemi, computer e tecnologia, i problemi si risolvono con una accurata analisi del problema, e spesso questa analisi è sufficiente affinché un'altra persona possa risolvere il problema. Questa cosa però non la puoi fare coi problemi che hai quando gestisci le persone.
Anche se tu fossi estremamente bravo o brava a descrivere perfettamente il problema, e fossi addirittura in grado di arrivare a un livello di analisi psicologica del quadro generale, devi comunque occuparti anche della parte della soluzione.

Molto spesso, è più che sufficiente identificare il problema, non va necessariamente descritto. Se una mia dipendente arriva in ritardo, qualsiasi cosa io, come manager, faccia per farla smettere di arrivare in ritardo - questo sarà più che sufficiente, il problema è risolto. Non è importante analizzare tutte le ragioni che portano quella persona al ritardo: la cosa importante è che quella persona smetta di arrivare in ritardo.

Avanscoperta: in una situazione ibrida, dove sei sia operativo/a sul progetto ma fai anche parte del team di sviluppo, una delle cose più complicate può essere quella del cambio di ruolo, ossia: fino a ieri eravamo colleghi, da domani sono il tuo manager... cosa ci puoi dire al riguardo? Come gestire una situazione del genere?

Luca: le prime edizioni del workshop saranno in italiano, per cui ci rivolgiamo a un mercato in cui c'è una presenza molto forte di imprese familiari.
Immagina: se già è difficile immaginarsi di passare da essere colleghi a direct report, quindi rapporto manager/collaboratore, pensa a tutte quella realtà in cui c'è anche la famiglia di mezzo. Per cui non solo chi fa parte della famiglia, ma anche chi lavora in un'azienda a conduzione familiare come dipendente, per cui, insieme a questa complessità, c'è anche il fatto che alcune persone all'interno dell'azienda hanno rapporti di sangue e non soltanto di contratto.

In realtà la classe di problemi è bene o male sempre la stessa, ossia essere in grado di creare in maniera adeguata dei comparti che separano la componente personale dalla componente professionale all'interno delle relazioni che si hanno.

Non è necessario avere cambi di ruolo perché questa complessità si presenti. Per esempio, nei team di sviluppo, quando due o tre persone sono abituate, vivendo vicine tra loro, o pensiamo a chi lavora in ufficio, ad andare a bere qualcosa dopo lavoro, e alcuni di loro invece non fanno così per vari motivi (familiari o perché non gli va), si creano degli sbilanciamenti di relazioni in ufficio. Quindi hai persone che sono più amiche tra di loro, e persone che sono meno personali nei rapporti tra di loro.
Questo presenta le stesse sfide di quando si cambia ruolo. La differenza è che quando si cambia ruolo questi contrasti avvengono nel tempo: fino a ieri eravamo una cosa, e oggi siamo una cosa diversa.
Quando invece guardi lo spettro del team, come nell'altro esempio del bere dopo le ore di lavoro, alcuni sono una cosa e altri sono un'altra cosa, e quindi questi contrasti avvengono nello spazio.

Per gestire questa complessità, bisogna essere estremamente deliberati. La chiave è essere deliberati, cioè riconoscere che queste cose ci sono: per natura c'è una differenza tra rapporti personali e rapporti professionali.

Questo non significa che dobbiamo implementare quella sorta di luogo comune per cui in Italia si fa l'amicone ma se lavori all'estero sono tutti freddi e gelidi. No, non è questo che intendo. Ciò che voglio dire si può lavorare in un team in cui si è anche amici, e si può lavorare in un team in cui si è freddi e algidi. Ma la componente professionale deve rimanere la componente professionale.

Io per tantissimi anni ho dovuto rendere conto del mio operato direttamente a una persona che a me è molto vicina da un punto di vista personale: il mio capo era il mio testimone di nozze. Eravamo amici prima dell'azienda, siamo rimasti amici dopo l'azienda e siamo rimasti amici anche mentre eravamo nella stessa l'azienda.
Come abbiamo fatto? Abbiamo creato una serie di regole per noi due e tra noi due su come comportarci all'interno del nostro ruolo professionale. Per esempio, quando si lavorava, dato che noi lavoravamo per un'azienda straniera in cui si parlava in inglese, anche se eravamo da soli, sia di persona che per iscritto si parlava in inglese.
Quando invece parlavamo in italiano, perché entrambi italiani, significava che stavamo parlando di affari nostri e personali. Ma nel momento in cui si passava a un argomento di lavoro, subito parlavamo in inglese automaticamente. Questo aiutava la nostra mente a tenere separate alcune componenti.

L'altra cosa era che ogni volta che si faceva performance review, quindi sostanzialmente io la subivo, questa veniva fatta esattamente con gli stessi modelli di valutazione come se fosse stata fatta per chiunque altro, perché lavoravamo in un modello in cui avevamo formalizzato le aspettative nei confronti della mia attività operativa.
Quindi se si formalizzano le aspettative nei confronti dei propri collaboratori, quando si passa da essere amici a diventare il manager di uno di questi, è sufficiente applicare la stessa scala valutativa. È chiaro che probabilmente la conversazione in sé sia più formale con una persona che non è a noi vicina piuttosto che con una persona che invece riteniamo amica, dove quindi sarà un po' meno formale: non si inizia a parlare in modo completamente diverso solo perché si parla di lavoro.
Ma tenendo bene a mente che quando facciamo una performance review, uno dei due è il capo dell'altro, e che quando giochiamo a calcetto siamo amici. Per cui in ciascun contesto ci si aspetta un determinato comportamento.

E la cosa vale in entrambi i sensi: si tende a pensare che è sempre il/la manager colui o colei che imposta la conversazione, imponendo rigore, correttezza e regole, ma non è così, perché in un clima corretto questo avviene sempre in due direzioni.

Ossia: tu, manager, ti aspetti che i tuoi collaboratori lavorino secondo determinati standard, ma i collaboratori d'altra parte si aspettano determinati standard anche dal proprio manager, cioè di essere valutati correttamente, che le aspettative siano negoziate e comunicate in maniera chiara, che le valutazioni siano corrette, che le opportunità siano eque all'interno del team, e non  che siano sempre i soliti a ricevere determinati tipi di opportunità e che sempre i soliti lavorino e basta... questo tipo di aspettativa è un'aspettativa di rigore e di disciplina che il team esercita nei confronti proprio capo.

La cosa interessante è che questa aspettativa c'è a prescindere dal volere dell'azienda e del capo. Per esempio si può pensare, della propria azienda, che "non ci sia meritocrazia": se il mio capo lavora male, non posso fare niente.
Questo non è vero in nessuna azienda. Il fatto che quell'azienda tolleri determinati comportamenti non avviene perché l'azienda non ha meritocrazia, ma deriva dalla cultura aziendale, e tu puoi fare qualcosa.

Il problema è che per tantissimi anni prendere la porta è stato visto come una cosa che non si fa, poi come una cosa che aveva un forte giudizio morale, e poi una cosa da sciagurati perché mollare un posto fisso era da sciagurati.
Ma il mondo è cambiato: il COVID ha completamente eliminato questa circostanza, per cui oggi saltare da un'azienda all'altra è la norma anche in Italia.

Le nuove generazioni, secondo alcuni trend, per esempio, ho visto da poco la presentazione dei Trend of work per il 2023... uno dei trend è il rapporto inter-generazionale: fino a una decina di anni fa, o meglio fino a prima del COVID, una persona giovane che entrava in azienda e vedeva che c'era una persona vicino alla pensione in un angolo che stava facendo gli ultimi anni della propria carriera, completamente emarginata o comunque un po' da una parte, era tentato o tendeva ad avvicinarsi a quella persona cercare di spingerla fuori dall'azienda per prenderne il posto, quindi o si faceva insegnare il lavoro a quella persona, oppure andava a colmarne il posto appena possibile.
Oggi quando una persona giovane entra in azienda e vede che l'azienda tollera persone anziane parcheggiate in attesa della pensione, quella persona prende la porta perché non vuole diventare quella persona tra 30 anni.

Il modo di approcciare il lavoro oggi è completamente diverso:il modello fantozziano non esiste più, e un manager che è un despota rimane solo e viene allontanato, perché le aziende non si possono permettere di avere questo tipo di comportamento e di incapacità all'interno dei ranghi.

Avanscoperta: Sorrido, perché se dici fantozziano, in Italia, apre subito un mondo di riferimenti culturali...

Luca: per quasi tutta la mia parte matura di carriera ho lavorato all'estero, e adesso, da qualche mese, ho ricominciato a lavorare di più in italiano, e mi rendo conto che ci sono un sacco di modelli e metafore che a volte faccio molta fatica a trovare. Poi torno alla mia infanzia, basta nominare uno o due film, e tutti capiscono di cosa sto parlando. Poi siccome sono un grande fan di Fantozzi, saprei anche identificare i vari nomi dei manager coi tipi umani che troviamo nelle aziende. Ma anche qui, ho scoperto che per fortuna le nuove generazioni non sono fan di Fantozzi quanto me, e quello si perde, e stiamo uscendo da quella cosa lì.

E per quanto ne sia fan, penso che Fantozzi sia stato il male dell'Italia, perché per 30 anni le persone non solo si sono identificate in Fantozzi, ma hanno anche cercato di esserlo, quindi tendevano a cercare quel tipo di rapporto di lavoro: se loro capo non era despota, non andava bene. C'erano delle distorsioni enormi.

Avanscoperta: e continuiamo a parlare di capi, re e regine assoluti. Questo è un corso che, se fossi dipendente di un'azienda e andassi a chiedere al mio capo di finanziarmelo, potrebbe essere visto come un: "ah quindi mi stai dicendo che non sono un bravo capo?"... oppure no. Cosa possiamo dirci al riguardo?
Mi spiego meglio: se chiedo in azienda di mandarmi a questo corso, la cosa è molto positiva, perché sto investendo sul mio voler diventare un manager migliore. Hai mai percepito perplessità da questo punto di vista?

Luca: qui ci sono due tipi di problemi da affrontare. Il primo è che andare da un capo e dirgli o dirle: "mi paghi questo corso per diventare un manager migliore?"... potrebbe non essere elegante, ci sono modi più efficaci, e ora li vediamo insieme. Quindi proviamo a pensarlo esattamente come se, in qualità di individual contributor, si trattasse di un corso su una nuova tecnologia (nel caso in cui siamo programmatori o programmatrici) da padroneggiare.

Noi l'abbiamo chiamato Effective Management di proposito, inizialmente l'idea era First-time Managers o qualcosa di simile, e sarebbe stato più difficile da vendere a un proprio capo, che avrebbe potuto dire "ma come, sei manager da sei mesi, com'è che ora vuoi un corso per nuovi manager?", o quindi "ah, allora non sei pronto/a?".
Mentre Effective Manager ha una terminologia precisa, perché include la parola "effective" (che, lo ricordiamo, si traduce come efficace, ndr); quindi si rivolge a una sottocategoria di manager, quelli che puntano alle alte performance. Per cui

è come dire che si vuole fare un corso di aggiornamento su una nuova tecnologia disponibile adesso, qualcosa che, se non l'aveste in azienda, vi metterebbe in difficoltà.

Per fare un esempio che spero sia calzante, quando è uscito React, molto dev han fatto i corsi per imparare React perché era la nuova tecnologia che andava padroneggiata. Il discorso non era "non conosco React, mi serve il corso", quanto piuttosto "ho bisogno di fare un passettino in più: conosco JavaScript, conosco Node, ora mi serve completare la mia formazione".
Consideriamo questo corso come quel passettino in più per diventare davvero efficaci nei propri team.

E il secondo spunto che offro è questo: se vogliamo essere ancora più aggressivi nel convincere l'azienda a finanziarci il corso, si può dire che sono stati investiti molti soldi per assumere nuovo personale, e così come si è investito per l'aggiornamento e formazione di questi nuovi colleghi e colleghe, allora toccherà fare lo stesso con me, che sono stato messo a capo delle nuove persone, perché altrimenti sono tutti sforzi buttati via in quanto non saremo efficaci quanto potremmo essere.

Un altro ragionamento, se le cose vanno già bene e l'azienda è già propensa, è pensare a quanto andranno meglio quando il team avrà anche un alto grado di efficacia a livello di management del team.

Se il capo non capisce questo messaggio, allora bisognerà fare un altro lavoro ancora: andare dal suo capo, e convincere il capo del vostro manager a pagare il corso al vostro capo, perché è chiaro che state lavorando con un capo che non capisce cosa vuol dire essere capo.

Avanscoperta: domanda da Riccardo: "quante persone è in grado di gestire un manager direttamente?"

Luca: la risposta è otto. Sulla mia pelle ti posso dire che la crescita di produttività è lineare fino a otto, dopo otto inizia declinare e sopra 12 declina. Quindi sei hai più di 12 direct report, soprattutto nella nella parte bassa, cioè da individual contributor a manager, se superi il rapporto 12:1 inizi a perdere, cioè ogni persona che si aggiunge diventi più lenta. A meno che tu dopo non crei una sotto organizzazione, però diventa ancora più complicato...

Quindi il mio consiglio è: team mai più grandi di otto persone. Questa cosa si conferma anche negli studi internazionali su "qual è la dimensione efficace di un team", tant'è che se andiamo a prendere Amazon, Bezos fin dall'inizio diceva cose tipo che "la dimensione di un team deve essere quella si riesce a sfamare con una pizza", parlando di pizze americane: solitamente loro non prendono una pizza a testa, ma c'è una pizza grande che si mette in mezzo al tavolo, l'idea è un po' quella.

Una pizza è fatta per dare da mangiare a 6-7 persone, e quella è un po' la dimensione giusta. E questo è ciò che Amazon ha fatto fin falla fine degli anni '90 quando si trattava di stabilire la dimensione massima di un team.
L'ho visto fare in Automaticc ed effettivamente funzionava; posso anche dire per esperienza personale di aver spezzato un team una volta raggiunte le 10 persone, quindi mi sono accorto sulla mia pelle che in più di otto non si riesce a fare quel che serve fare in un team.

Avanscoperta: domanda da Noemi: "in alcune realtà, operatività e management hanno confini sfumati e spesso si ricoprono più ruoli, con forte context switch. In che modo renderli conciliabili?"

Luca: la risposta è: attraverso una deliberata separazione. Se tu sei una engineering manager, con 4-5 persone sotto di te, e la tua azienda si aspetta che una parte del tempo la passi facendo anche codice e code review, e una parte del tempo a gestire persone, mettiti d'accordo su qual è l'esatta aspettativa dicendo: "cosa vi aspettate? 50/50?", e a quel punto lo metti in pratica, dedicando il 40% del tuo tempo alle attività specifiche di management, il 40% del tempo alle attività operative, e ti tieni quel 20% come la parte nebulosa in cui poter saltare di qua e di là, perché fare le cose senza un minimo di margine di movimento non è reale.
Però questo lo definisci a tavolino e in anticipo, perché sennò il rischio è che tu viva questo spettro larghissimo in cui in una situazione fai solo codice, in un'altra solo management, e continui a oscillare nel mezzo a seconda della settimana.
Molto meglio se questi due momenti invece li organizzi così: 40% manager, 40% coder (o marketer, o designer, ecc), e questo si applica magari alla nostra industria.

Quindi abbiamo detto: 40% di operatività, 40% di gestione delle persone, e quel 20% nel mezzo, ed è in quest'ultimo pezzo che posso eventualmente muovermi. Vedrai che troverai grande giovamento da questo essere deliberati in questo tipo di decisioni.

Avanscoperta: ultima domanda e siamo in chiusura: ti è capitato, nei tuoi vari corsi di formazione, tipo il Dojo, di avere una persona e il suo capo?

Luca: può capitare. Se la quantità di iscritti lo permette, consiglio di essere separati, soprattutto le prime volte, perché c'è bisogno, sia nel corso Effective Management che nel mio Dojo, di creare un safe space space in cui si possono affrontare anche casi particolari, e quando c'è un rapporto gerarchico tra due persone all'interno del gruppo, quelle due persone tendono a condividere di meno perché vivono la relazione con un limite al poter condividere cose, quindi idealmente meglio separarsi.
Se ci dovessero essere però, ed entrambe le persone (o più di due) vogliono partecipare al corso, preferirei saperlo prima. Ne parliamo prima e insieme costruiamo un piano per evitare che questo limite si presenti, ossia lo gestiamo.

Se pensate di venire a questo corso, che è fatto di quattro moduli, e se pensate che sia un corso dove ci si mette davanti al computer, braccia incrociate a guardare slide... non iscrivetevi. Questo corso è lavoro, ed è impegnativo: significa avere degli obiettivi, sapere che si vuole migliorare, esserne coscienti ed essere disposti ad ammetterlo, sapere che più del 60% del tempo del corso sono esercizi che faremo insieme.
Questo non significa che dovrete sudare, significa però che dovete pensare molto e quindi farete avrete dei template e delle matrici da riempire, parleremo un sacco di cosa bisogna fare e come bisogna farlo, faremo dei role play, faremo dei giochi in cui chiederemo a una persona di impersonare un manager e a un'altra persona di impersonare un dipendente, dove ci sarà una traccia guida da seguire... impareremo in prima persona a dare e ricevere feedback, anche e soprattutto con questi role play, e poi insieme faremo debriefing, dopo il quale io darò un'analisi tecnica, spiegando dove migliorare.

C'è molta azione in questo corso. Oltre alla durata del corso (al momento 3 ore e mezza alla settimana), aggiungete un'ora durante la settimana per rivedere quello che avete fatto e per fare i compiti che vi darò: non sono esercizi lunghi e noiosi, però se parliamo di feedback, per esempio, uno dei compiti è: se durante questa settimana ti capita di dare feedback a qualcuno, fallo nel modo strutturato che ti ho insegnato, così vedi come funziona nel mondo reale.
Quindi sono 4 ore e mezza di impegno settimanale. Se voi vi impegnate a questo livello, garantisco che uscite da quel mese di training con un livello di autocoscienza e di capacità che in questo momento non potreste neanche immaginare, farete un passo avanti incredibile.

Succederà una cosa inevitabile: finito questo corso ci saranno le persone che bussano alla porta (di Avanscoperta) per fare i successivi, perché una volta che iniziate il percorso di crescita con queste queste metodologie vi verrà una fame di questi argomenti che in parte sazierò dandovi oltre 50 libri da leggere, però avere supporto aiuta molto, quindi dopo ci sarà ancora da crescere.
Lo ripeto un'altra volta: se pensate che sia un corso dove la passività premia, non è per voi.

Avanscoperta: grazie mille per averlo ricordato. Come tutti i corsi Avanscoperta, grande spazio a esercizi di vario tipo, quindi non staremo a scaldare la sedia, come si diceva a scuola. Grazie Luca e grazie a tutti e tutte.

Luca: grazie per le domande. Vi lascio con una call to action: se avete altre domande su questo argomento e siete interessati alle mie risposte, scrivetemi, e io vi rispondo. Scrivetemi su info at lucasartoni punto com, mi trovate sul sito di Avanscoperta e sui social. Vi garantisco una risposta.

Cover photo: Foto di Joshua Earle su Unsplash

Small Talk con Luca Sartoni: il video - il podcast - la prima parte dell'intervista su questo blog.

Learn with Luca Sartoni

Luca è il trainer di Effective Management Workshop.

Vuoi continuare a leggerci? Iscriviti alla nostra Newsletter 📩 (disponibile in italiano e in inglese).
Ti faremo compagnia ogni venerdì mattina. ☕️

La lista completa dei nostri corsi: Avanscoperta Workshops.