Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Chiedo in anticipo scusa per la qualità del mio microfono come i miei compagni di viaggio che non sono solo possono vedere sto registrando dal letto della camera da letto di casa dei miei suoceri dall'altra parte del Mediterraneo quindi probabilmente mi sentirete un po' di merda ma mi dispiace insomma non abbiamo ancora dei microfoni portatile uno studio portatile abbastanza all'avanguardia per sopperire a questi problemi di qualità ma proveremo a proveremo a compensare con la qualità dei contenuti io non garantisco e soprattutto confido quasi esclusivamente sull'aiuto dei miei compagni di viaggio.Infatti oggi siamo anche abbastanza numerosi abbiamo con noi Mattia, Carmine e Luca.Ciao ragazzi! Ciao! Oggi parliamo di un argomento figo che in realtà non abbiamo mai affrontato qua nel nostro bar eppure assume un'importanza veramente decisiva parliamo di leadership, parliamo di management, parliamo insomma di tutte quelle cose che qualcuno definisce come elemento facente parte del gruppo delle soft skill in realtà secondo me sono quasi più hard delle technical skill prima però di introdurre l'argomento il mio compito è ricordarvi i nostri contatti.Info che ho c'è la github.it è @brainrepo e voi ragazzi volete ricordare qualcos'altro? Ma so che c'è un gruppo, non ricordo bene dove.Televisione? Telefono? Tele...Tele...Tele...Tele...Telegram! Telegram! Telegram! Telegram! Telegram! E' il porting della chat room che c'era su Netlog.Ci potete trovare lì.Sì c'è il non me lo ricordate? Era una roba veramente brutta, non lo so.Netlog, ricordo, in realtà era come...No, io usavo il Nessen.Era...ma in periodo c'era anche Badoo o mi sbaglio? Sì, c'era anche Badoo, c'era Netlog, era anche il periodo in cui c'era MySpace in realtà.Ah, che bello! E sono il mio social di sempre, tipo, cioè, se potessi fare il mio profilo MySpace con quelle...comunque restando un umbre bracciante del software ma con le skill che ora sarebbe un profilo fighissimo Ma c'è della gente che faceva i soldi anche facendo i profili Io, io, io L'hanno proposto anche a me, quel che voglio Io mi ci son pagato una parte dell'università, la sapete? Praticamente c'era Sei un vero professionista Ma che, ero morto di fame più che altro Nel senso che all'epoca facevamo parte del mondo delle discoteche, quindi con band, dj, erano tutti presi benissimo.Il periodo c'era un tale che si chiamava Stefano Scozzese, aveva un'agenzia di web design molto figa, tra l'altro penso sia ancora operativa, ha fatto dei lavori per Pausini, Bocelli, adesso credo si sia spostato a Miami e si occupi di criptovalute.posso fare una battuta cattiva sul fatto che se in effetti ti metti a fare i temi MySpace per Andrea Bocelli lui non sa se l'hai fatto bello oppure no che maledetto che sei! no però in realtà erano davvero dei capolavori perché erano dei veri e propri siti flash che venivano montati su MySpace naturalmente questa cosa poi nel tempo è degenerata e secondo me ha sancito proprio la fine di MySpace che ci caricavamo tutta la mondezza possibile del mondo e quelle pagine erano impossibili da caricare, ci mettevano un'ora a scaricare tutta la roba, però erano dei capolavori e io ho imparato Flash e Action Script proprio così c'era un decompiler per Flash e cosa facevo? Decompilavo questi siti, tra l'altro là ho visto le prime funzioni di easing per le animazioni, delle roba fighe, decompilavo questi siti, rubavo gli script e poi creavo degli SWF per, che non è solo la band della zona o il DJ amico mio delle discoteche e ci chiedevo quel, all'epoca parlo del tipo 2004, 2003, chiedevo qualche centinaio di euro, naturalmente in nero, e questa cosa era...funzionava anche io funzionava, c'era uno studio però in effetti adesso che hai detto mondo del discoteche io facevo una cosa simile però da bravo backhandista io avevo un tool quando ero un giovane DJ famoso che automaticamente prendeva tutta la mia friend list e gli spammava i flyer delle mie serate nei commenti di MySpace in maniera automagica quindi anche io non ho fatto direttamente dei soldi con MySpace ma quasi che bello che bello mi hai riportato indietro di 15 anni però l'argomento di oggi non è come fare del guerrilla marketing su myspace anche se credo che appunto potremmo farlo ma oggi credo sia tardi penso che sia tardi anche per farlo su facebook e parliamo di leadership Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Prima domanda, un elemento fondamentale che porta a galla il concetto di leadership è la costruzione di un career path, voglio proprio partire da lontano.Secondo voi quali sono le azioni che bisogna intraprendere nella costruzione appunto di un career path e quali sono le tecniche che possiamo utilizzare per rimanere concentrati, per tenere il focus in questo percorso? Io vado ultimo perché ho un'opinione estremamente bold su questo.Io sono un perenne impostore, quindi qualunque possa essere il career path comunque penso di non meritarmelo, di non essere all'altezza, insomma.Però le persone che ho visto fare un career path decente, o quantomeno che avrei voluto fare io, sono persone che magari non sono bravissime dal punto di vista tecnico, dal punto di vista diciamo, non so se il termine è giusto, diciamo relazionale, dal punto di vista sociale, hanno delle skill molto importanti, nel senso riesco comunque a sopperire quelle mancanze tecniche con delle skill sociali di un certo tipo, che spesso magari sfociano anche nel diciamo, come si può dire, sono dei figli di una donna.sì ecco sì sì diciamo diciamo sì è quella classica persona che ti aspetta questo sushi bar no mentre ti parla del tuo del tuo prossimo sprint dicendo però siete voi dei nigiri ti prendi questi nigiri lui ti accarezza e ti dice che andrà tutto bene e che ha grandi piani per te c'è anche quel piccolo aumento a finiamo che è un quinto di quello che comunque prende lui però insomma ma diciamo una persona con delle skill sociali, sicuramente sopra la media.Insomma, il problema che vedo io, e qui insomma chiudo per non diventare polemico, è che spesso se ti ritrovi con queste skill a ricoprire un ruolo che non è strettamente diciamo di people management, ma anche tecnico, puoi fare danni alla fine.Perché lì o vai nel sottoalbero di "mi fido e fate voi", comunque danni, ho comunque visto, oppure mai nel sottualbero so comunque io, io sono quello che sa, però non sai davvero e fai comunque danni, insomma, quindi non ho un'opinione in merito, insomma.Quindi ci aggiorniamo tra due, tre anni, quando magari posso portare anche io a mangiare un nigiri, il mio stagista.No, però, scusate, voglio incalzare e fare una domanda, un dubbio che mi è venuto con Carmine.Per cui ad oggi se tu volessi alimentare un career path con main focus il lato tecnico cosa pensi di dover fare? Secondo me le skills social ti servono comunque insomma nel senso cioè alla fine se chi deve notare la tua bravura, tra virgolette, magari è una persona che non è necessariamente tecnica, ti servono comunque quelle skill lì.Partendo dal presupposto che le soft skill ti servono comunque, comunque se è il tuo ruolo, insomma.Però nel senso, secondo me, sicuramente, cioè, non so quanto aiuti essere il rockstar dev che fa tutto, insomma, però questa è la mia opinione.Secondo me deve essere un mix delle cose.Qual era quel principio secondo cui ognuno fa carriera finché non raggiunge il proprio grado di incompetenza? Alternativamente Peter o Dilbert.Dilbert è una specifica del principio di Peter che dice che tu vieni promosso fino al tuo livello di incompetenza.Potrebbe essere una strategia.Del resto se servi dove stai perché dovrebbero spostarti in un grado superiore? C'è un po' questo pattern, soprattutto io l'ho visto succedere in aziende italiane con le scrivani radica in cui ti dicono "sei molto bravo a fare il tuo lavoro, smetti di fare il tuo lavoro e vai a farne un altro, perché allora adesso, siccome sei molto bravo a scrivere il codice, allora adesso devi fare il manager e sapete anche voi che sono due lavori diversi.E tu accetti perché soltanto il manager hai più soldi.Sì, però secondo voi è un problema di come è strutturato il concetto organigramma all'interno di queste società o è un problema, cioè, riformulo la domanda, mi è capitato di vedere questo elemento in modo molto più acuito nel nostro dominio, nell'IT, probabilmente dipende dal fatto che io questo dominio lo vivo, però per tanti anni ho vissuto anche il dominio del turismo, e molto raramente in casi professionali mi sono trovato a vedere un cameriere che diventava il direttore di un albergo o il responsabile strategico delle politiche commerciali di un'azienda attivistica, no? Ma il più delle volte ho trovato delle persone che avevano fatto un percorso di formazione e hanno iniziato quel percorso, no? E' come il generale, il generale magari passa per un'accademia, non nasce come fante semplice.Quindi secondo voi quanto dipende dal nostro, dal fatto che il nostro ambiente non è strutturato per questa cosa? Allora sicuramente Nel nostro dominio questa cosa è più del genere.Poi io onestamente non ne conosco molti altri.So un po' anch'io per via traverse il mondo del turismo e del marketing turistico ed è in effetti leggermente meno accentuata, ma esiste comunque questa cosa.Io credo che il problema di fondo sia una cultura del lavoro, almeno che ho visto succedere in diversi posti.Per cui ho visto, mi sono sentito dire da una persona di HR, del settore in generale non ho una grossa stima, lei mi ha detto che quando tu fai carriera, fare carriera significa passare dall'essere una persona del fare, da una persona che quindi operativamente fa le cose, a essere una persona del far fare.E quindi di fatto non lavori e fai fare le cose agli altri, perché per carità è una visione assolutamente lecita, a me fa schifo, nel senso che comunque a me il mio lavoro piace, mi piace fare le cose, mi piace risolvere dei problemi, realizzare delle cose.L'idea di che questa cosa, che fare le cose e risolvere i problemi sia una cosa da persone di basso livello mi fa assolutamente incazzare.credo che siano responsabilità differenti e soprattutto credo che nel momento in cui sei una persona del far fare se costruisci un sistema a gradini tu ti posizioni nel gradino superiore passatemi il termine non hai capito un cazzo di quello che stai facendo nel senso che quando mi sono trovato a a gestire l'azienda turistica e soprattutto a operare in un territorio dove dovevo gestire degli stakeholder differenti, una delle cose che ho imparato è che il mio ruolo doveva essere un ruolo di concordo tra gli elementi, cioè io dovevo essere un elemento facilitatore di questo processo, quindi dovevo essere un elemento al servizio di questi attori, chiamiamoli così e credo che anche nel nostro...Posso venire ad abbracciarti? Beh non è una cosa che ho inventato io, il concetto di servant leader è credo un elemento fondamentale di una leadership sana, il fatto che l'armiamoci è partite non funziona probabilmente è un elemento importante c'è però da dire che in realtà c'è anche un altro elemento che voglio portare all'attenzione immaginate di far parte di un team e di ricevere una promozione per competenze per quello che vi pare e diventate il team leader di quel gruppo Come costruite la vostra trastability da leader partendo da un team di pari? Questa è una bellissima domanda alla quale mi è capitato di rispondere tempo fa quando sono stato invitato dall'agente di CodeMotion a un panel in cui il tema era appunto come si diventa tech lead.e il punto secondo me è che uno non diventa leader o comunque autorevole, riconosciuto come leader perché glielo dice qualcuno o perché arriva il papa che lo investe con la spada e gli dice "adesso ti nomino leader da ieri sera tu non eri leader e stamattina sì" è una cosa che...ok, probabilmente sì in termini di bonifico a fine mese, questa cosa ovviamente sì ma in termini di riconoscimento della leadership del resto del team è una cosa che avviene da sé, non puoi forzarla in nessun modo e non, anzi, probabilmente forzare qualcuna una posizione di leadership che non ha il carisma e l'autorevolezza per esserlo, è una cosa estremamente nociva per tutte le dinamiche interne del team.Per cui, per rispondere alla tua domanda, uno diventa leader quando il team ne riconosce la leadership.Chiaro, Luca? Questa cosa introduce anche un altro problema conosciuto "lead de facto ma non de jure" e ci sono tante persone che sono lead de facto ma non con il benefit e la compensation di un vero tech lead.Secondo me è interessante anche accorgersi di questa cosa in tempo o per battere cassa o semplicemente magari anche per cambiare verso quello stesso tipo di posizione ma riconosciuta formalmente, insomma, anche perché spesso magari nell'azienda medio-piccola questa cosa succede, che il team comunque riconosce una figura come tech lead, ma siamo tutti allo stesso livello, siamo tutti senior, siamo tutti qui, insomma, e non c'è un vero riconoscimento degli ur, insomma, che alla fine credo sia la cosa che poi ti ha più fastidio, perché sai effettivamente di avere un impatto di un certo tipo, ma non ti viene riconosciuto.Credo sia anche uno dei motivi che spesso portano a cambiare lavoro, insomma.Io, beh, come sapete, o forse non sapete, non so, io mi ci sono ritrovato esattamente in questa posizione.Un anno e mezzo fa, insomma dopo dieci anni di segnore in azienda, mi hanno proposto di essere responsabile dell'area, cosa che ho accettato.Come diceva anche Carmine, negli ultimi anni lì ero di fatto un leader, perché il team leader, siccome era anche socio dell'azienda, pensava più all'azienda, aveva sicuramente più problemi, più altri problemi da risolvere e lasciava un po' il team in disparte, forte del fatto che eravamo due di noi con l'esperienza necessaria per prendere in mano, insomma, per tenere sulla baracca.Però di fatto alla fine molte scelte, molte decisioni le prendevo io, molte decisioni che non avrei dovuto prendere le prendevo io proprio per portarle avanti, rischiando quello che c'era da rischiare perché insomma un conto è prendersi la responsabilità e avere il diritto di prendersi la responsabilità, un altro conto è prendersi una responsabilità, che ho il diritto di prendere.Comunque sta di fatto che poi sì, sono diventato team leader e ho accusato anche il fatto di dover essere a un certo punto, non un gradino superiore perché non era non è questione di essere sopra o sotto la dipendenza di qualcuno, ma comunque hai un ruolo diverso.Hai un ruolo diverso e determinati rapporti, determinati giochi di amicizia, diciamo, determinate dinamiche giocoforza cambiano.Cambiano perché a un certo punto hai delle responsabilità, hai bisogno di far sentire la tua voce in un certo modo, o a volte, come dovrebbe succedere più spesso, ti devi mettere più da parte, più di quanto non faresti se avessi l'operatività in mano.Infatti la tecnica che ho adottato io è che io non potevo assolutamente calare nessuna regola nuova dall'alto, perché non avevo l'autorità di fatto, perché fino a ieri, fino al giorno prima, avevamo un certo tipo di rapporto, non si può cambiare da oggi a domani così.Se prima la stessa cosa te la potevo dire come un'idea, adesso non te la posso più dire come idea, anche se te la dicessi come idea sarebbe percepita come un ordine calato dadda.Per cui, tabolla rasa, tutte le regole del team le abbiamo fatte insieme, partendo ovviamente da delle basi di letteratura come quelle delle Jail, quindi non avevamo stand up meeting, non avevamo code review, non avevamo niente di tutto questo, eravamo abbastanza autogestiti.Però abbiamo un accordo introdotto, delle regole e contemporaneamente anche ci siamo tutti ci siamo dati la responsabilità di controllare se queste regole funzionavano oppure no, in pieno spirito dell'eggiano.E questo devo dire che mi ha aiutato.Molte volte ho dovuto mettere da parte le mie idee e le mie convinzioni proprio perché alcune regole che io pensavo non erano condivise, semplicemente non erano accettate.La strategia che ho usato è no, le regole sono del team, questo perché l'illuminante Mattia me l'ha detto una volta in chat e l'ho sposato, non Mattia la regola, però se vuoi, è una proposta di matrimonio in diretta? Sono ancora impegnato, poi ci regoliamo.E niente, no, cavolo, ha funzionato, quindi ha funzionato per il tempo che ha funzionato.Poi, come forse sapete o non sapete, chi lo sa, ho deciso che quel ruolo, anzi quel lavoro, manco quel ruolo, Quello lavoro mi piaceva meno che programmare, mi piaceva meno che fare l'operativo e quindi ho deciso di lasciarlo.Secondo me, magari spesso c'è anche una misconception di fondo, il lead dev non deve necessariamente essere anche il project manager, non deve solamente pianificare il lavoro, non deve essere necessariamente lo scran master, quello che fa lo sprint, eccetera.Questa cosa qui si va ad unire a quel discorso che si faceva prima, che in una realtà medio-piccola, spesso magari sei eletto ai benefit del leader, poi emergi anche da quel punto di vista, cominci anche a prenderti dei perk, delle responsabilità che sono più manageriali o comunque che non sono strettamente operative e diventi anche tipo project manager de jure, ma non de facto, eccetera, eccetera.Insomma, io sono dell'opinione che bisogna avere delle conoscenze che sono trasversali, però nel senso sulla parte di leadership, sui ruoli di leadership sono d'accordo che bisogna avere una certa verticalizzazione, nel senso che se sono lead dev non significa devo essere scrammastro, non si sa che devo fare anche il project manager, non si sa che devo fare altri ruoli rispetto a quelli che non mi competono, insomma.Almeno io la vedo così, insomma.Però sono consapevole che in realtà più piccole già è difficile emergere de facto in questo ruolo.Riuscire a emergere anche in ruoli magari più verticali sia ancora più difficile.No, giusto per chiarire, hai assolutamente ragione, tant'è che quando mi sono reso conto che facevo tanto di quel lavoro che poteva essere benissimo delegato, delegabile, delegabile e anche delegato, la prima cosa che ho fatto è stato proprio creare nuove descrizioni funzionali, che vuol dire creare nuovi ruoli, diciamo così, e ho assunto in accordo con la dirigenza altre due o tre persone che mi hanno sgralato del tantissimo lavoro che il primo tempo invece mi ero addossato.Il fatto è che comunque cambia, cioè cambia il tuo ruolo, cambiano i tuoi obiettivi.Nell'azienda dove ho stato prima si adottava il modello sistemico, per cui si ragiona a sistemi.La nostra area era un sistema che doveva interagire con il sistema di livello superiore che a sua volta andava a interagire con il sistema sovraffinato e tutte le altre aree.Ovviamente il ruolo di team lead o di responsabile mio era quello di responsabile dell'area più che di un lead, i miei compiti era quello di far funzionare la rete funzionale, far funzionare la comunicazione tra tutti i sistemi di propria competenza.Però era un altro lavoro, completamente un altro lavoro, non avevo tempo per l'operatività e se avevo tempo per l'operatività evidentemente stavo trascurando qualche altra qualche altra cosa, qualche altra ottimizzazione che solo io potevo fare in quel ruolo.Sì, credo che il nostro mercato abbia una certa confusione, puoi perché questi ruoli assumono delle responsabilità dipendenti dalla dimensione dell'azienda come abbiamo detto prima, o del contesto, puoi perché iniziano ad essercene tanti ruoli, di lead, staff engineer, senior engineer, mette un project manager, vp of engineering e il career path giusto per ricollegarmi al concetto di cui parlavamo prima difficilmente è chiaramente visibile.Quindi alla fine non lo so talvolta si è veramente confusi quando si deve capire chi deve assumersi delle responsabilità e credo che la parola discriminante sia proprio il concetto di responsabilità e quando vi ho parlato del fatto di emergere come leader all'interno di un team del quale sei stato parte credo che anche in questo caso il concetto di responsabilità sia discriminante, cioè io faccio parte di un team, devo in qualche modo diventarne il leader, al di là del riconoscimento dei livelli superiori io devo costruire quella credibilità che mi renderà leader e questo posso farlo prima se ho un management illuminato che riconosce questi elementi o devo fare dopo altrimenti scopria un casino nel senso devo creare i presupposti per diventarlo anche a posteriori e qua mi piace portare una mia esperienza no io come vi dicevo a 20 anni mi sono per colpa di alcune mie pazzie mi sono trovato a dirigere un'azienda con diverse persone coinvolte, diverse decine, alcune anche con più esperienza di me nel dominio e con un'età decisamente maggiore.Come fai a costruirti quella credibilità, parlo di un ragazzino poco più che ventenni, appena laureato, con quello che potrebbe essere essere tuo padre e di acqua sotto i ponti ne ha visto e ne ha visto anche in quel dominio? Beh io credo che gli elementi discriminanti siano alcuni.Uno di questi è il lavoro sodo, la definizione delle responsabilità e quindi il lavoro sodo nell'ottica delle responsabilità, Il fatto come vi dicevo che in qualche modo bisogna mostrare che sei un servant quindi che sei al loro servizio, che sei un gradino più in basso di loro, che devi eliminare gli ostacoli al loro lavoro o comunque lavorare per farlo, un altro Un altro elemento importante era quello dell'alimentare l'empatia.Ognuno di noi è più o meno naturalmente empatico, ok? Nel momento in cui ci si mette nel ruolo del facilitatore, l'empatia va alimentata.conoscete qualche tecnica, qualche strategia che avete utilizzato per dar da mangiare a questo lato che spesso teniamo nascosto? Un aneddoto, non racconto perché è proprio la parola empatia, prima di diventare responsabile ho fatto una sorta di non test, un questionario dove dovevo dare una priorità a determinati valori.Questi erano valori, potevano essere i valori dell'azienda o valori consolidati del team, e dovevo dare una priorità, cioè cos'è che era per me più importante, valori o conoscenze anche, di cos'è che era più importante e cos'è che era meno importante.Tra le varie voci c'era l'empatia, che io però non ho messo come prioritario.non lo ho messo come prioritario perché dissi "beh l'empatia la puoi delegare".Non so che caspita mi era venuto in mente.- "Assumi un orsetta abbraccio a tutti".- Questa cosa qui è una frase, non la so regolare, non c'entra niente, però è immaginata, detta dal cattivo di Toy Story, Zurg, non so se ci vedo presente, con quella voce lì.Sì, comunque anche io pensavo tipo al cattivo dell'ispettore gadget, quello sulla poltrona di spalle che accarezza il gatto e dice "all'empatia la deleghiamo".L'empatia di Space Ranger.Però sono curioso di sapere perché Luca è pensato a questa cosa, perché sicuramente avrei avuto delle ragioni, no? No, in realtà poi ne abbiamo anche discusso perché con questo questionario funzionava così, io facevo questo questionario, l'ex responsabile faceva lo stesso identico questionario, si vedeva quali erano i punti discordanti e i punti in accordo.Ovviamente per i punti discordanti si discuteva, abbiamo discusso anche sul fatto dell'epatia.È venuto fuori il fatto, e io l'avevo detto davvero di getto, l'avevo messa in fondo perché in realtà io sono una persona molto empatica e quando sei troppo empatica in un ruolo di responsabilità e leadership io lo vedo come un difetto.Cioè, quindi io dovevo compensare il fatto di essere già troppo empatico, per cui dicevo "non voglio pensare all'empatia, non voglio pensare di essere empatico perché già lo sono, se penso di essere empatico divento troppo empatico e la cosa non può funzionare.A quanto pare li ho convinti perché poi...No, credo che hai sollevato un punto molto molto molto importante che è il famoso problema del "l'orsetta abbraccia a tutti" lo avete appena scherzato, ma il lead amico di tutti o il manager amico di tutti che spesso ha ha delle difficoltà nell'esercitare il suo ruolo proprio in funzione di questa amicizia e credo che in realtà la discriminante vera sia che si tratta di empatia e non di relazione amicale.Questo vuol dire che per esempio io ho stabilito un mio trade off, nel senso che la prima cosa su cui mi son concentrato era quello di riuscire a distinguere quelle che vengono chiamate le difficoltà umane, cioè la prima cosa che io dovevo leggere in qualità di facilitatore era non capire non solo le difficoltà lavorative ma anche le difficoltà umane della persona senza essere invadente, quindi senza entrare nella sfera troppo personale che invece ha pannaggio dell'amicizia, ok? E questo è, diciamo, l'elemento di apertura verso l'empatia, verso la relazione dell'altro.Però allo stesso tempo ho trovato un modo per concentrarmi tanto sulla costruzione di un consenso e di una fiducia che piuttosto che lavorare sulla creazione di un'amicizia, che sono cose ben diverse.Un elemento che ho trovato utile proprio a livello pratico, cioè tipo one to one gestione domestica della situazione, era quella di alimentare il lato umano andando a pranzo col team, quindi dove non si parlava di lavoro, ma allo stesso tempo dove si...*risata* *risata* *risata* ok...dove...in realtà...- L'ho vista anch'io *risata* dove...- Cazzo io no! - Tranquillo, faremo uno screenshot di questa cosa e soprattutto la voglio dove...si parlava del più e del meno non di elementi necessariamente connessi col lavoro, ma dove si costruiva questa relazione umana? Mattia, ho visto dei tuoi cenni con la testa, cosa ne pensi in merito a questa cosa? Sì, sono mega d'accordo con quello che hai detto e volevo citare un libro molto molto bello che parla esattamente di questa cosa che si chiama Radical Candor e il claim sulla copertina è esattamente questo, dice "Caring personally while challenging directly.Cioè, ok, il fatto che io possa non essere d'accordo con una cosa che hai detto e quindi ti stia facendo challenge perché ho bisogno, è nell'interesse del team che noi adottiamo la soluzione migliore possibile per un problema.È una cosa completamente separata dal nostro rapporto amicale o dal nostro rapporto personale.Io ho diversi colleghi ed ex colleghi con cui sono rimasto amico e ho delle amicizie molto profonde con cui lavorando insieme ho avuto delle discussioni feroci.Io credo che sia importante per riuscire a stabilire una posizione di leadership trovare quella che di fatto è come funziona giustamente l'empatia, cioè trovare il modo di distinguere tra il livello personale dell'interazione e quello di cui stiamo parlando in quel momento lì.Io posso non essere d'accordo ed esserlo in maniera feroce, ma continuo a riconoscere il tuo valore umano.Quando si lavorava in presenza, questo elemento io l'ho sempre mitigato con una birra dopo discussione, no? e soprattutto utilizzavo la tecnica dell'invitare la birra.Da sardo mi viene anche automatico, nel senso che io triggero la discussione, ci sfanculiamo a livelli altissimi, però alla fine della discussione io "Beh, che stai a fa' qua? Andiamo a farci una birra, invito una birra".Giusto per riportare l'elemento umano nella relazione.in un'ottica di remote working? Come cazzo si fa? È una bella domanda.Io l'ho risolta, non è detto che funzioni e non è detto che funzioni con tutti i team.L'ho risolta facendo i one to one con la gente del mio team.ed è una cosa che non me l'aspettavo ma ha avuto benefici giganteschi.Ho iniziato a farla banalmente perché facevamo le retrospettive, come ogni team che si rispetti, e alle retrospettive parlavano sempre gli stessi due, di cui uno ovviamente ero io.Quindi io e il mio manager, nonché il CTO dell'azienda, ci siamo detti "qua c'è della gente che non parla mai, c'è della gente comunque che sta facendo un percorso di crescita e ha bisogno magari di un po' di assistenza, bla bla bla ho detto "boh, io provo a fare 'sta roba di fare dei one to one ogni tre settimane con ognuno" ed è stata una roba estremamente istruttiva anche per me nel senso che ovviamente le persone che in fase di retro erano molto silenziose in un contesto più intimo si aprono molto di più.E mi era dato amore di scoprire un sacco di cose sul mio team che mai mi sarei immaginato e mai sarebbero emerse.Per cui io me la sono cavata così ed è una roba estremamente variabile, nel senso che il mio team attualmente consta di cinque persone.Ce n'è una che si piglia tutti i 45 minuti di one to one e ne parliamo un sacco, abbiamo un sacco di cose da dire.C'è uno invece con cui quando va male male dura dieci minuti in cui ci diciamo "va tutto bene, sono molto contento, mi piace, nell'ultimo periodo mi è piaciuta questa cosa, è stato figo, bello, grazie, ciao".Per cui secondo me avere dei momenti, diciamo, schedulati per dell'interazione che se vuoi è forzata, nel senso che io probabilmente se fossimo stati tutti in ufficio come si faceva in un'altra era geologica questa cosa non l'avrei mai fatta, perché probabilmente ci vedevamo per un caffè o ci incrociavamo alla macchinetta dell'acqua o andavamo a pranzo.Invece avere questa roba che probabilmente all'inizio se ti arriva uno che ti dice "oh facciamo i one to one ogni tre settimane" ti sembrava mega forzata, in realtà ha funzionato.perché comunque è vero che noi leader, passami questa generalizzazione, abbiamo necessità di coltivare il rapporto umano con il resto del team e fare tutte quelle cose che abbiamo detto, coltivare l'empatia e bla bla bla, ma è una necessità che non abbiamo solo noi, è una necessità umana che probabilmente ha qualunque membro del nostro team, cui avere uno spazio per farlo probabilmente fa comodo a tutti.Dicevo, io feci, come sapete c'è stata anche una puntata dedicata, feci un corso di comunicazione proprio in ottica, cioè proprio per prepararmi al ruolo di responsabile.Era sempre un corso di comunicazione sistemica, questa è la...siccome era...adottavamo il modello sistemico, anche la comunicazione doveva essere sistemica.In realtà, durante il corso, a parte cose abbastanza tecniche, abbastanza interessanti, diciamo un paio di cose sono rimaste impresse che mi hanno davvero aiutato tanto anche a gestire determinate cose.La prima cosa è che si parla di tanto di discussioni però in realtà veramente c'è poco da discutere, cioè ci sono quelle discussioni tecniche e lì è difficile che si proteggano all'infinito, cioè a un certo punto si riesce a trovare una quadra o quantomeno un consenso.La cosa più difficile è quando ci sono proprio discussioni che vanno sul personale e lì le discussioni ovviamente che vanno sul personale non devono avere posto nel nostro ruolo.Per cui si dice quando dovete esporre una critica, parlava tanto di critiche di feedback.Quando dovete, nel gergo, "cazziare" qualcuno per qualcosa, assicuratevi che sia necessario.E quando è necessario? Quando questo qualcuno ha creato un danno al tuo sistema, oppure al sistema superiore.Basta.Niente e nient'altro.Tutto il resto mettetevelo via.Perché non vuol dire niente.Perché il tuo ruolo è quello di alimentare il tuo sistema e proteggerlo.Il tuo ruolo poi come responsabile è anche proteggere il tuo sistema dall'ingerenza del sistema superiore, che sarebbe la dirigenza oppure le altre aree, le altre parti, quello che volete.Quello è il tuo compito.Se non c'è un danno va tutto bene, cioè non c'è motivo di discutere.Questa cosa qua mi ha salvato un paio di volte, perché quando stava per nascere una discussione e io stavo per abusare del mio ruolo di super saiyan, c'erano delle tecniche che mi diceva "per sapere rispondi a queste domande per sapere come fare questa cazziata, questa critica".Alla prima domanda che era "qual è stato il danno al sistema?" un paio di volte mi sono fermato, non c'è stato nessun danno, c'è stato un danno al mio ego oppure a quello che io credevo essere giusto e poi chissà magari avevo anche volta, quindi l'ho buttata via, messa via e ho avortito sul nascere discussioni.E questo alla fine è un po' il nocciolo di quello che dovrebbe essere il ruolo di leader, saper fermarsi a un certo punto.Poi ovviamente, e non è facile, anche saper riconoscere, appunto, fermarti, ma per questo ci sono delle tecniche, saper riconoscere quando stai sforando e quando no, perché ovviamente siamo umani, noi crediamo di stare lottando per un danno che poi alla fine abbiamo ricevuto soltanto noi, non esisteva.Secondo me, concordo su tutto, vorrei farvi una domanda.Si sta parlando di ruoli, team lead, il team, il sistema superiore, la dirigenza, eccetera, eccetera.cosa che ho visto, che ho sentito e che ho toccato con mano è che spesso per tendere a questi sistemi complessi e gestibili si tende a sottovalutare o a sovravalutare la grandezza del proprio team, della propria organizzazione.Nel senso, non tutte le aziende sono Spotify, non tutte le aziende sono Netflix, non tutte le aziende sono Google, no? E io quando magari mi sono ritrovato a parlare con persone che lavorano in aziende di 30, 40 persone, di 15 persone, a parlare di Tribe, Spotify, il Team Lead, eccetera, eccetera, l'ho sentita come, diciamo, una cosa che credo sia abbastanza frequente, come non voler trovare una propria dimensione, ma voler prendere un framework che funzioni in una determinata realtà e adattarlo a forza in una realtà per cui non è pensato.E quindi ci si trova con sei lead, tre manager, sono tutti project manager, sono tutti senior, Insomma, nel senso, vorrei anche parlare sull'effetto contrario, in senso, non è detto che ci vogliono tutti questi livelli e che sia, io però ho detto che spesso capita che sei riconosciuto, che sei de facto ma non de jure.Spesso c'è anche il contrario, dove lo sei de jure ma non de facto perché non c'ha senso farlo de facto, non so se vi è mai capitato, insomma a me per ridere mi piace dire che sono tutte startup fin quando non decidono che è il momento di diventare corporate oppure viceversa.Allora, voglio ritornare per un attimo all'one to one perché secondo me è un strumento importantissimi e su 1 to 1 c'è un elemento che fa parte del discorso che facevo prima no del costruire la trastability tra i due elementi che viene anche in aiuto ai famosi 1 to 1 silenziosi non so quanti di voi hanno fatto dei 1 to 1 dove la persona davanti non parlava, bisognava utilizzare le pinze per fargli dire una cosa e quindi siccome il one to one è lo strumento ideale per avere una visione verticale che va a completare la visione insieme in modo leader, è importante che si parli e io ho una tecnica che ho utilizzato è quella di iniziare la discussione alimentando quell'elemento di empatia, quindi mettendo al centro la persona più che il tecnico, sempre nell'ottica di rispettare gli spazi altrui.E poi l'altro elemento invece era quello di avere una visione un po' più tecnica, più lavorativa un po più legata legata al team ma credo che la costruzione del one to one vero sia nel momento in cui si dà valore al one to one e qua voglio tirare le orecchie a situazioni in cui il one to one è visto dal manager come un elemento non fondamentale ma che fa parte di quell'insieme di cerimonie, fa parte di quell'insieme di cerimonie che si fanno tanto per fare.Un campanello d'allarme è per esempio il fatto che un certo lead disposti one to one nel calendario come se fosse una pallina a ping pong o si presenti in ritardo.questo va a intaccare quell'elemento di trastability che poi è l'elemento fondante per un one to one positivo.Secondo voi ci sono altri elementi che depotenziano il one to one? C'è anche l'assetto dello spazio, che nel caso di spazi virtuali è ok, un po' si perde, però una cosa che mi dissero a questo ormai famosissimo corso è che quando devi parlare con qualcuno, one to one o per qualsiasi altra ragione, è importantissimo preparare il posto dove stai effettuando il colloquio o comunque il dialogo.E' importante non avere la scrivania davanti, è importante essere a paro livello, è importante mantenere lo stesso tono, è importante mantenere lo stesso tono e lo stesso stato d'animo di chi hai davanti.Sono tutte cose che anche nei one to one mi hanno aiutato.Se io avevo davanti una persona agitata, mostrarmi davanti lui eccessivamente calmo non era forse una buona idea.Mi dovevo in qualche modo allarmare anche io, come per dire sono con te, sono nella tua stessa lunghezza.E poi soprattutto stare molto attenti alla comunicazione non verbale, è il motivo per cui ovviamente in remoto si perde un po', però quantomeno si dovrebbe preferire webcam accesa, microfono, perché devi sapere intercettare anche il non detto, perché se io ti chiedo "va tutto bene?" o ti faccio un'altra domanda meno diretta e tu mi rispondi "sì", devo vedere quanto è profondo il tuo "sì" e lo devo sapere intercettare.Io aggiungo anche una cosa che è una skill che ho imparato facendo i One-to-One e facendo anche anche il lavoro che facevo prima di developer relations engineer che funziona molto bene ovviamente durante le call e le interazioni remote che è prendere nota mentre stai parlando delle cose che dice e delle cose che dice l'altra persona ed è una skill piuttosto difficile da imparare perché comunque anzitutto devi chiarire con l'altra persona ed è una cosa che subito la metti in chiaro "guarda io ogni tanto mi senti scrivere ma non sto giocando a solitario, non mi sto facendo i cazzi messo, prendo nota di quello che ci diciamo perché voglio poter fare follow up di quello che ci siamo detti".Ed è...io almeno io faccio molta fatica a scrivere e ascoltare insieme, banalmente sono due cose che devi fare contemporaneamente, per cui è un po' come quando...è una roba che ho imparato anche...che le insegnano anche a scuola, no? appunti mentre un professore spiega.È più o meno la stessa cosa, però è veramente una roba che ho dovuto un po' faticare per apprendere e che però ho scoperto che fa una differenza gigante, nel senso che comunque riprendere le note di quello che ti eri detto la volta prima e quindi poter fare follow up di quello che ti eri detto la volta prima, vedere se i problemi che c'erano si ripresentano o sono cambiati e così via fa un sacco di differenza anche rispetto a quello che dicevi prima Mauro del problema dei one-to-one silenziosi, nel senso che comunque hai diversi conversation starter nel momento in cui hai le note della volta prima.Bene.Per cui quello secondo me è una cosa che fa molta differenza nei one-to-one.e soprattutto è uno di quegli strumenti che ti aiuta a dimostrare il valore che stai dando alle parole dell'altro.Una cosa che mi ha sempre fatto piacere nelle discussioni appunto con i miei attuali manager è proprio il fatto che si fermassero e mi dicessero "No, no, no, fermati un attimo, questo me lo segno bene perché ci sentiamo la prossima settimana e ti do gli updates.E questa cosa ha costruito trastability.Scusate se vi rompo le scatole tantissimo ma secondo me è il pillar fondamentale.quindi credibilità verso il manager, mi ha fatto rendere conto che sono un elemento rilevante di quel tipo di dinamica e quindi ha dato valore a quello che faccio e quindi vedere questi due elementi anche se non sono nettamente elementi tecnici o non sono per niente elementi tecnici, mi ha portato a vedere questa persona come un mentor.Non è necessario che il mentor abbia esclusivamente da darmi degli elementi di tipo tecnico, ma un mentore può anche darmi degli elementi di tipo dinamico, degli elementi di tipo relazionale.secondo me sto vedendo male, secondo voi sto vedendo male il ruolo del mentore o possiamo anche classificarlo in questo ottimo? secondo me un mentore ti deve dare molto di più dal punto di vista relazionale e soft in generale dal punto di vista tecnico ti basta un posto medio allora mi accompagnate a una domanda fondamentale per voi cos'è il mentore? grazie per la domanda ma secondo me ci sono diversi modi di essere mentore di qualcuno io ho diversi mentori molti sono in questa stanza in questo momento.Per me un mentore può anche essere semplicemente un tuo peer con cui ti piace confrontarti quando hai una situazione e hai bisogno di un input in più, perché non sei convinto della tua risposta istintiva e hai bisogno di un punto di vista diverso.Nel gruppo Telegram segretissimo di noi persone di questo podcast sapete che io lo faccio spesso.E per cui Mauro, Luca, Carmine, ma anche Alessio e Leo e tutto il resto della gente che parla qui mi sono stati utili come mentor in questo senso.Diverse volte...e io ho diversi anche ex colleghi, amici che hanno lo stesso ruolo.Per cui probabilmente è una cosa che succede anche tanto di più quanto più sali di livello e di esperienza, un mentor è anche una persona del tuo stesso livello con cui ti confronti.Invece quando il livello è diverso, il rapporto è, secondo me, sempre importantissimo "dammi un punto di vista diverso dal mio", che magari è tanto più diverso se il livello di esperienza è diverso.però è un rapporto assolutamente bidirezionale.Secondo me perché un rapporto di mentorship funzioni bene non è una cosa in cui io ti dico cosa devi fare e tu lo fai, ma è una cosa in cui io ti do il mio punto di vista, tu mi dai il tuo e poi ognuno fa quello che ritiene necessario, perché entrambi ci fidiamo che l'altro sappia fare il meglio che fa.Dobbiamo stare attenti, condivido tutto quello che ha detto Mattia e aggiungo i fatti, bisogna stare attenti a non creare un rapporto di dipendenza tra le persone che poi reputi più che mentore, cioè reputi qualcosa di più.In quel caso c'è il rapporto di dipendenza e anche di se puoi essere soggetto a manipolazione diretta e indiretta o voluta o non voluta.Alla fine c'è la differenza che c'è tra il mentor e il guru, cioè nel senso io li ho visti entrambi, c'è il mentor che condivide qualcosa con te e accetta che tu condividi qualcosa con lui, il guru ti dice "ero sull'autogrill e ho pensato alla nuova architettura della nostra applicazione, che mi è capitato in una precedente esperienza che una persona mi mettesse la mano sulla la testa e mi dice "tu non hai capito, io stanotte ho sognato l'end point" e non sto scherzando, chi mi ascolta e chi ha lavato con me ha perfettamente capito a chi...Tu lavavi col mago Telma.Che un'ansia lì è messa "tu non comprendi la passonomia del dominio funzionale di questa io l'ho sentita.Era un crew di merda con Ruby, cioè nel senso, adesso non me lo capisco che cosa avesse sentito, però nel senso queste figure ci sono, spesso sono figure con delle skill relazionali molto sviluppate, una persona con un estremo carisma, alcune funzionavano, ho mandato a f***** alla prima riunione, insomma, nel senso proprio testuali parole, insomma.Però ci sono anche queste figure qui, insomma, e spesso anche il guru nella mia esperienza è quello che sa qualcosa che tutti non sanno, ma che sa solo lui e crede di essere insostituibile.Speriamente questa cosa nelle realtà piccole non credo, cioè c'è ma in realtà diciamo medie un po' più grandi, cioè c'è sempre quello che dice questa cosa la soffa solo io e non te la dico perché così sono insostituibili e quando quella persona lì è in una posizione anche diciamo di più alta di gestione del team e queste cose così viene visto come il guru che sa come si riavvia e il last exercice tipo, è veramente capitato, il culo che sa cosa succede quando lo sharding, tutto questo così, che magari tecnicamente non sono nemmeno delle banalità, ma sono effettivamente qualcosa che tu devi condividere, insomma.E credo che spesso sia anche la realtà aziendale italiana, mi sono confrontato con altri miei colleghi che la vorranno fuori o comunque in aziende di un respiro un po' più internazionale.Nel senso, in Italia spesso c'è il capo e c'è il subordinato.Nel senso, dove magari l'aspirazione del subordinato è diventare capo.Sì, credo...Diventare capo nel senso di...stai zitto.insomma, per essere volenti di questa cosa c'è, insomma, c'è.E secondo me, dal punto di vista tecnico, pensare di avere sempre ragione è la strada maestra per poi farsi un lavoro creativo, le opinioni di tutti possono essere determinanti per arrivare che tu mi arrivi e dici "io sono il signore di Neo4j", ho sognato il grafo, lo sto visualizzando con le mie mani, lo stampa mi è stata detta.Nel senso tu comunque lì un po' ridi perché che dici, insomma, a fine che fa, chi ha i vigili per fare il TSO, io dico di sì.Però comunque, insomma, e secondo me sono anche delle situazioni in cui magari se sei emotivamente un po' più introverso, comunque hai delle problematiche, tu, insomma, di diverso genere, che fare con una persona del genere può essere veramente disastroso, perché accentua tutta una serie di cose che non ci dovrebbero essere.E magari in una realtà che non è tanto strutturata, dove non puoi andare dalle char a dire "oggi XYZ mi ha detto che si è sognato il cluster", e questo lo devi semplicemente tenere.In senso che questa cosa qui non saprei come risolverla se non cambiando lavoro.Credo che hai detto un elemento importante.Hai evidenziato un elemento importante.Per me il concetto mentore e mente è semplicemente un gioco di specchi.Io lo dico spesso quando parlo di relazioni umane.cioè, come facciamo noi per capire l'universo? Adesso mi direte "Mauro, ma sempre con queste scite da cazzo te ne usci?" Eh sì, ma come facciamo per vedere la Terra e comprendere il globo terraqueo? Semplicemente, noi guardiamo l'immagine riflessa o l'immagine o il risultato riflesso da un altro pianeta, una stella, un quello che cavolo volete, che è uno specchio che ti permette di comprenderti meglio.Questa cosa in realtà funziona nel rapporto mentore.Nel senso che se tu sei un mentore, sia che tu sia un peer, un pari, o che tu sia un po' più junior rispetto al tuo mentore, hai modo di vedere un te diverso da quello che percepisci.perché la visione che noi abbiamo è assolutamente parziale.La stessa cosa funziona per il mentore, perché il mentì propone e prospetta dei punti di vista sia che siano tecnici, che siano relazionali, completamente diversi dal mentore, che quell'esperienza può non averla vissuta o può non averla vissuta in quel modo e quindi si deve confrontare con un'esperienza non sua, deve interiorizzarla e trarne delle conclusioni e quindi c'è tutto un processo d'apprendimento basato su quello.Vero è che per fare questo tipo di lavoro non puoi essere, non essere aperto a questo tipo di relazioni E soprattutto ci deve essere una cosa chiara dall'inizio, proprio per evitare quello che si diceva prima di relazione malata di dipendenza.Ci deve essere un sistema di expectation chiaro.Cioè, tu devi sapere cosa aspettarti dal mentore se sei un menti.E tu devi sapere cosa aspettarti dal menti se sei un mentore.Se questa informazione è condivisa, a quel punto può crescere una relazione sana, anche perché con questa informazione tu formalizzi un altro elemento importante, che è quello di quanto devi sbattere la testa sulle cose prima di rompere le balle al tuo mentore, se sono mentore.E soprattutto, mentore, quanto aprire le porte del "Ok, pingami quando vuoi".Perché l'elemento dipendenza viene proprio da questo elemento cioè una cosa io sono stato poveretti loro mentore di un po' di persone no? E una cosa importante e difficile da formalizzare da condividere e soprattutto da avere un agreement da tutte le parti era proprio questo elemento che è un trade off perché più più ti chiudi e fai sbattere la testa al tuo mentì, più lui rischia di perdere fiducia nei tuoi confronti.Però più ti apri e più lo rendi interdipendente e soprattutto rendi impossibile il tuo lavoro e non gli permetti di apprendere o comunque di...perché raga diciamoci la verità, noi apprendiamo sbattendoci la testa contro il muro.Il mentor è quella persona che ha posteriori, una volta che ha sbattuto il muro, ti aiuta a capire la visione di...la testa contro il muro, ti aiuta a capire la visione di insieme, cioè ti aiuta a dare una lettura differente e più completa, o da un'altra prospettiva, di quella esperienza.Giungo che probabilmente c'è c'è tantissima empatia anche nel ruolo di un mentore che capisce di quanta autonomia ha bisogno il suo mentì.Qui adesso mi metto il cappello da allenatore, che fondamentalmente è un mentore di una squadra di calcio.A me capita spessissimo di dover regolare la mia comunicazione con dei giocatori perché ce ne sono alcuni che hanno bisogno che tu gli evidenzi gli errori che fanno in maniera anche molto netta e molto ferma e ci sono dei giocatori che invece se tu gli evidenzi un errore che hanno fatto si incazzano di più perché lo sanno da soli e sono già abbastanza incazzati da soli per aver fatto un errore e quindi devi dividere un altro approccio, devi magari proporgli una soluzione alternativa anziché dirgli questa cosa sbagliata, "Perché non provi a fare quest'altra cosa?" Però lì di nuovo è quello che stavamo dicendo prima, che è probabilmente una delle skill fondamentali di un buon leader, che è l'empatia, che è capire come si sente la persona che hai di fronte rispetto al feedback che gli stai dando e essere in grado di regolarlo di conseguenza.Chiaro, chiarissimo.Voglio aggiungere un altro elemento.in realtà ciò che ti fa capire di non essere un potenziale mentore è proprio il non riuscire a gestire questo trade off e anche qua voglio fare una capriola e collegarmi su un altro concetto che però al di là della capriola è molto connesso cioè buona parte dei mentori vengono dal mondo delle community e spesso a prima occhiata tu valuti una persona o scegli un mentor all'inizio per le sue skill tecniche.Salvo sapere, salvo scoprire che dietro al buon viso rassicurante di un mentor si nasconde una cosa che noi nerdoni chiamiamo l'alpha geek, l'uomo alfa.molte community nascondono questo tipo di figura cioè quella che è il miglior tecnico del gruppo o del team quello che ha sempre una risposta giusta o assimilabile alla correttezza e però però là succede un macello, nel senso che si vanno a innescare tutta una serie di dinamiche negative e là la mia domanda è vi è mai capitato di scegliere un mentore perché tutti abbiamo scelto un mentore, abbiamo cercato un mentore e trovarvi davanti a questo tipo di figura? Abbiamo letto tutti i libri di Uncle Bob, per cui sputina che era un coglione.Ma non significa che quello che abbia scritto sia tutto sbagliato.Cioè, nel senso bisogna comunque separare la persona dal te.Sicuramente io non sono d'accordo con Uncle Bob su tante cose, nel senso su Twitter o su uno spesso di leggerlo, però Clean Architecture è un buon libro, Clean Agile mi è piaciuto, e Clean Code nella sua semplicità può essere un buon punto di partenza per tante persone.Però questa cosa non si lega comunque al discorso del guru, no? Cioè, nel senso, io devo decidere con che framework devo fare il mio nuovo front-end.ho visto il talk di xyz che mi ha detto che jquery mobile è meglio di angular e quindi io scelgo insomma jquery mobile.questo non te lo dico nemmeno io guarda.comunque questa cosa c'è no? e secondo me è sintomo anche di una una community non troppo sana e fortunatamente non succede in tutte le community.Nel senso, è vero che ci sono alcuni pilastri, alcune figure sicuramente importanti, però non significa che abbiano sempre ragione.Però spesso ci sia anche il contrario.Cioè, ad esempio, nella community JavaScript, esce fuori un guru ogni 6-7 ore che dice una cosa diversa, insomma.Quindi, nel senso, boh, non lo so, un po' di bilanciamento ci vorrebbe.Però sì, sono io, effettivamente non sei più un mentor, sei diventato guru, insomma.Non sei più mentor.Credo che, in realtà, il trucchetto per evidenziare questo tipo di persone viene dal fatto che il mentore, la capacità principale del mentore, è la capacità d'ascolto, è l'elemento fondamentale, invece il geek alfa, la figura alfa, ha un approccio completamente diverso e soprattutto porta con sé l'indiscutibilità, come si chiama così, delle proprie tesi.cioè non mette mai in discussione le proprie tese e invece spesso vi è mai capitato che un bambino vi facesse delle domande per mettere in difficoltà e mettervi dei dubbi in merito ad alcuni assunti che avete della vita in generale? A me i miei nipotini mi mettono in crisi fisso quotidianamente però Luca ha più figli di me quindi probabilmente più lui di me quello quello sì soprattutto quando fanno quando hanno la fase dei perché che ti mettono proprio nudo perché sai è noto che quando tu hai un problema o quel che ti devi dire perché per almeno quant'è letteratura 4 o 5 volte 5 ok i figli te arrivano al 20, al 21 e quindi ti spogliano e ti ignudano davanti alla tua ignoranza e alle tue convinzioni.Stupido.Io credo che per crescere e soprattutto per… buttiamola anche sul prodotto, per fare un prodotto sono determinanti un prodotto una community sono quanto sono determinanti le buone idee sono anche determinanti le idee del cazzo le sparate idiote perché mettono in discussione le buone idee per cui l'apertura a questo tipo di dinamiche è fondamentale se tu non hai e questo tipo di apertura tu cerchi di spingere il contesto dove vivi verso una finta cultura dell'eccellenza, che però in realtà è alimentata dalla paura degli altri nel tirare fuori delle idee che possono essere considerate idee del cazzo ma che in realtà portano in un processo di sviluppo a un contesto d'eccellenza vero, naturale, sano.Allora alla fine l'importante è anche trovare il bilanciamento tra la sindrome dell'impostore e il dining room, perché per Cangari ci sono persone che sono molto brave, che però non non hanno o comunque non riescono ad avere quella capacità relazionale e personale non di imporsi ma di emergere con determinate idee.Insomma, se vogliamo portare l'esempio della community in un contesto mediamente più picco, aziendale è tutta, secondo me, anche una questione di cultura aziendale, una cultura aziendale dove le diversità di qualunque tipo non sono ben viste, non sono incentivate, questa cosa non potrà mai succedere.Ed è quello che succede in tantissime community dove si è partiti con determinati pilastri, è guai a metterlo in discussione.Poi, alla fine, secondo me, come segui la domanda, questo tipo di cultura aziendale ha spazio anche nelle aziende più piccole o la possiamo solo trovare, magari, nella big corp che ne fa anche, diciamo, una...un qualcosa anche di immagine, no? dove tutti i tipi di diversità, se parliamo di diversità di noitecchie, non per andare in altri tipi, che sono importanti ma non ci competono in questo momento.Secondo voi c'è spazio anche nella community più piccola? Nel senso, la cultura aziendale di valorizzare tutte le idee, tutte le diversità, oppure è qualcosa che va arginato comunque va concesso solamente in parte.Qual è il bilanciamento tra l'anarchia e l'equilibrio di Prost? Una domanda molto filosofica.Io non sono un grande fan della loro cultura aziendale, ma nei principi fondativi della cultura aziendale di Amazon ce n'è uno che si chiama "disagree and commit".Quindi ti dicono che è estremamente incentivato il disaccordo e il challenge delle opinioni, per cui se tu presenti una soluzione è atteso e te lo aspetti che ti facciano le pulci su qualunque cosa, virgole comprese, ti mettano a nudo e veramente io tra l'altro questa cosa ho visto succedere nell'altra Big Corp in cui ho lavorato ed è un'esperienza estremamente faticosa e che ti fa sentire il peggio impostore del mondo perché davvero vieni challengiato in una cosa magari a cui tu tieni quindi la prendi anche sul personale, c'è questo rischio.Però quello che ti dice il principio di Amazon è che una volta che siamo arrivati a una soluzione che va bene a tutti, fondamentalmente non devi più rompere i coglioni.Quindi una volta che il team ha deciso una soluzione, tutto il team rema in quella direzione lì.E secondo me quello è un buon modo per trovare il bilanciamento tra anarchia in cui ognuno dice la sua perché è giusto che ognuno possa dire la sua, però a un certo punto si tirano a riga e si va tutti nella stessa direzione.dove sta a quel certo punto, secondo me, probabilmente anche lì sta la bravura di un leader.Secondo voi, perché me lo sono sempre chiesto, voglio ricollegarmi a quello che ha detto Mattia prima, ma che secondo me si rifà anche a quello che ha appena detto Luca, Come si fa nel momento in cui si fa "challenging" a poi dire "da questo momento in poi si fa così, tutti andiamo in questa direzione e l'ownership è condiviso"? È difficile.Cioè eliminare il "te l'avevo detto" per capirci.Devi veramente mettere da parte l'ego.io confesso di aver peccato di questa cosa diverse volte.In passato è capitato che dovessimo scegliere se fare un progetto in PHP o in Java.Abbiamo iniziato in PHP, io ho fatto per diverso tempo quello che diceva "ah, minchia, PHP fa schifo, PHP lo sapete tutti, cosa penso di PHP".Dopo quasi sei mesi, che il progetto era ormai in ritardo di un anno, abbiamo deciso di buttare tutto e rifarlo in Java e lì è stato difficile, però mi rendo conto che probabilmente ci ho messo del mio anche nel far andare male questo progetto nei suoi primi sei mesi.Allo stesso modo, mi è successo di recente, avevamo un progetto legacy con il debito tecnico e io ero molto intenzionato a spegnerlo e rifarlo nuovo, ma non potevamo spegnerlo del tutto perché comunque faceva dei soldi.e quello che ho fatto per un anno è stato dire "vabbè, tanto il progetto lì lo spegniamo a breve, sti cazzi di fare le cose fatte bene".Alla fine della storia è venuto fuori che spegnerlo non era una cosa praticabile e per cui di fatto quel progetto lì che aveva del debito tecnico adesso ha un anno di debito tecnico in più, per colpa mia.e questa cosa è successa proprio perché non sono stato in grado di fare "disagree and commit", cioè di fare la parte di "commit" dopo aver disagreato.Credo che sia la parte più difficile delle due, onestamente, nel senso che dire "non sono d'accordo, secondo me questa cosa si dovrebbe fare in un altro modo" non sono capaci tutti, è quello che fanno i vecchi al bar o i vecchi che guardano i cantieri e dicono "eh, non ci può lavorare così".- Pega.- Pega.Dire invece "ok, magari non sono al 100% d'accordo, però rispetto l'opinione del team e quindi vado nella stessa direzione in cui va il team" è una roba che richiede obiettivamente del pelo sullo stomaco.e poi hai evidenziato un altro elemento che nel momento in cui si tirano la fila di una certa decisione spesso il responsabile ahimè di questa decisione diventa poi il lead che deve formalizzarla ed è un problema proprio perché si perde tutto l'insieme dell'ownership il concetto di ownership e allora a questo punto come si fa da lead a tenere quella la trastability nel momento in cui si è fatto una capellata enorme lo si dichiara io io l'ho dichiarato in maniera estremamente trasparente con il mio team ho detto ragazzi ho fatto una cazzata è stata un'idea di merda ho fatto per un anno ha remato contro il team ed è stato un errore, me ne rendo conto adesso.Non so dire poi che opinione abbia di Maelstrasm, ma adesso probabilmente pensano che sia un coglione.Io un paio di volte ho detto, ero giovane e inesperto per qualche mese fa, per una scelta fatta qualche mese fa, però si impara.Appunto c'è la cultura dell'errore che si deve comunque inserire in azienda.L'unico errore che puoi fare è quello di non commettere errori, quello di non provare cose nuove per paura di sbagliare.L'errore lo dobbiamo riscattare e lo dobbiamo ammettere quando c'è e soprattutto dobbiamo imparare dall'errore.Una volta che abbiamo imparato qualcosa l'errore si è ribagato.Ammettere di aver fatto un errore è un grande segno comunque di leadership, cioè nel senso è una delle cose che mi fa dire "ok, questa persona può mantenere questo ruolo perché sa mettere qualche ruolo", insomma è il segno massimo di una leadership sana.L'unica cosa è che questa cosa può scontrarsi con la cultura della colpa o, ancora più brutta, della vergogna che magari in determinati contesti ci possono essere.Insomma, alla fine, diciamo, credo che sia più dannosa la cultura della vergogna, perché nel senso essere, insomma, commettere un errore in un ambiente del genere fa sì spesso che gli errori non vengono più commessi perché non si osi più perché non ci si prendono più dei rischi, insomma.Come leader accetti di prendere dei rischi e accetti comunque che quella scommessa non sia pagata.Come di aspettare, insomma.Fa parte del gioco, ecco.- O perché non scondi gli errori.- Secondo me c'è un tema molto bello e molto importante rispetto a questa cosa che hai detto degli errori che si lega anche a quello che dicevamo prima della relazione tra mentor e mentee, nel senso che un buon leader, un buon mentor è uno che accetta l'esistenza degli errori propri e non e fa in modo appunto di eliminare la cultura della colpa e della vergogna, ma ti dice "ok, gli errori esistono e li facciamo e li faccio io" appunto come dici, come era tutto adesso, ma li fai anche tu, mentì o giugnolo, chiamalo come vuoi e non è un problema.e anzi, io ricordo che ne parlavo qualche tempo fa con il mio ex manager e a me è piaciuto moltissimo il mio manager dell'epoca di Google che mi ha lasciato intenzionalmente fare degli errori perché mi ha detto "guarda, se io ti avessi detto come si faceva questa cosa giusta mi avresti ascoltato, ma probabilmente l'avresti fatta sbagliata lo stesso" avertela fatta fare sbagliata invece ti ha permesso di vederlo meglio con i tuoi occhi.Per cui io credo che faccia parte del buono del ruolo di un buon leader, di un buon mentor anche permettere o magari anche indirizzare intenzionalmente verso un errore, un fallimento le persone che mentora.Perché c'è un grosso valore educativo in questo.Esatto, infatti secondo me l'errore del lead può essere un potente strumento pedagogico.Pedagogico forse non è la parola giusta perché tratta i team members come dei sottoposti, ma un ottimo strumento d'apprendimento chiamiamolo così per tutto il team lead compreso.Un elemento fondamentale viene dal concetto di gestione del fail, ne ha accennato prima Luca.Primo elemento da fare, quando c'è un errore mai attaccare la persona ma criticare...Abbiamo un problema.Mi sentite? Sì, sì, sì, non ci sei sentito per una ventina di secondi.Scusate, qua in Fuzia ci sono dei problemi tecnici con le retti, ma vi dicevo, giudicare sempre l'azione e mai la persona e questa cosa è tanto importante anche se chi deve essere giudicato, cosa deve essere giudicata è l'azione del lead.questo permette in qualche modo di tutelare la fiducia che si costruisce verso il lì altro elemento fondamentale e in questo caso mi metto un golfino nero e degli occhiali con la montatura rossa e per un attimo mi vesto da Matteo Flora con il quale sono in disaccordo con circa il 98% di quello che dice ma una cosa che secondo me è sacrosanta che dice spesso e che condivido è la parte di reputation una cosa che il lead deve fare è gestire la propria reputation e come si gestisce la reputation nel momento in cui c'è un errore con degli elementi actionable alla fine nel senso che per dare un senso a quell'errore il leader deve in qualche modo mettersi davanti agli altri e dire ho fatto una cappellata, spacchettare l'azione e comprenderla a fondo insieme agli altri, quindi un momento di estrema condivisione importantissimo per il team e terminare con una serie di azioni che servono da una parte per tamponare gli effetti dell'errore dall'altra per prevenire un errore simile o assimilabile e soprattutto per creare della knowledge condivisa in quel caso da una situazione critica in termini di trastability tu ti porti, tu lead, ti porti in una condizione di ancora più rispettabilità.Ve lo dico perché l'ho fatto...Alla, a me è capitato prima esperienza a fare una cazzata enorme.Cioè, mi sa che l'ho anche già detto nel podcast, andare a fare una conferenza in una città, parlare di un progetto per un'ora e mezza, e verso la fine dire "in questa città" e dire il nome di un'altra città, faremo una cosa fantastica.questa è una sputanata colossale non tanto col cliente ma con il team che si era fatto il culo per un anno lavrando quel progetto e la mia prima azione, il mio primo acchitto è stata quella di difendere la mia posizione quindi "sì ho sbagliato ma cazzo voi lo sapete è mille responsabilità secondo voi" no, non funziona così analizziamo l'azione, quali sono le cause, come fare a prevenire le case ed è un lavoro di gruppo.Nel momento in cui io mi son posto in quest'ottica, perché il danno era condiviso, concordo, alla fine insomma, poi lo richiamo magari anche dei barocchi, dei barocchi, insomma alla fine avere il coraggio e la capacità di chiedere scusa quando si è sbagliato, quando si ha sbagliato, insomma, è quella cosa che ti può effettivamente far mantenere la reputation e probabilmente ti fa anche gestire meglio tutto l'inevitabile senso di colpa e di fallimento che hai quando effettivamente sbagli.Insomma, alla fine combattere e remare contro il fallimento ti fa stare male, abbracciare il fallimento ti fa crescere, credo.Ma quando cominci a sbagliare troppo spesso? Ti fa crescere ancora di più perché se capisci che c'è qualcosa di sistemico più grande che va aggiustato.Nel senso l'errore sistemico può essere sintomo di qualcos'altro, il più delle volte, perché con questo approccio te riesci… cioè l'importante è rendersene conto da sé e non mettersi sulla condizione in cui sono gli altri a fartene rendere conto di forza, insomma.Nel senso che lo siamo quello e tutto.Rispetto a questo tema, tra l'altro a quel panel sui leader di cui vi parlavo prima, Gabriele Lana, che è un leader vero e non è come me, ha dato una definizione molto bella, diceva "per me un tech lead è uno che ha molte cicatrici, perché ha fatto tanti errori, ha fatto tante cazzate e da quelle ha tratto degli insegnamenti.- Verissimo.E Luca ha detto "e quando sbagli troppo spesso?" Beh, secondo me...- Definisci troppo spesso.- No, ma soprattutto capisci dove stai sbagliando e cosa stai sbagliando, nel senso che Se stai sbagliando nella stessa area, vuol dire che non stai prendendo le giuste azioni correttive, quindi non stai attivando bene il processo d'apprendimento.Se invece sbagli in aree molto diverse e sbagli sempre tu, vuol dire che per esempio non stai responsabilizzando il team e quindi non c'è un ownership delle azioni condivise.quindi in realtà il trucco da questo punto di vista il server ballet può essere probabilmente le azioni correttive non sono non sono prese ragazzi cazzo mi distraete devo dirlo ne lasciate mi stanno ancora prendendo piedi in culo perché ho sbagliato il nome della città No, dicevo, ricollegandomi a quello che dicevo prima, sostanzialmente esistono dei modi per capire dove si sta scrivendo.Condividere la responsabilità e soprattutto in qualche modo delegare, quindi permettere anche agli altri di sbagliare, non solo a te è un elemento, quindi se sto sbagliando troppo in aree troppo diverse probabilmente sto facendo troppo, centralizzando troppo queste possono essere delle delle delle visioni su sbagliare troppo.Ragazzi io guardavo il timing siamo tipo a 1 ora e 38 che dite? In media come tutte le altre puntate se non di più se non se non sotto quindi forse dovremmo continuare.Non abbiamo ancora parlato di Ralla alla fine.No? Però dobbiamo ringraziare il donatore della puntata.Sì, quello tocca a me.28 gradi e mezzo all'ombra non ci ave più da 20 giorni e non c'è un aleto di vento caldo, tanto caldo, tanto assente ja, ja, ja portaci da bere uno shot di birra, ma presto portaci da bere uno shot di birra, ma frutta con o senza schium scuro, chiara, ma che sia una birra una birra, please! oh yes, sir! ringraziamo Antonio Bovenzi che ci ha scritto un messaggio molto bello, dice "fate un podcast eccezionale" quindi chiaramente ha sbagliato il podcast a cui favo la domazione, "e ti stimo" credo si riferisca a Mauro "perché so bene quanto è complicato coniugare lavoro, passione, i doveri e i piaceri di padre.Ho aspettato anche troppo per supportarvi.Alla salute di Gitbar".Tony mi ha donato una cifra, tra l'altro gigante.Per noi lo ringraziamo enormemente e adesso mi metto i capelli lunghi e faccio Alessio e ricordo a tutti che potete donare e siete timidamente incoraggiati a farlo.Donate, donate, donate...Donate e donatevi! Donate e donatevi! A Gitbard si farà una meravigliosa festa sul catamarano di Gitbard che stiamo comprando proprio in questi giorni.Siamo in trattativa per comprare l'una rossa.La rossa che sarà l'una gialla, come i poveri.Voi non potete immaginare la gioia che ci date, soprattutto a chi porta avanti ogni settimana questo podcast, quando c'è una dimostrazione concreta di effetto.Se proprio guardate, se proprio sentite, mi state ascoltando e sentite che dovete fare qualcosa, sapete che è questo.Su TikTok e Tipeee voi seguite i vari link e ci sono.- Mi parlo anche io adesso la parrucca di Alessio.- E conducono il paese dei balocchi.- Ah, il paese dei balocchi.Sì, sì, sì, sì.Ho un libro e un blog che si chiama staffeng.com.È di un tizio che è estremamente bravo, che si chiama Will Larson, che nella vita ha fatto diverse cose, tipo che è quello che ha messo in piedi il team di SRE di Uber, quando Uber non aveva gli SRE, e ha questo blog in cui intervista gli staff engineer o comunque le persone che fanno l'individuo, il contributore a livello molto alto in aziende, molto fighe.E c'è un libro anche ed è molto bello perché fondamentalmente ti dice che cosa fa un tech leader.Ho anche un post molto bello di un altro grandissimo personaggione che è Gerge Biorost, che si chiama "What TPMs do", quindi "Cosa fanno i technical project manager", ed è bello banalmente perché c'è un diagramma di Venn, stupendo, in cui ci sono tre pallotti, che sono Building Software, Strategy and Alignment e People Management, che sono le tre cose che uno può fare in un team.E lui ti dice fondamentalmente che se le stai facendo tutte e tre, lo stai facendo male, perché non puoi fare tutte e tre le cose bene.Quindi se fai solo Strategy and Alignment, forse sei un Technical Program Manager, se fai solo people management sei un engineering manager, se fai solo building software sei un software engineer, il technical lead sta in una delle intersezioni tra queste ma non nelle intersezioni di tutte e tre.Impressivo, bello.Tutto è l'enote dell'episodio.Carmine? Certo.Io ne ho due, uno tecnico e uno no.Quello non tecnico, così me lo tolgo subito in realtà sto finendo di leggere in questi giorni, è "Il trionfo della stupidità di Russell".È sostanzialmente una raccolta di...saggi, sono articoli di giornale, praticamente, che sono stati scritti, insomma, negli anni '30.Ed è un libro divertente, diciamo, con la prossima frase, fa ridere, ma fa anche riflettere, insomma.e secondo me può calzare a pennello quello che abbiamo detto oggi.Insomma, abbiamo parlato di condizioni sociali, di tabù e di leadership e di percezione di quello che c'è intorno a noi.Insomma, quindi sicuramente un libro interessante che può essere più o meno calzato di quello di cui abbiamo parlato oggi.E l'altro invece è Essential Scrum, probabilmente sarà già stato nei balocchi di qualcuno, io in realtà lo sto leggendo in queste settimane, ed è sostanzialmente un overview del Frameworks RAM e secondo me, almeno io ne ho letti diversi, è quello che dà una panoramica, una cosa assolutamente generalista, ma che permette effettivamente...è quella cosa che puoi tenere sotto mano se ti sei dimenticato qualche concetto per assicurarti che hai effettivamente capito.Trovate tutto nelle note dell'episodio.Il formato Kindle, ve lo consiglio e non ve lo consiglio, compratelo cartaceo, sta un po' di più, ma in quel formato di Addison Wesley, con un livello legato con la copertina Rigidance.Io, visto il successo del cubo di Rubik delle scorse settimane, mi sento di consigliare un'app che ho scoperto in realtà, in realtà non ce l'avevo mai pensato, magari qualcun altro non l'ha mai pensato, esiste una, ne esistono varie, però ne ho trovata una che è carina che si chiama A-Solver, dove è appunto un'app per il cellulare, fai la foto alle facce del cubo e l'app ti dice come risolverlo, con il numero di mosse minore, quindi senza seguire un algoritmo particolare, non ho idea di quale algoritmo segue, in realtà non ci ho dormito per un paio di notti per cercare di capire che cosa, come facesse a farlo.Però, insomma, può essere carino, i miei figli ci perdono un buon paio di ore con un cellulare, questa app attiva.Un cubo qualsiasi, può essere sia il 2x2, che quello piramidale, che il 4x4, che il...non so come si chiama, quello esagonale, ottagonale, ok ne so io, e in più ti dà diverse combinazioni.È gratuito, a pagamento devi vedere delle pubblicità ogni tanto oppure paghi, un paio di euro mi sembra.Comunque, è carino.Se vi serve risolvere uno di quegli affari e non sapete come, volete tornare alla posizione originale, si può risolvere le sue problematiche.Siccome io non amo tanto la regola "don't repeat yourself" vi riporto il blog della settimana scorsa, "The Manager's Pat", un libro carino che mi ha aiutato a mettere ordine a una serie di esperienze che ho fatto, è scritto molto si legge piacevolmente ed è credetemi illuminante.Un altro libro che vi porto invece me l'ha ricordato il buon vecchio Eddie Osmani che di per sé è un balocco già lui proprio lui il suo account twitter è un balocco però qualche giorno fa ha tweetato condividendo il link per leggere online un altro libro che ho trovato altrettanto illuminante proprio nell'ottica di leadership e di 'ste robe qua che si intitola "Software Engineering at e vi condivido il link che il buon vecchio Osmani ha condiviso su twitter e che vi permette di leggerlo gratis.Buttateci un occhio perché ne vale la pena.Detto questo noi andiamo verso la chiusura, è stato un episodio lungo ma piacevole, ma non vi lascio andare, almeno non prima di aver chiesto a Carmine di alzarsi in piedi perché voglio fare uno screenshot alla maglietta e che vi voglio condividere perché prima io stavo ridendo e come uno scemo e poi siamo scoppiati tutti a ridere, ecco questo è il motivo per cui moriredo ma dove viene questa maglietta perché la voglio allora questa maglietta viene dal FOSDEM del 2020 ed è una maglietta che regalavano allo stand di Mattermost tra l'altro sperando che il FOSDEM l'anno prossimo si possa fare in presenza, è una manifestazione bellissima qui vi invito a partecipare se va tutto come deve andare potreste trovare anche me con una maglietta non come questa ma leggermente più verde e pensavo a questo.No, le davano allo stand, io ne ho prese diverse, hanno una qualità bellissima, non so dove le abbia prese, Mattrimost l'ho lavata centinaia di volte e non ha accusato colpo.Mi scuso con i ragazzi di Mattrimost che erano lì, Ne ho prese un po' troppo forse.Quindi non è che scolorisce, è che hai tante magliette e quindi le lavi poco perché...Assolutamente ne ho diverse, è stato tipo come con la scena di "Algorithm" in cui c'è Peter che prende i sample di cibo nel supermercato e ogni volta tipo va con una maschera diversa a prendere lo stesso sample.Naturalmente io senza permesso ho appena condiviso nel gruppo telegram la tua maglietta.Ah no no no assolutamente no detto questo e siccome siamo prossimi alle due ore io direi che alla prossima ciao ciao ciao GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.[Musica] [Musica]
