Siamo noi quelli che leggendo il codice cercano lo stronzo che ha scritto quello schifo, ma ahimè lo stronzo è mai medesimo e l'ho scritto giusto ieri.Siamo quelli che santificano il nuovo framework javascript preferendo segretamente jQuery, gli stessi per il quale il testing è importante, infatti la nostra codebase ha solo due test flakey pure.Siamo noi quelli che il tuo linguaggio fa cagare ma il mio è peggio.Quelli che la chiarezza nei comment message prima di tutto e dentro ce l'appella tutti i santi.Quelli che in call parlano per 5 minuti prima di accorgersi che il mic è muto.Quelli che non si può fare di default diventa velocemente un tutto è possibile se hai le risorse tempo e budget ilimitato.Siamo noi quelli che l'AI va regolamentata ma hai visto questo nuovo modello che disegnerà Tinifunambuli, quelli che il dipende e unisci gratis la prigione e quelli che la RAL...no vabbè fa già ridere così.Siamo quelli che fanno lo slalom tra le specifiche che cambiano costantemente, ormai rassegnati che la definition of ready è solo una più illusione.Quelli che si sentano dire "ho un'idea per un ed è subito l'ennesimo social come Instagram, ma meglio.Siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo al Gitbar e davanti a una birra tutto ci sembra un po' meno grave.Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Ho cambiato un po' setup e non sento una c...ah ok adesso è un po' meglio perfetto ho cambiato setup e quindi tutti i volumi tutte le cose sono la cazzo di cane però proveremo a portare a casa questa puntata anche perché ho un amico e un ospite speciale ma non ve l'anticipo prima ci sono delle cose da fare e da dire intanto gitbar lo potete trovare, raggiungere con i metodi classici mandandoci un'email che non funziona quindi non mandateci un'email perché ci sono problemi con i dns grazie a Rupa potete scriverci su su twitter @brainrepo oppure c'è il gruppo telegram cercate pure github nel vostro client di telegram preferito a parte questa abbiamo anche un canale youtube molto giovane ma dal quale potete riuscire a vederci e vedere le nostre faccione mentre parliamo e che altro.Diciamo che per adesso va bene così e passiamo subito a presentare il nostro ospite di oggi.Come vi ho anticipato, qua ai microfoni di Gitbar, questa settimana abbiamo un mio collega, un amico ma anche un esperto di un topic particolare che è l'engineering management.Abbiamo con noi Alberto Motta.Ciao Alberto.Ciao Mauro.Ciao a tutti.Come stai? Non c'è male.Dai, oggi è venerdì, la portiamo a casa questa settimana.E stranamente Maura arriva a rompere i coglioni il venerdì sera quando uno potrebbe uscire a bere una birra vera.Eccoci qui a bere la nostra birra virtuale, ma è un piacere averti davvero qua con noi.Tutto mio.Ti ho chiamato perché in realtà è da un po' di tempo che volevo affrontare qua a Gitbar un topic che è abbastanza complesso ma che ci tocca comunemente, cioè ci sbattiamo il muso pesantemente che è quello del engineering management.Quando c'è troppo, quando c'è troppo poco, quando c'è male e raramente quando abbiamo un engineering management che c'è bene ci rendiamo conto che stranamente le nostre performance crescono, la nostra psychological safety aumenta e tutta una serie di elementi a contorno.Per cui con te la prima domanda che ti voglio fare è, ancora prima di andare a analizzare il ruolo dell'engineering manager, come sei arrivato a diventare un engineering manager? Sapevo che sarebbe arrivata questa domanda, c'è stato tutto un piano diabolico alle spalle, mi piacerebbe avere un'ottima risposta, dire che c'era stato un career planning molto dettagliato, ben progettato, non è così, penso che in realtà per molti nel mio ruolo, in questo ambito in particolare, non sia così.Allora io parto da solo un ingegnere, in origine io ho fatto altro, all'università, ho studiato giurisprudenza, volevo fare l'avvocato da grande, poi quando ci ho provato ho scoperto che non mi piaceva per niente.Allora sono ritornato un po' all'università, ho fatto un breve corso al Poli e poi mi sono lanciato in questo mondo.E nel tempo, quello che è successo è che a un certo punto un'azienda mi ha assunto perché aveva visto un loro manager, aveva visto un mio talk e ha detto "Ah bene, tu hai già risolto un problema che noi abbiamo, vieni a lavorare con me".Io mi sono rappresentato il primo giorno in ufficio dicendo "Bene, sono molto contento di lavorare con te".Lui fa "Bene, però ho dato ieri le dimissioni, per questo una settimana me ne vado".E quindi mi sono tornato in questo team che non aveva più un manager, ho cominciato a lavorarci dentro e a un certo punto qualcuno mi ha proposto, ho detto "senti ma qui ci vorrebbe qualcuno che faccia un po' lo step up, che si occupi un po' del team adesso che quello che era il manager è andato via, secondo noi hai le carte in regola, ti rendeva di provare" e quindi questo è stato poi il mio inizio.Quindi in realtà c'è stata una crescita sul campo e qua mi viene la domanda subito dopo.Quando si parla di management quanto fa la crescita sul campo e quanto fa invece studiare? Nel senso quanti danni si possono fare sul campo senza aver studiato e quanto grossi? Allora, i danni si possono fare se hai studiato, se hai tanta esperienza.I danni si fanno sempre, io faccio danni tutti i giorni e lo ricordo al mio team con molta serenità tutti i giorni.Allora, l'esperienza sul campo penso sia molto importante.Il fatto che appunto parliamo di un ruolo che ha una connotazione particolare, cioè già il fatto che il nome non sia manager, ma sia engineering manager, dice qualcosa di particolare, di specifico del nostro ambito, in un certo senso.Cioè, normalmente un manager è un manager, quello è il suo lavoro.Quindi non è raro che certe persone, non parliamo della piccola media impresa italiana, però di realtà grosse corporei, conti nazionali, entri in un'azienda già con questo career path assegnato.Cioè, io entro in questa azienda perché farò il manager.Quindi, dal giorno uno sono dei manager, hanno studiato qualcosa di specifico, vengono affiancati a qualcuno e fanno un percorso per essere dei manager.Quindi sono delle persone che gestiscono cose e quindi questo li rende D'utile in un certo senso, adesso che sono, c'è questa visione per cui il manager si muove tra aziende che hanno magari, non so, dei settori completamente diversi.Quindi oggi sono il manager di un'azienda che fa il sapone e l'anno prossimo che fa il tagliaerba.Perché comunque sono un manager, il mio ruolo è gestire le risorse, ok? E far sì che tramite la gestione delle risorse io ottenga dei risultati.Nel settore tech c'è stata questa volontà di mettere un po' il puntino sulla E e aggiungere davanti quell'engineering, laddove io l'ho sempre letto così, cioè come quel manager che ha una base da individual contributor come software engineer.Quindi parti già dicendo, ok, team, so di cosa stiamo parlando, non sono, fino all'altro ieri non vendevo gli aspirapolveri, io sono uno come voi, sono uno di voi, sono qui con una funzione diversa.Quindi l'esperienza sul campo secondo me è fondamentale innanzitutto all'origine, cioè quella di avere comunque una certa esperienza come individual contributor.Poi possiamo discutere eventualmente quanta ne serve per essere efficace come engineering manager, però secondo me quello serve per questo ruolo specifico, proprio perché c'è questa connotazione particolare e perché è anche un'industria particolare con dei rapporti differenti, tendenzialmente gli ingegneri hanno un certo potere contrattuale, cioè sono delle figure molto ricercate, sono delle figure che quindi hanno bisogno di essere motivate, che sono coccolate dalle loro aziende molto spesso, comunque più o meno, poi parliamo di...Mi hai letto nel pensiero, ti giuro, mi hai letto nel pensiero.qualche anno sono calze, qualche anno sono felpe, però...Quindi, partire già con questa base aiuta.Quindi la prima base che è quella dell'individual contributor, quindi dell'estero ingegnere.E poi, allora, c'è un bel mix secondo me di studio, e quindi di...la dovere studio, secondo me, più che la teoria, è trovare quelle fonti che ti possono passare dell'esperienza.Quindi, libri, articoli, mentori, che ti possono aiutare a offrirti l'esempio di come affrontare certe situazioni.Perché ovviamente, mentre gestire il codice, le macchine, è abbastanza deterministico, ok? tendenzialmente, il codice dovrebbe sempre fare quello che una volta che l'hai scritto e se l'hai scritto decentemente così si comporta, le persone non sono così, le persone hanno un certo livello di random che è sempre interessante da gestire.L'hai detto in modo eccelso, io ci sarei andato con la zappa.Però voglio fare un passaggio indietro.Allora, il nostro dominio, il dominio del mondo tech e dello sviluppo software a maggior ragione, diciamo che ha proprio formalizzato l'esigenza di avere una figura manageriale che abbia un deep understanding di quello che è il dominio tecnico che si sta andando ad affrontare e questo ha evidenziato una mia bold opinion, infatti avevo già Massimo Boldi pronto da mostrarvi, cioè una parte è data dal potere contrattuale che gli ingegneri hanno oggi nel mercato e dicono io col management non ci parlo, al massimo posso parlare con un CTO perché lui almeno ne capisce, se poi c'è un engineering manager che gestisce anche quel pezzettino di people che serve, blocchettino di people, ecco il dialogo è più semplificato.E a questo si aggiunge anche la complessità della parte tecnica, cioè noi abbiamo bisogno di spiegare, trasformare i contenuti strettamente tecnici che hanno diversi livelli di profondità e di complessità in un modo diciamo più semplice da poter mettere sul tavolo degli stakeholder.Nel top management spesso questo viene fatto dal CTO però a livello di team c'è bisogno di una figura che in qualche modo faciliti.Io credo che questo succeda anche in altri domini.Penso all'ingegneria edile, non lo so.Ci sarà un qualcuno che semplifica il dialogo tra il committente e l'ingegnere? Chiederò a mio suocer che è ingegnere edile.Anch'io chiederò a mio fratello che fa l'architetto, faremo un follow up.Però in realtà mi chiedo proprio questo, se poi dovessimo guardare nella figura di questo ponte che è l'engineering manager, quali sono i suoi ruoli? Perché spesso è confuso col ruolo del team lead, è confuso col ruolo del product manager, spesso non ci sono dei confini così netti.Assolutamente.Allora, faccio uno step indietro.Secondo me una parte del ruolo nasce nel fatto che comunque l'esperienza un po' del mondo tech, come la conosciamo noi oggi, è stata molto formata nella controcultura della Silicon Valley, dove c'era un po' questa opposizione all'immagine tradizionale della corporate americana, ok? E quindi questo fatto, cioè la visione quindi del manager come figura che era un puro gestore, quindi poteva fare qualunque cosa, si scontra con questa visione un po' libertaria, un po' hippie, di quelli che dicono "non è vero, voi in giacca e cravatta di Wall Street non potete venire da noi a dirci cosa dobbiamo fare, perché noi sappiamo cosa vogliamo fare".Questa è un po' semestrata alla visione che mi sono dato io del perché, appunto, c'è questa peculiarità, perché effettivamente è una peculiarità del nostro settore o quanto meno.Probabilmente ci sono anche altre altre esperienze simili.Però io ti adoro quando dici così perché è un po' come dire avete un carattere del cazzo e quindi vi metto l'insegnante di sostegno a fianco per poter come un...lo hai detto in un modo così delicato! Non mi tiro indietro, non mi tiro...Quindi c'è questa cosa...Aspetta che ho perso il filo della domanda.Questa è l'età invece.No, tranquillo, dicevi della controcultura della Silicon Valley che un po' ha spinto questa...l'adozione appunto di questo tipo di figura.Certo, e per quanto riguarda invece la questione di cosa è dentro al ruolo, anche questo è un aspetto secondo me complesso in generale però di una figura manageriale, perché questo cambia da azienda a azienda, ogni realtà ha una sua struttura, quindi in base alla struttura il manager fa da collante tra gli strati, Quindi c'è un team che è una sfera chiusa e poi c'è un manager che connette il team con il resto dell'organizzazione.Quindi questo può voler dire che la connessione è puramente quella di qualcuno che deve ricevere un input e fornire un output, Oppure può essere che invece ci siano tutta una serie di fili da tenere, per cui c'è la parte di gestione delle risorse umane, che quindi si fa magari interconnessi con un dipartimento di HR, c'è una parte di sviluppo del prodotto, per cui può essere che, ad esempio, manchi un product owner, un product manager all'interno di un team, e quindi spesso capita che poi il manager, il nome è già lì, prodotto, project manager, engineering manager, fai un attimo il mix e dici va bene sei manager gestisci cose.Quindi c'è sempre un po' questa tendenza anche del ruolo ad adattarsi a quella che è la situazione e adattarsi soprattutto un'altra cosa molto fondamentale che è il team.Cioè il team che tu hai determina il ruolo che tu andrai a giocare.Questa è...Allora, premesso che...anzi, mettiamola così.Facciamo...Allora, mia bold opinion.Spesso, anzi troppo spesso, parliamo di ruoli e non parliamo di responsabilità e io mi sono un po' rotto le palle dei ruoli, piccolo rant serale del vecchio Mauro, tra l'altro con la camicia a quadri sembra davvero un vecchio Montanaro, parliamo troppo spesso dei ruoli e poco delle responsabilità e quello che tu hai detto casca a pennello, l'engineering manager è uno che gestisce cose con un background anche tecnico.Poi, come dicevi tu, a seconda del contesto si presta a risolvere problemi, a facilitare e quindi hai proprio introdotto il concetto del facilitatore, del servant leader.Come si può operare da servant leader? Questo è sicuramente una delle cose che personalmente mi stanno più a cuore.Cioè è un po' quando appunto mi è capitato di diventare un manager, ho facciato studiare e cercare di farmi un po' la cultura per non essere uno di quelli che avevo avuto io, che avevo magari odiato perché erano scarsi e non utili, era proprio questo di essere un servant leader, un facilitatore, un qualcuno che permetta al team di performare e quindi questo appunto viene ancora quello che dicevo prima, cioè quello che comanda il team, il materiale che tu hai è quello.È come essere un...io faccio sempre degli esempi sportivi, ogni giorno cambia lo sport, il mio team lo sa che ogni giorno ho uno sport che mi gira eccetera però tendenzialmente se tu sei un allenatore di un qualunque sport tu guardi le persone che hai e poi organizzi un sistema di gioco cioè vai a capire quali sono le mie potenzialità, quali sono i miei punti deboli e poi organizzo il team in modo tale da potenziare il più possibile le prime e coprirle più possibile gli altri.Quindi se io ho un team di persone che sono estremamente creative e molto poco rigorose, lavorerò sui processi per aiutarli ad acquisire tramite uno strumento esterno quel rigore che naturalmente loro non hanno.Viceversa, se ho un team che è estremamente rigoroso ma un po' schematico nell'affrontare i problemi, allora il mio ruolo sarà inverso, cioè dovrò cercare di rompere questi schemi il più possibile per trovare delle soluzioni originali e quindi andrò a lavorare invece con appunto, non so, dei workshop, di brainstorming con varie tecniche per andare a cercare di instillare questa non c'è nessuna creatività, ok? Poi ovviamente nessun team è mai così, è mai lineare, è mai fatta da persone tutti in un certo tipo per cui si tratta poi da poi di capire anche all'interno del team chi hai.Eh come in una squadra, non non tutti i giochi possono giocare in attacco, non ha senso.Tu hai gli attaccanti, i tuoi centrocampisti, i tuoi ai tuoi difensori e vai a capire ognuno in che ruolo può dare al meglio, in che ruolo può essere eh potenziato al massimo stai rappresentando un ruolo da regista fondamentalmente, da direttore d'orchestra di questa azione.Un ottimo esempio.Hai degli strumenti che in qualche modo condizionano, tentano il condizionamento di alcune attività, indirizzano più che condizionano le attività in una certa direzione piuttosto che in un'altra.E qua la domanda sorge spontanea.Io nella mia precedente vita ho gestito diversi team anche in domini che non erano in l'ambito tech, tra l'altro ringrazio i miei compagni di viaggio delle mie vecchie esperienze lavorative, Gianni e Gianna un abbraccio enorme.Ecco, in quel contesto io mi sono trovato davanti a un muro durissimo.Quando tu utilizzi questi strumenti per indirizzare, in stradare delle decisioni, il rischio di diventare il padre che tratta i membri del team come i propri figli o di diventare ancora peggio il burattinaio che governa e controlla profondamente le azioni, se stai facendo una cosa, ma indirizza ecco, nel senso di indirizzare profondamente le azioni, è un rischio che si corre.Secondo te esistono degli strumenti, delle azioni, dei metodi per contenere questo rischio? Sì, esistono.Innanzitutto bisogna rendersi conto di qual è il proprio ruolo, cioè questa è la cosa importante per chi si trova in questa posizione di potenziale potere, cioè di potenziale capacità di imporsi, quella che...il comprendere che imporsi di fatto quello che ottiene al massimo è di indebolire, di deoperare quello che è il team.Ho fatto un workshop qualche anno fa, mi è piaciuto l'esempio che tu hai fatto del direttore di orchestra, perché era proprio un workshop fatto così, c'era dentro un'orchestra, c'erano tutte le persone all'interno e ascoltavi l'orchestra.Il direttore faceva anche la parte di training, diciamo, e faceva praticamente vedere che l'orchestra è perfettamente in grado di suonare il pezzo se il direttore sta fermo immobile lì, non ne ha bisogno.La maggior parte dei team sono in grado di ottenere quello che è necessario ottenere senza bisogno di qualcuno che li tenga per la mano, per la manina, gli faccia vedere dove andare di qui, bisogna fare questo, bisogna fare quell'altro.Tendenzialmente se non c'è proprio una situazione di disfunzionalità grave, quindi ha bisogno di un altro tipo di cura, un team normale è in grado di portare a casa il suo sprint, il suo goal, il suo prodotto in maniera autonoma.Quello che deve fare dal mio punto di vista un manager è quello di aiutare il più possibile in questo percorso.percorso.Dove aiutare significa fare in modo che il team abbia i minori ostacoli possibili, che il team sia il più efficiente possibile e poi lavorare con l'individuo per tirare fuori il più possibile il loro potenziale.Guarda, mi ci sono rivisto al 100%.Io per anni ho suonato in una banda musicale ed eravamo tutti musicisti che, con lo spartito davanti sai quando e cosa deve fare e come lo devi fare e va bene, però avere il punto di riferimento là davanti del maestro che sai che c'è e che può succedere qualunque cosa e lui è là è completamente diverso, il famoso no, famosa cosa che sentiamo dire dagli engineering manager "no actions no blockers" che è lo stato migliore, quando la situazione del team viaggia sereno è tranquillo e sai che hai qualcuno, un servant leader là davanti che è pronto a rimuovere gli ostacoli e adesso a questo punto mi collego con un'altra parte che quali sono gli strumenti che noi abbiamo da manager per rimuovere gli ostacoli nel team.Io penso per esempio, te la butto così, penso per esempio a escalare, non so come si dica in italiano, ma escalare una certa problematica per facilitare il flusso.Ne esistono delle altre e magari possiamo approfondire anche l'azione dell'escalare.Certo.Allora, beh, questo è l'esempio più...che viene più evidente perché, come dicevamo prima, il team tende ad essere una sfera, un mondo perfetto e chiuso di se stesso, ok? Ha le sue dinamiche, il suo modo di essere e poi c'è il fuori, c'è...ci sono i draghi, cioè l'incognito e lo sconosciuto del resto della realtà, quindi...- "Exunt leones".- Esatto.- Quindi la funzione dell'essere un ponte, o l'essere un messaggero anche, tra il team e il resto di questa organizzazione, che spesso viene visto come "chissà quelli fuori cosa fanno", quello...il director of engineering l'ho visto una volta mangiava uno in sala mensa e cose così, scene fantoziane di questo tipo, immaginate, è proprio il caso più comune in cui un manager va a risolvere, va a rimuovere degli ostacoli, cioè si fa da tramite e crea relazioni all'interno di quella che è la struttura di una realtà.laddove dal mio punto di vista quello che dovrebbe fare è fare più che essere appunto lui stesso il tramite il messaggero dovrebbe fare tinder cioè dovrebbe abbinare le persone in modo tale che gli ingegneri parliano con gli ingegneri che lo stakeholder magari parli con gli ingegneri magari facendo facendo un pochino da filtro aiutando come facilitatore questo con questo questo dialogo.Spesso si dice, questo è un esempio che fanno spesso nel mondo Scrum, che il team parla il "geekish" e invece i stakeholder parlano il "businessish" e quindi uno parla il linguaggio del business e gli altri invece parlano il linguaggio tecnico.Quindi spesso quando si parlano non si capiscono perché parlando due lingue opposte che hanno, che essendo lingue sono strumenti per comunicare puntano a comunicare concetti che non non centrano niente uno con l'altro.Cioè da una parte si parla di "ah ma guarda però ho fatto dei test che sono perfetti, hanno coverage al 100% eccetera" dall'altra parte c'è qualcuno che dice "senti ma io devo vendere domani mattina sta roba qui, quanto lo facciamo al chilo?" Ok, quindi spesso queste due parti hanno bisogno di un facilitatore, ok? Nel mondo Scrum ti direbbero che dovrebbe essere il product owner.Non sempre è così facile avere dei product owner che sono empowered sufficientemente, quindi spesso il manager deve fare anche questa parte, di fare da facilitatore, da traduttore anche in alcune situazioni, per cui aiutare una parte a capire l'altra.Senza però, secondo me, in un certo senso, nascondere questo rapporto, Cioè, senza far finta che l'altro non esista, che sì, ci sono io e dietro c'è un mondo misterioso di, non lo so, scimmiette meccaniche che scrivo su delle tastiere.Cioè, ci sono delle persone, eccoli qua, sono loro, sanno fare un sacco di cose, sono bravi, svegli intelligenti, parlateci, capitevi, io sono qua per aiutarvi in questo.Pensavo una cosa mentre parlavi, fondamentalmente il ruolo spesso dell'engineering manager è anche quello di frontman in questi luoghi di frontiera comunicativa, ma quando si è frontman di qualcuno, ok? o di qualcuni.In qualche modo ci si pone come sostituto di quel qualcuno e immagino si debba avere una qualche credibilità da parte della persona che in quel momento, o delle persone, il team, che in quel momento stai rappresentando.E allora pensavo è come cazzo immaginati temp t0 entro in un team come engineering manager a parte il ruolo come cazzo me l'ha conquisto la credibilità all'interno del team bravo questo è un tema è un tema eccezionale e la credibilità secondo me è proprio è proprio quella connessione che ti connette tra il team e gli stakeholder perché ho visto dei manager fallire perché erano dei bravissimi manager col loro team e dei pessimi manager verso gli stakeholder.E visto che questo rimane un lavoro e non è un hobby, ma comunque è un lavoro per cui qualcuno decide di pagarti, significa che tu hai bisogno di avere questa credibilità da entrambe le parti.Cioè, qui tu devi essere un qualcuno che sia quelli sopra di te che quelli sotto di te.Sopra e sotto, vabbè, concedetemelo in questo momento per capirci una cosa all'interno di un'alberatura, ecco, e riconoscano questa capabilità.Come si ottiene questo? Trovando tutti i giorni, secondo me, tutti gli istanti, anzi, quell'equilibrio che va tra il perseguire l'obiettivo di business che si ha e prendersi cura del proprio team.Queste due componenti non sono necessariamente in contrasto, però è molto evidente che si muovono come in un'altalena, sono collegate.Per cui tenerle in equilibrio è quello che ti permette di ottenere entrambe le cose.Perché se tu vai a squilibrare questa cosa, lo puoi fare per qualche momento, però a un certo punto poi l'altalena va dall'altra parte e il rischio è quello che il tutto comincia a muoversi.Il tuo obiettivo è quello di tenerla sempre in quell'equilibrio precario, per cui tu sai che in in un momento c'è un bisogno di business specifico, c'è una difficoltà e quindi chiedi qualcosa di più al tuo team.Dici "ragazzi, c'è questa cosa per cui magari imponi qualche limite alla loro creatività, per cui so che ci sarebbe una soluzione fantastica per questo che voi state immaginando, però vi devo affermare, abbiamo bisogno di una soluzione con queste caratteristiche in questo tempo, ok? E questi sono i limiti che agli ingegneri proprio gli rodono cioè no io io se avessi il tempo di fare questa cosa in modo giusto come dico io sarebbe una figata così è una merda.E poi più senior sono e peggio è.Mamma mia più più ne sanno più vorrebbero sempre bollire l'oceano come si suol dire e dall'altra parte tu hai qualche volta quel qualcuno che ti spinge dicendo ci vuole dobbiamo avere questa cosa domani e tu devi dire no col cavolo perché il team già è esausto oppure siamo in una situazione in cui l'equilibrio è precario per cui mi spiace non possiamo farlo.Tu devi sempre mantenere questo equilibrio tra il punto per seguire quello che è lo scopo di business che è il motivo per cui qualcuno ti paga fondamentalmente e per cui paga tutto il tuo team.Da un certo punto di vista comunque rimane un modo per proteggere il tuo team, quello di far sì che loro siano utili all'organizzazione quindi che siano visti come un valore, un qualcosa su cui investire e dall'altra parte fare in modo che il team sia banalmente felice nello svegliarsi e venire a lavorare con te.Hai detto una cosa molto interessante, questo equilibrio lo si raggiunge con qualche interazione, lavorando sul team, lavorando sugli stakeholder.Pensavo però anche al t0, quando tu entri in un team.E ripensavo a quello che io ricordo ancora il giorno che ci siamo conosciuti, no? Quanto è? Un anno e mezzo fa? Qualcosa del genere? Senti, mi racchi.Se sei molto contento.E ricordo che dopo una preliminare chiacchierata, ricordo che eravamo nella lobby di un aeroporto, mi dicesti e lo dicesti praticamente a tutte le persone che erano là, per favore dedicami 15-20 minuti per fare una call e io ricordo che tu hai chiamato tutti e hai chiamato me e quei 20 minuti hai fatto tre domande e hai solo ascoltato.Quel passaggio, io in quel momento interpretava il ruolo del single contributor in un certo contesto, ok? Quel passaggio è stato da single contributor sufficiente per darti fiducia.Con quel semplice passaggio di avermi ascoltato ancora prima di aver parlato, tu ti sei costruito, almeno da parer mio, dal mio lato, una certa credibilità.Sai, tu prima hai detto "la credibilità la devi costruire con gli stakeholder, fondamentalmente col management e col team, ok? Ma sai il management è quello che ti ha messo là, quindi la credibilità ce l'hai out of the box, perché altrimenti non ti avrebbe messo là.Poi la perdi, rischi di perderla facile, ok? Però diciamo che credibilità a livello t0 in un modo o nell'altro riesce ad averlo tra virgolette.Sul team invece te la devi proprio costruire da zero e là è molto complesso per cui quel tipo di azione secondo me è stata è stata importante può essere un'azione che aiuta l'ascolto sincero per farsi un'idea e comprendere profondamente le esigenze dei membri del team.Però nel momento immediatamente successivo quando si entra a regime, per forza si pesta un merdone.E quindi come cacchio si fa il mistake management? Cioè il manager pesta un merdone? Come tutela la propria credibilità all'interno del team e all'interno del gruppo di stakeholder? Come lavora per fare crisis management personale? Guarda, da questo punto di vista io ho una risposta molto banale in un certo senso.Come insegna sempre un mio caro amico, un bravissimo sviluppatore con cui ho avuto la fortuna di lavorare, lui mi dice sempre "tranquillo, chi non fa non sbaglia".Avevo una versione pugliese che io non mi azzardo a ripetere perché verrei subito additato.Però il senso era questo, chi non fa non sbaglia.Per cui io sbaglio, sbaglio tutti i giorni, più volte al giorno, e ogni volta che sbaglio, semplicemente dico al team "ho sbagliato".E quello che faccio tendenzialmente è spiegare il perché ho sbagliato.Ho detto, questi erano gli input che avevo, ho fatto questa valutazione e ho sbagliato perché ho fatto questa cosa.Sarebbe stato meglio fare quest'altra.In alcuni casi dico, magari, purtroppo non avevo visibilità di quest'altro elemento che mi avrebbe fatto propendere di più per altra soluzione, oppure in qualche caso ho preso un rischio tra le due cose, mi sono basato sulla mia esperienza, e in questo caso ho commesso un errore.Onestamente dipende molto dal rapporto che tu hai con il tuo team, dal rapporto che tu hai costruito, il tipo di climatici è una certa realtà, perché poi ci sono tutti i fattori che ovviamente il singolo manager spesso è, comunque è un uomo solo, una donna sola in un mondo di altri attori quindi non influenzano comunque il team, eccetera.Però con questa trasparenza, secondo me, col fatto di spiegare che si possono fare degli errori, ottieni due cose.Uno, ottieni credibilità.Non ti metti a raccontare palle, a far finta di essere un superuomo che è un oracolo sceso dal cielo che ha sempre la verità in tasca, ma che sei uno che fa un lavoro, che cerca di farlo il meglio possibile, e che nel fare lo meglio possibile può commettere degli errori.Due, fai vedere al team che ammettere i propri errori e condividerli, e imparare i propri errori, è una cosa positiva, perché tendenzialmente come se lo fa la maestra, allora possono farlo anche gli scolari, si dice a casa mia, insomma.Quindi se quello che è lì che deve "giudicare" l'operato degli altri è il primo che non ha problemi e da ammettere di aver fatto degli errori, allora significa che lo stesso possono fare quelli che sono parte del team.Si sentono a volte un po' quelli sottoposti a un giudizio.Ok? Ovvio che qui rientra anche la parte engineering, cioè se tu sbagli il 10% dei casi, il 20% dei casi, perché la vita è fatta di errori, rischi, valutazioni errate, benissimo.Ovvio che se sbagli il 90% dei casi, probabilmente...No, probabilmente devi lavorare su te stesso, c'è un qualcosa che ti manca, probabilmente hai bisogno di fare qualcosa in maniera differente.Sì, pensavo proprio a quel tipo di situazione dove magari, giustamente, magari sei in una situazione di impasse, alla fine l'engineering manager o il team lead, il tech lead della situazione deve per forza sbloccare l'impasse e prendere una decisione e in un contesto dove le informazioni sono limitate può capitare che la decisione sia un lancio di un dado.A me è capitato.Le informazioni sono limitate, due soluzioni sembrano uguali, ci sono due fazioni nel team e tu devi smuovere la cosa perché quelli sono ingegneri, sono single contributor, sarebbero pronti a tagliarsi una mano per sostenere la propria tesi, me compreso.A questo punto come sblocchi l'empath? Alla fine dici "Raga, noi dobbiamo andare avanti, me ne prendo io le responsabilità".Andiamo avanti, prendiamo questa direzione.Ti capita l'ingegnere stronzo, e lo dico io, che una volta che la merda arriva nel ventilatore, arriva a te, manager, e dice "te l'avevo detto".Vedi? "Te l'avevo detto, se avessimo fatto come?" Come gestisci questa situazione? Che poi destabilizza, rischia di destabilizzare il team costruendo due fazioni facendo guelfi contro gli bellini? te l'ho detto che non sarebbe stata facile questa chiacchierata! è una di queste inquadroni in cui è molto difficile darti una risposta su due piedi proprio perché come dicevamo prima è una delle premesse che abbiamo fatto all'inizio se parliamo di codice tu hai sempre una certezza che l'esecuzione di un qualcosa cosa sarà sempre la stessa.Nelle motivazioni delle persone invece ci sono tante sfumature, c'è quello che ti dice una cosa così perché ti vuole stabilizzare, perché ti vuole rompere le scatole, perché non l'hai conquistato, perché non ha la tua fiducia, perché è uno che è così, perché è uno stronzo.Ho lavorato con gente che era semplicemente degli stronzi e non c'era niente da farci, purtroppo ci sono anche le persone così.E quindi lì si tratta di contenere la situazione.Come la contieni? La contieni se tu hai guadagnato credibilità col team, probabilmente col resto del team, cioè se è un elemento proprio che è totalmente opposto, che non vuole fare altro che romperti le scatole.A letto del fatto che un manager questa cosa deve gestirla, per cui avere un elemento nel team che destabilizza è un qualcosa che devi gestire in un altro modo, dopo eventualmente troviamo questa cosa.Ma in quel momento il modo in cui tu assorbi questa cosa è con l'accredibilità che tu hai costruito.Cioè tu l'accredibilità in un certo senso è come se fossi il tuo conto in banca, tu nel tempo ti sei preso cura delle persone, ti sei preso cura del team, hai fatto sì che loro fossero contenti, che performassero bene, che le persone al di fuori del team fossero contenti dell'operato di quel team e quindi hai accumulato credibilità.Capita un momento di difficoltà, se hai i soldi in banca non è un problema, cioè paghi.Ovvio che hai perso una quota di quella credibilità, la dovrai ricostruire facendo il tuo lavoro bene.Se tu non hai questa credibilità in banca perché non ti sei comportato bene col team, perché non hai curato i rapporti con il team, non hai curato la salute del team, a quel punto ti trovi che hai il conto a zero e ti arriva la situazione così e lì è facile che perdi il controllo della situazione.Chiaro, è praticamente il tuo jolly da giocare sul tavolo.Il jolly da giocare è quel, cioè tu nel tempo ti devi costruire la credibilità, la credibilità poi la spendi quando ti serve.Qualche volta devi dire "ragazzi fidatevi" ok? E magari qualcuno, diciamo, il rompiscatole ma che non è diciamo negativo in confronto, semplicemente è convinto che la sua idea sia migliore della tua e ci sta, è sacrosanto, cioè tante volte io devo fare una decisione e devo fare una decisione magari basando su dei principi che non sono quelli che gli ingegneri vorrebbero, perché devo dirgli magari "ragazzi questa cosa dobbiamo farla a debito, non possiamo farla bene come vorremmo" perché? Perché purtroppo ci sono dei...spesso il mio lavoro è dire agli stakeholder "no, non si può fare" però non è che posso sempre...se dico solo "no" a un certo punto mi dicono "senti, grazie, a rivenerci, quella è la porta" e facciamo un altro.Quando vi beccate uno che dice che vi fa fare solo quello, dice solo "sì" da una parte e voi dice solo "fate le robe in due ore perché bisogna farle di merda".Quindi tu costruisci la carità dicendogli "ragazzi quando si può fare le cose fatte bene, vi faccio vedere che le cose le facciamo bene".Quando però non si può fare, ve lo spiego e andiamo in un'altra direzione.Quindi io tutti i giorni devo chiedere agli ingegneri di fare qualcosa che non vorrebbero fare, però Però perché lo fanno, perché mi seguono? Perché gli ho fatto vedere che, uno, perché sono stato trasparente nella richiesta, due, perché gli ho fatto vedere nel passato che le scelte che faccio non sono votate a metterli in difficoltà, ma a cercare di fare, di ottenere il massimo possibile da quello che è il goal del team, fondamentalmente.Quindi questa credibilità tu la costruisci giorno per giorno.Qualche volta devi accettare che si riduca per poi la ricostruirla.se tu giochi sempre a ridurla, a un certo punto il team non ti segue più e quindi poi dopo cominciano i problemi veri portatore sano di pragmatismo pragmatismo è l'unica vera incertezza della vita pensavo una cosa in realtà quando mi è capitato di gestire team abbastanza interessanti con persone anche fortemente opinionate io una delle cose che facevo è definire i principi ancora prima di partire.Uno dei principi fondamentali e condizione sine qua non per far parte del team era che qualunque decisione che il team prende, sia essa guidata dall'engineering team manager o guidata da un ingegnere specifico, è una decisione del team.Se questo è definito come principio e la decisione è formalizzata, io sono un amante degli ADR per esempio, perché formalizzano la decisione e il team lo sottoscrive, tutti i membri di un team devono approvare l'ADR, ok? Stando proprio a quel principio.Se hanno qualche cosa da dire la possono scrivere nei commenti, però comunque una volta che le diaree, let's say, mergiata, a quel punto è una decisione del team e in quanto tale, qualunque membro del team, anche se sbagliata, dovrà difenderla a quei denti.Se questo è il principio di partenza, ci rendiamo conto che le nostre posizioni individuali lasciano spazio a una posizione collettiva che è molto più proficua anche se punta nella direzione sbagliata e paradossalmente più produttiva della posizione individuale perché anche se puntando nella direzione sbagliata svilupperà una conoscenza condivisa all'interno del team che ha comunque il suo valore e vale molto di più della conoscenza individuale di uno dei membri del team.Scusa ma io mi riscaldo parecchio quando...Questo è assolutamente vero.Faccio uno step in più.Ogni team, come abbiamo detto, è un mondo a parte, ok? Quando tu nel team hai la fortuna, perché è la fortuna di avere persone opinionate e competenti, ok? Perché ci sono le persone opinionate e incompetenti, più pericolose che puoi avere, ma quando hai la fortuna di avere delle persone opinionate e competenti, quello che deve fare l'engineering manager è secondo me l'empowerment di questo team.Cioè, laddove tu hai le risorse, tu devi in un certo senso lasciarli fare, fare un passo indietro.Questo ti dà due grossi vantaggi.Il primo è quello che appunto il team si sente potenziale, si sente nella posizione di decidere per sé.Quindi non si verifica quella situazione in cui a un certo punto tu devi dirimere la situazione, perché tendenzialmente quando le persone sono messe nella condizione di essere padrone proprio destino, cioè dire ok, allora per questa cosa io spesso quello che faccio è per ogni progetto, non so, ogni epica, ogni situazione un po' più complessa delle semplici task, dico allora per questa cosa a rotazione, ovviamente magari coinvolgendo prima i team più senior del team e poi man mano proestendendola anche a quelli che magari sono un pochino meno senior, senza, ovviamente anche qui, ogni team ha le su dinamiche, dico "ok, guarda, per questa cosa qua tu sei responsabile".Quindi ognuno di loro si trova in una situazione di dire, di prendere decisioni, di essere, di dover gestire.Il membro del team arrembante dice "no, guarda che però dobbiamo farla così, non ascoltare gli altri, fidati, ascoltami, bisogna farla così".E quindi tu potenzi il team, dai a tutti la possibilità di vedere queste cose, dai a tutti la possibilità di capire qual è la complessità di prendere delle decisioni.E poi l'altra cosa che ti dà è quella possibilità di fare un passo indietro e di allargare lo sguardo.Cioè, quando tutti sono concentrati sul dettaglio, perché sono lì che discutono, eccetera, della cosa piccola, che stanno risolvendo il singolo problema, tu fai un passo indietro, guarda se tu sei per l'ampio e guardando questo poi sei quello che quando il team ha bisogno sta dando direzione perché quello che succede quando le persone si concentrano su un problema è che il loro sguardo si restringe.Quando tu potenzi il tuo team per dirgli risolvete voi il piccolo che allo sguardo di insieme ci penso io, il team si fida a un certo punto, anche a dire siamo indipendenti nel risolvere una serie di problemi perché abbiamo anche la tranquillità che c'è qualcuno che ci guarda alle spalle, c'è qualcuno che fa in modo che nel risolvere questo problema non ci perdiamo quello che è l'obiettivo finale.Sì, anche perché poi quando ci verticalizziamo tecnicamente è facilissimo, proprio per un parola di carico cognitivo, perdere la visione insieme.Poi gli ingegneri non sono mai pragmatici, la maggior parte degli ingegneri non sono mai pragmatici, cosa che si scontra sempre con la mia massima di prima, cioè che l'unica certezza è il pragmatismo.Esatto.Nel team ci possono essere...il conflitto può accadere, a quel punto va gestito.Alcuni elementi del conflitto spesso vengono specie in team un po' sbilanciati, vengono da quello che quelli bravi chiamano l'alpha geek factor, cioè il super performing ingegnere, super bravo, 10 per, 15 per, 25 per, quello che è visto che stiamo moltiplicando i numeri sono gratis, che in qualche modo destabilizza con magari l'iperperformazione o lavorando la notte o facendo...destabilizza l'equilibrio del team.Come si gestisce questa situazione senza frustrare questo elemento del team che in realtà è veramente produttivo? Allora c'è un bell'articolo di qualche che io rileggo ogni tanto a giro, che si intitola, traduco un po' alla spicciola, "ho licenziato il mio migliore ingegnere e non ho mai fatto una scelta migliore", nel senso, ci possono essere degli eccellenti solisti, ok? ma nessun solista, nessun elemento del team è mai più importante del team, per quanto performanti, per quanto eccezionali.Il rischio di queste persone, se lasciate nel loro brodo e in questa aura di superiorità, è quello che diventino veramente degli elementi di tossicità all'interno del team.Tanto che mi è capitato più di una volta di essere in questa situazione, cioè di dire c'è una persona che singolarmente è il top performer del team, magari o comunque uno il top performer del team, ma il loro comportamento fa sì che il resto del team performi al 50% e che eliminando quella persona dal team, il risultato finale sia stato quello di un team che nella sua globalità performava molto di più e perforava molto meglio.Quindi l'obiettivo è cercare di non arrivare a quella situazione, di mettere le persone davanti alle responsabilità delle cose.Quello che dicevo prima, nel momento in cui tu lasci che Rick, in quell'articolo lo chiamano Rick, prendendolo da Rick Morty, quindi il genio pazzo.Quindi se tu prendi Rick e lo lasci fare per i fatti suoi, che quando prende una cosa va per la tangente.E' quello che dice "allora dovevo fare questa cosa qui, erano quattro righe, però in realtà ho riscritto sette parti del coso e ho trovato una soluzione fichissima a questo problema".La tendenza potrebbe essere quella di dire "io di questa persona ho bisogno, perché è un genio, perché è bravissimo, perché figurati tutti quegli altri non saranno mai in grado di concepire questa cosa.La realtà è che chi se ne frega nella maggior parte dei casi? I geni? Sì, sono utili in alcune situazioni, ma se non sono incanalati nella maniera giusta e se sono peggio ancora delle persone che non vogliono essere incanalate nella maniera giusta, che non vogliono essere dei membri del team, ma vogliono fare i veneziani che prendono la palla sulla tre quarti e provano a far maradona, poi è un problema.Perché uno perché devi essere poi maradona per metterla dentro, toccando la tre volte e facendoti tutto il campo per far gola all'Inghilterra.Per cui spesso poi queste persone lasciate da sole, senza un controllo, quello che tendono a fare è tendere ad abitarsi su loro stesse, a creare sempre più problemi inesistenti e a risolverli sempre più loro, fino a che di fatto tutto quello che esce dalla loro mente è solo un riflesso della loro complessità e che il resto del team non è in grado di gestire, quindi diventa sempre più un rapporto di dipendenza anche.Non bisogna dargli l'opportunità di fare questo.A qualche modo bisogna anche essere chiari e duri nel dare un feedback alle persone.Cioè hai fatto una cosa che anche è interessante, è fatta bene, ma non era quello che ci serviva.Non hai fatto un buon servizio al team.Cioè mettere davanti le persone davanti alla realtà dei fatti e non coccolare quelli che sembrano fenomeni è necessario.Se non lo fai, il rischio non ti trovi.A me per fortuna non è mai capitato di essere quello che ha causato la megalomania, ma quello che l'ha ereditata.Ma la soluzione in tutti i casi è stata quella di spostare questa persona, spostarla dai team o salutarla dall'azienda.Perché? Perché si creano dei circoli viziosi che non possono far altro che portare alla risoluzione del team.La risorsa è il team, le persone sono parte del team, le persone hanno un valore intrinseco, ma quello che porta valore al business è il team.Sì, sì, sì.La somma delle parti è più della somma stessa delle parti, come dici, giusto per parafrasare.Se non lo è, è un problema.Cioè, è un problema.Se tu hai sette ingegneri in cui solo uno ti performa e gli altri sei no, sei davanti a un problema perché non è possibile.Il 10 per secondo me non lo so, adesso c'è sempre la discussione esiste o non esiste, non mi interessa neanche.Il punto è, quello che mi interessa è avere un team che, dato un gol, sia in grado di raggiungerlo.Tutto il resto sono cose che sono segmentali, personali delle persone.Contento per voi se volete farvele, ma a me non interessa.Alcuni, un po' di letteratura in giro dice, mi è capitato di leggere adesso non mi ricordo dove esattamente, ma l'ho letto qualche anno fa, si diceva una delle tecniche potrebbe essere provare ad assegnare delle responsabilità di buddy a questa figura overperformante per per metterlo fuori dalla sua zona di comfort è canalizzare tutta questa esuberanza, tutta questa energia in qualcosa che sviluppa il team.Io su questa cosa ho i miei dubbi, nel senso che alla base c'è comunque un problema di comunicazione e assegnare una responsabilità così grande a un membro che è palesa dei limiti di comunicazione, perché spesso l'overperformance accompagna con dei problemi di comunicazione.È rischioso, ecco, io mi preoccuperei un po' nel fare questo tipo d'azione.È sempre una di quelle cose che rientrano nell'ambito dei rischi e di correre.Cioè, è evidente che se tu hai un ottimo strumento saresti uno sciocco a dire "No, io per partito preso non lo uso".Cioè, se ho il cortello più affilato e devo tagliare qualcosa, è evidente che ho un vantaggio in quello.Però se il fatto di avere un membro del team così performante poi va scattato dal resto del team, è lì che ho il problema, è lì che ho perso.Dipende dalla persona.Cioè, ci sono delle persone che hanno un carattere di merda e devono lavorare da soli.Riconoscerlo è l'unica cosa che puoi fare, dirgli "guarda, tu non vai bene per lavorare in un team".tutti sono in grado di lavorare in un team.Ci sono persone che non sono in grado.Fate gli spike.Fate e trovatevi una realtà in cui siete da soli, perché quello è il vostro ambito.O andate da uno psichiatra, da uno psicologo e lavorate su voi stessi, perché magari ci sono dei problemi che io non posso venire a risolvere tutti i cazzi al lato, come vi Posso aiutarti, spero di poterti aiutare, però alcune cose sono al di fuori delle mie potenzialità e del mio ruolo.Come si dice "psychological safety" ma non "psychological therapy".Altri invece hanno solo bisogno di essere canalizzati bene, di dargli delle responsabilità.Un esempio, un trucco abbastanza semplice per canalizzare bene quelli che sono fondamentalmente delle persone positive, ma magari molto introverse, quindi che tendono ad essere un po' micragnose nella fruttare le cose, è farle investire molta parte del loro tempo nel mentoring dei più giovani o di quelli meno portati.All'inizio piccheranno i piedi per terra, dovrai essere brava anche tu nel scegliere chi aiutare, perché dovrai scegliere qualcuno che abbia l'intelligenza emotiva di capire con chi sono in relazione, per cui di capire che è una persona che all'inizio farà fatica e sarà un pessimo maestro, specialmente nelle prime fasi.Però quello è un buon metodo assolutamente che aiuta alcuni a uscire dal loro guscio, perché poi la soddisfazione del crescere le cose è uno di quelle esperienze che danno soddisfazione.Cioè è il motivo per cui la gente fa l'orto o coltiva le piante in casa, compra gli animali, fa figli, cioè è il crescere, è il senso di aiutare un qualcos'altro a diventare grande.Comunque è un'esperienza umana genericamente positiva e quindi questa è una di quelle esperienze che possono aiutare quelle persone che hanno già una loro positività di fondo a tirarlo fuori.Chiarissimo e adesso altra domanda difficile e invece con i low performer come ci muoviamo? Con i low performer la regola è sempre quella totale trasparenza cioè ai low performer si dice prima di tutto in faccia e senza troppi giri di parole "Kikko non va bene non stiamo andando nella direzione giusta" poi si cerca di capire il perché.Quindi è quello che dicevi tu prima, ascoltare, cioè, trasparenti nel dare un feedback, non sta andando nella direzione giusta, queste sono le cose che non vanno bene.Chiaro, queste sono le cose che non vanno bene.C'è qualcosa che ti sta limitando nel tuo performance? Può essere che qualcuno dici "guarda, tutte le volte che "Tu non ci sei", "C'è Carmelino che mi tira i capelli", "Ah, ok, va bene".C'è una situazione nel team che spesso, quello che capita tante volte, è che comunque tu hai una visione del team, ma non sei un visore onnisciente, sono delle dinamiche che avvengono al di fuori del tuo raggio d'azione, per cui hai bisogno di capire anche certe situazioni, perché qualcuno si trova in difficoltà.Può non dipendere da loro, può dipendere da loro.E quando dipende da loro, quello che devi fare è mettere davanti la situazione e capire una cosa fondamentalmente.Ce la possono fare? Cioè questa persona può essere messa nelle condizioni di avere successo? Perché quello che può essere semplicemente che hai sfruttato con la persona sbagliata banalmente oppure hai messo...c'è una persona fuori ruolo, se tu prendi un portiere e lo fai giocare a punta tendenzialmente non performerà bene e se tu hai preso un portiere convinto che fosse un attaccante forse sei tu che hai fatto lo sbaglio di ammetterlo.Quindi la prima cosa da chiedersi è "ok, questa persona è in difficoltà, è una persona che però ce la può può fare? Sì, benissimo.Cosa possiamo fare? Come io posso aiutarla ad arrivare a quello che è il livello che io mi aspetto, il potenziale che io leggo in loro? E poi, dopodiché, dipende molto dai problemi che ci sono.Cioè, può essere una logica di mentoring che puoi fare tu, che puoi far fare a uno dei tuoi ingegneri più esperti.Può essere che ci sono dei diversi che devono essere gestiti magari con l'aiuto di HR o con un mentoring di un altro tipo, magari un mentoring più sulla comunicazione, perché spesso una grossa parte dei problemi sono problemi di comunicazione, spesso non tanto tecnici, perché quelli tecnici tendenzialmente uno poi impara.La comunicazione invece è sempre difficile.Sì, perché non è binaria quella, è ricca di sfumature.Cavolo, io ho 70.000 domande.Comunicazione.Quando si parla con le persone, e tu sei un engineering manager e lavori in inglese, da non native speaker, e lavorando con le persone dove le sfumature contano, difficoltà nel piegare la lingua per passare alcuni gradienti, alcune sumature particolari, per, che ne so, underperforming, direzionare il carico emotivo di quello che stai andando a dire? Assolutamente, assolutamente, nel senso io ho una proprietà della lingua inglese buona, diciamo, ok? Lo sai, insomma.Forse anche più che buona, ecco.Però non è la mia lingua nativa.Poi io sono una persona molto verbale, anche, e quindi questa discrepanza tra quella che è la mia capacità verbale nella mia lingua e quella che è in inglese comunque la vedo.Tanto che sono famose certe mie traduzioni letterali di modo di ritaliare, tipo "ci vado con gli stivali di di piombo, c'è voluto un po' per spiegare perché "entering with the bootlegs", no, "the lead boots" aveva senso nella mia testa, e tutti quelli che mi guardavano dicevano "che cazzo dice questo?" Però l'ho spiegato e anche gli americani a un certo punto hanno detto "sì, infatti l'ho capito".Di sicuro, di sicuro c'è bisogno di impegnarsi su questo.Certe sfumature io non riesco ancora ad oggi, nonostante siano ormai almeno sei anni che lavoro esclusivamente in inglese, a darle e se mi credo di lavorare con qualcuno di italiano faccio meno fatica.È una questione di impegno però, è una questione di pratica, è anche di, secondo me, semplificare, togliere.Cioè se in italiano, dove io ho padronanza totale della lingua, perché è la mia lingua, posso permettermi di usare dei cosiddetti più complessi, eccetera, sull'invece punto all'essere essenziale, cioè a rendere un concetto il più semplice possibile, in modo tale da non lasciare dubbi.E questo è assolutamente sposabile.Io l'abbraccio in tutto anche perché il mio inglese è orribile, quindi soggetto, verbo, complemento mi ha sempre tirato fuori dalla merda.Però mentre parlavi, io ho introdotto la domanda parlando sempre di underperformers.Mentre stavi parlando Risalita Galla un'altra domanda sui underperformers.Abbiamo quelli underperformers.Ah sì, underperformiamo.No, noi abbiamo parlato della comunicazione, quindi comunicazione di crisi in questo caso, con l'underperformer.Ma come comunichiamo in caso di un elemento underperforming col resto del team? Come gestiamo lo squilibrio dall'altra parte? spesso si si parla di comunicazione di crisi parlando con la persona strettamente interessata ma poi l'engineering manager si trova anche a gestire l'altro lato per cercare di tenere tutto in equilibrio almeno in quella fase.Allora tendenzialmente il team non ha bisogno di sentirsi dire guardate che Alberto è un underperformer, ti hai il team e tu te ne accorgi per ultimo tendenzialmente.Prima che lo sai tu se ne sei accorto tu, anzi probabilmente nella maggior parte dei casi qualcuno te la dà il tuo feedback diretto perché quello che tu fai quando non sei sulle cose è il fatto che ti devi fidare delle persone con cui tu lavori per cui tu costruisci dei rapporti di fiducia e magari dici "senti Mauro è arrivato tizio questa settimana "Fai pairing con lui", così mi dai un feedback iniziale su come se la sta cavando, eccetera, mi fai un po' da buddy e nel frattempo mi dici anche però come siamo, siamo allineati su certe cose, eccetera.E quindi tendenzialmente il feedback, il primo feedback ti arriva dal team sull'underperformer, per cui il team lo sa.Anche qui è una questione di fiducia del rapporto tuo e il carattere col team, Cioè, come gestisci gli underperformer? Come hai dimostrato di gestire gli underperformer al team? Gli gestisci nascondendo la palla sotto la sabbia, lasciando che il team si smazzi il surplus di lavoro che è causato dal fatto che qualcuno non fa il suo? Puoi farlo, però poi il team non si fida di te.lo fai, cioè in un certo senso accettando questa cosa, quindi non vuol dire che ti metti davanti al team e dici "allora ragazzi, Alberto è una capra, bisogna sopportarlo".Ovviamente lo farai con delicatezza, magari durante i one on one dici "guardate, c'è una situazione in cui abbiamo una fragilità in questo momento, stiamo lavorando per risolverla, Alberto in questo momento è è entrato nel team da poco, ci siamo accorti che probabilmente non è super allineato con quelle che erano le nostre aspettative, per cui stavamo facendo un certo lavoro.Coinvolge alcuni membri del team in questo lavoro, in modo tale che non è più un qualcosa che il team subisce, ma è un qualcosa che il team partecipa, per cui dici "guarda, Mauro, fai paren con Alberto, per favore, anzi, facciamo un piano in cui io, te ed Alberto ci mettiamo lì, facciamo un piano perché queste sono le cose che lui deve imparare e che tu devi aiutarlo ad imparare in questi tre mesi.Il team a quel punto capisce che c'è una complessità, c'è una persona, un membro del team che è in difficoltà e che deve essere aiutato.Il team deve avere la fiducia, perché tu gliel'hai trasmessa, che tu farai le scelte giusto per il team, quindi saprai dire al team "investiamo su questa persona", fatica perché comunque è fatica, perché ce la può fare, oppure che saprai prendere la decisione più antipatica, più schifosa che c'è da prendere quando sei un manager, cioè dire a qualcuno "non ce la facciamo, non siamo in grado di arrivare al livello che ci aspettiamo, per cui non puoi fare parte di questo team".che fa schifo, cioè proprio...allora poi ci sono quelli che sono delle brutte persone e si divertono, io ancora oggi quando mi capita di farlo, fortunatamente non di frequente, però capita ed è una delle parti del lavoro, cioè devi dimostrare al team che lo fai, che quando serve fare anche delle decisioni difficili, fastidiose, perché dal mio punto di vista sarebbe molto meglio dire "Tim, ve la smazzate voi, io non ho voglia di andare in faccia a dire a Mauro "Mauro mi dispiace, questo è il tuo ultimo giorno qui", perché comunque è un fallimento, è un fallimento tuo, vedi il fallimento che che quell'altra persona deve affrontare, quindi è comunque una situazione sgradevole di per sé, però purtroppo devi anche dimostrare di essere una persona che queste decisioni difficili e sgradevoli è in grado di prenderle quando serve.Chiaro, sono super-iper d'accordo.Abbiamo parlato di over-performer, di under-performer, Adesso parliamo di composizione del team.Quando gestivo i team, costruivo i team, uno dei problemi che ho avuto, specie in giovane età, era quello di cercare elementi che si assomigliassero il più possibile a me.Questo è un rischio che capita quando componi il team, no? Specie se sei immaturo come manager.come si gestisce questa fase? Perché fondamentalmente, per esempio, immagina che tu hai una certa seniorship ok? e se approccia questa cosa in un certo modo rischi di dire "no, questo è meno senior di me, forse non lo metto nel team" quando invece potrebbe essere l'elemento giusto nel team perché quello che ti smazza lavoro senza discutere troppo e senza accelleggiare su ogni angolo, per esempio.Adesso sto banalizzando, però in realtà un problema nella selezione dei membri del team, uno dei problemi più comuni è quello appunto di cercare di assumere o di ingaggiare persone almeno pari a te.Quindi come lo gestisci questa tendenza? Allora, io ho avuto una fortuna che è derivante del mio percorso, cioè che quelli simili a me non c'erano.Cioè il mondo tech è un mondo abbastanza omogeneo, in cui comunque trovi persone...Adesso più passa il tempo, più per fortuna questa omogeneità si va un po' diluendo.Però c'è comunque tendenzialmente quelli che fanno...o che vent'anni fa facevano ingegneria informatica, specie magari nei nostri video, ma non un po' una certa forma mentis.Io ero quello diverso, io ero quello che non aveva fatto ingegneria, che non aveva fatto...l'ho sviluppato tutta la vita, avevo fatto tutt'altro, fino all'altro ieri andavo in ufficio in giacca e cravatta.Adesso la gente, la volta che mi presentavano in ufficio in camicia, mi dicevano "Oh, c'hai un colloquio!" e mi trattavano male perché non avevo una felpa col cappuccio.Adesso ce l'ho, la felpa col cappuccio, mi sono adeguato col tempo.però all'inizio non ero abituato, io ero abituato a dare del lei al mio capo, mettevo la giacca e la cravatta, sempre un po' amodino.Per cui ho avuto questa fortuna in cui non ho dovuto fare quel passaggio, non c'erano quelli uguali a me, per cui quello che dovevo prendere e quello che mi era evidente però sempre era quello in cui mi mancava.Io imparavo in fretta, ho sicuramente avuto tanti pregi, se no non avrei fatto quello che ho fatto, però mi mancavano delle basi solide su certe dinamiche, cioè tante cose me le studiavo, mi sbattevo, mi svegliavo alla mattina alle 6 per avere due ore prima del lavoro per studiare cose, per fare corsi, eccetera.Però una certa forma mentis ci vuole del tempo per acquisirla.Quindi quello che io cercavo di fare naturalmente era prendere nel mio team tutti quelli che coprivano i miei gatto.Qualunque cosa che io sapevo di non essere bravo a fare, cercavo uno che fosse molto bravo a farla e lo prendevo.Quindi questo è sempre stato il mio approccio, dovuto a me, alle mie insicurezze, alle mie mancanze.Quindi nell'accettare questa cosa, quello che facevo era proprio andare a cercare "ok, cos'è che non so fare io? Questo".Ok, lui è la mia persona.C'è una persona che ho assunto tre volte, in tre aziende diverse, era il mio esatto posto e quindi mi aiutava in una serie di cose dove io sapevo che avrei fallito, quindi tante volte io sarei andato in una direzione e dicevo per me tutti devo parlare con il mio amico qua, non faccio sto nome perché sennò poi si imparazzo, perché sapevo che se lui era d'accordo con me allora vuol dire che andavo nella direzione giusta, se lui mi guardava dicendo "Mh, non sa", allora il mio obiettivo diventava "devo convincerlo".Se riuscivo a convincerlo e mi accorgevo...perché a un certo punto poi entra...cioè quella...si supera il fatto di essere vicino ai colleghi, ma c'è un rapporto umano che ti fa capire subito se lo ho convinto veramente o "no, mi stai dicendo no per cortesia".Quindi se io vedevo che lui mi diceva di no per cortesia a un certo punto, capivo che stavo andando in una Quindi, non ho avuto questa esperienza, ecco, per me è stata esattamente una cosa, forse è stata una delle mie fortune, ecco.Però sì, assumete solo persone che non esattamente...cioè, se voi sapete già fare una cosa, non vi serve quella cosa, siete già bravi voi.Se voi siete i più bravi del mondo a fare gli stream di node, non vi serve a niente assumere Matteo Collina, che è probabilmente un pochino più bravo di voi, però Se siete lì, se ve la giocate, vi serve assumere qualcuno che vi insegna una roba che voi non sapete.Sì, cercare l'equilibrio anche in quel modo.Io ho visto che siamo a un'ora e venti, quindi in realtà, ultime due domande...Vedi che vuole il tempo, voi, quando si chiacchierate di queste cose? Poi non sto proprio lì, scusatemi.Stai parlando con quello conciso, tra l'altro.- La situazione pratica.- Abbiamo registrato quasi 300 ore di podcast in un paio d'anni, quindi vedi un po' te.No, come cazzo lo misuri il tuo lavoro? - Il mio lavoro? - Il lavoro, come si misura il lavoro dell'engineering manager? - Non ne ho tanti idea.Onestamente, baso Allora, io sono costantemente in preda a una certa sensazione di dire "Boh, oggi mi sembra di non aver fatto niente, di non aver ottenuto niente, passata una giornata", a pirlare in giro tra meeting, a discutere di questa cosa, a cercare di risolvere un altro problema e alla fine non ho ottenuto nulla.Tendenzialmente penso che è una percezione che molti che cominciano a fare il manager quando prima facevano l'individuo contributore hanno e forse poi ne dovrò un sacco di tempo perché comunque quando sei un individuo contributore hai una percezione molto più netta di quello che hai fatto ok cominciate la giornata il tasto blu per fare download non c'era adesso c'è e quindi ho fatto questa cosa è misurabile puoi farlo vedere puoi farlo vedere la tua moglie quando devo dire a mia moglie cosa ho fatto la sera a volte "Boh, non ho fatto niente in realtà, mi sembra".Quindi ho imparato col tempo a basare tutto sul feedback che mi davano le persone sopra di me e sotto di me.Se vedevo che le persone intorno a me erano felici, mi dicevano "stai facendo un buon lavoro", mi rassereno in questa cosa.Ho rinunciato a capire quando sono veramente positivo, ma mi baso su il feedback degli altri.Sì, in realtà un dato quantitativo, come dici, è sempre difficile da rappresentare quando tu fai un lavoro di questo tipo.Un dato qualitativo però emerge almeno nel medio periodo ed è per esempio il numero di blocker o la qualità dei blocker che scende e arriva al team se tu sei un bravo filtro e li risolvi vedrai che proprio a livello qualitativo i blocker si riducono la dimensione dei blocker si riduce il team impatta meno quei blocker la stessa cosa è la comunicazione però in realtà una metrica specifica è difficile da gestire e questa cosa nasconde, e con questo ci arriviamo a chiusura, questa cosa nasconde un grande grande tranello, un grande rischio e il rischio è quello della valutazione del proprio successo personale.Quando si diventa manager, e questo io l'ho imparato a mie il successo personale è uguale al successo del team.Se il team ha successo, quello è un tuo successo.Qual è il problema? Che comunque siamo anche delle persone che hanno delle ambizioni.E il rischio più grande che si nasconde nel dire "il successo del team è anche un mio successo, essendo un facilitatore è anche un mio successo", il rischio è quello di la soddisfazione del successo al team.Capita spesso che il manager si intesti dei meriti che in realtà sono meriti collettivi, condivisi ed essendo facilitatore lui una parte, il collante e l'olio che fa funzionare la macchina, ma non può appropriarsi, intestarsi quel merito.Il merito rimane sempre del team, quindi in un'ottica di career progression progression.Questo è un po' complicato quando devi andare a discutere e in alcuni contesti devi utilizzare la carta di "il team ha avuto successo e anche il mio successo" ma deve essere detto e comunicato e soprattutto percepito in modo da non rubare il successo al team and appropriarsene.Non so se sono riuscito a spiegare.No, no, ma ti è spiegato bene.Guarda, te la giro in questa maniera.Tendenzialmente tutti noi abbiamo un manager, ok? Cioè qualcuno sopra di noi.Se le persone sopra di te sono persone valide, riusciranno a capire il tuo valore tanto di più quanto tu saprai esaltare quello delle persone che effettivamente hanno ottenuto quella cosa.organizzare il team, banalmente.Fai vedere chi è che ha fatto questa cosa.Pippo, Pippo, fai vedere alla presentazione con il CEO o con il partner della firma, chi è che ha, cosa hai fatto di bello.Io ti introduco, dico ok, il nostro team ha seguito questa cosa, in particolare la persona che si è occupata di questa cosa come lead del progetto era Pippo.E poi parola Pippo.E sarà tipo che si godrà il momento, si spera che sia ben preparato, non faccia la cura di merda, però giustamente tu come manager l'avrai preparato, l'avrai aiutato a essere nelle condizioni migliori.Se sei in una realtà sana, quelli sopra di te riconosceranno che tu hai fatto crescere le persone che sono sotto di te, che tu hai ottenuto dei miglioramenti in quello che è il team e hai ottenuto dei dei gol di business e te lo sapranno riconoscere senza bisogno che tu ci metta sopra le bandierine.Se sei in una realtà sana cambia lavoro, cioè l'inkedy.Stavo pensando esattamente a quello, sei il manager.Siamo fortunati, siamo ben ricercati anche i manager, anche se meno, per cui altra cosa si scopre quando si comincia a essere manager, che ti cercano meno su LinkedIn rispetto a quando sei un individual contributor, ma ti cercano comunque, per cui se hai una realtà in cui ci sono tossicità di quel tipo, l'unica soluzione è mandare il curriculum a qualcun altro.Abbiamo la conferma da Uncle Bob, quindi hai ragione, hai assolutamente ragione.Se il top manager pensa che il successo del team a quel punto, che il team ha successo quindi può fare a meno di te probabilmente non ha capito il tuo valore di meglio che te ne vai.O magari l'ha capito e tu non vale niente e sei inutile perché può anche esserci questo caso si spera spero per voi di no a me non è capitato fino adesso per cui...ho fatto caso insomma Spero che la nuova sigletta del momento dei donatori vi sia vi sia piaciuta questa è una new entry, nuova sorpresina e ne approfittiamo per ringraziare chi ci sostiene, chi si fa carico ogni settimana di sbezzare con noi, pagare parzialmente uno dei costi, alcuni dei costi perché Gitbar è gratis ma non senza costi e appunto si basa sul contributo della comunità.Questa settimana, in realtà due settimane fa e faccio mea colpa anzi no, una settimana fa e faccio mea colpa abbiamo ricevuto una donazione da Massimiliano San Paolo che ringraziamo e che ci offre tre birre, birre virtuali che solleviamo e appunto brindiamo alla salute di Massimiliano.A parte questo vi volevo ricordare che c'è un'area supportaci nel nostro sito e che soprattutto potete supportarci con i metodi moderni del podcasting 2.0 anche noto come value for value.Cosa vuol dire? Se pensate che questo episodio abbia del valore per voi, per la vostra career progression, per il vostro intrattenimento o per la vostra crescita personale, ecco, e soprattutto avete la possibilità di avere un wallet con qualche satoshi e magari un portafoglio Foglio Lightning potrete supportarci utilizzando un'applicazione del Podcasting 2.0 che trovate nelle note dell'episodio o nel sito newpodcastapps.com.La cosa figa in realtà è che c'è un metodo super bello per supportarci che è lo streaming di Satoshi.Cosa fate? Praticamente ogni minuto che ascoltate ci donate, che ne so, un Satoshi che è una frazione centesimo e questo fa sì che mentre ascoltate l'episodio un Satoshi al minuto ci arriva, adesso non per il valore del Satoshi che è veramente infinitesimale, probabilmente alla fine dell'episodio non ci riusciremo a comprare neanche una caramella, però ci dà l'informazione che state ascoltando l'episodio e che ci sono delle parti che vi interessano particolarmente, quindi se vi fa piacere ecco questo è un buon modo per supportarci.Detto questo passiamo al nostro momento tipico e topico di Gitbar, il momento in cui sia i guest che gli host condividono con noi un libro, un film, un qualunque cosa abbia catturato la loro attenzione e vogliano condividere con la nostra community, quindi il Paese dei Balocchi."E conduco nel Paese dei Balocchi" "Ah, il Paese dei Balocchi" Alberto, domandona, hai qualcosa da condividere con la nostra community? No, farò così.Questo è un regalo di miei figli.Questo è Mago Merlino con Anacleto della Spagna della Roccia.Mago Merlino dice una cosa molto importante a un certo punto, quando è nella cucina con un segola che lava le pentole e Mago Merlino si mette a fare l'incantesimo che automatizza il lavaggio delle pentole e uscendo canta e dice "non sapranno neppure chi è stato, che conta è il risultato.Questa è una delle mie massime un po' liberatorie, nel senso che tante volte c'è una tendenza a voler mettere la bandierina, ho bisogno di dire "l'ho fatto io questa cosa".Tanto più sali sulla scala, tanto più sei in alto nell'albero, più hai questo bisogno di ego, di dire "aspetta, questo l'ho fatto io, l'ho fatto io" eccetera.Tante volte è molto meglio far parlare i risultati.Io ho difficoltà a entrare subito dopo questo inciso perché hai tirato su la sticella talmente alta con questo balocco che per me...- è stato Pado Merlino e la Spada nella roccia, comunque...- Io non ho un balocco dello stesso valore, però un libro che ho letto qualche anno fa, ne abbiamo anche già parlato a Gitbar, il libro è bellissimo, è The Manager Puts, che è veramente veramente un bel libro, anzi, vi dirò, questo mi riprogrammo quest'estate di rileggerlo perché sai le cose volano e fa sempre bene.Sì, è finito per un riletto di un utopo.Esatto, e quello è un libro veramente ben fatto.No, assolutamente, mi piace molto e rientro in Cormer e ne consiglio altri due, se posso.Vai, spara! Libri che possono andare bene per un manager, visto che poi vanno le parti di apprendimento.Allora, uno che è sempre, lo vedo sempre, ce l'ho là e lo guardo sempre quando bisogna dare feedback a qualcuno ed è Radical Candor, è un libro famosissimo ormai, penso che tanti l'abbiano letto, rileggetelo, rileggetelo perché la prima cosa da imparare a fare è dare feedback, dare feedback, comunicare in maniera efficace è essenziale.Quindi questo è il numero uno ed è il libro è il libro cuore.Poi abbiamo un altro libro invece che è un po' più ostico, che è un po' più difficile, però secondo me è un libro che ha del potenziale che dovete andare a scavare, cioè non è un libro dove questo potenziale vi arriva gratis, che si chiama "Extreme Ownership"."Extreme Ownership" è un libro un po' particolare, perché è un libro che è stato scritto da due ex membri dei Navy Seals americani che hanno partecipato alla campagna in Iraq e poi sono abitati dagli istruttori.Ed è un libro in cui praticamente raccontano le loro esperienze in un ambito bellico, quindi un ambito in cui ci sono delle forti negatività, per cui le situazioni sono anche crude, anche un po' fastidiose quasi.Ma la cosa interessante è che loro poi tornati a casa hanno preso le cose che avevano visto e gli insegnamenti hanno aperto la società di consulenza in aiutano i manager a diventare dei manager migliori.Quindi, attraverso un ambito estremo da tutti i punti di vista, dove le decisioni che prendo io, mal che vada, abbiamo toppato la release di un prodotto, di un SaaS, non muore nessuno, lì è proprio l'esatto contrario.È un libro, appunto, non è un libro semplicissimo da approcciare per il tipo di argomenti, però che lascia degli insegnamenti molto forti, un libro interessante.Bellissimo, lo aggiungo sicuramente al mio backlog, non so in quale sprint riuscirò a leggerlo.Sarà il mio regalo di Natale per te.Ti chiedo cortesemente se puoi poi dimandarmi i link, così li mettiamo nelle note dell'episodio qua sotto, potete anche recuperarli.Io ho l'ultimo balocco, in realtà da qualche tempo nei miei side project o almeno nel mio computer sto usando un nuovo terminale, si chiama warp, è un terminale molto molto figo, nelle note dell'episodio trovate un link col mio referral, usate quello così mi mandano la tazza o la maglietta e io sono un feticista delle magliette, è un terminale tra l'altro molto figo scritto in Rust che ha una serie di funzionalità a parte l'LLM che insomma mai manchi ormai ce lo mettono dappertutto ma le vere feature fighe secondo me sono due la prima è la possibilità di salvare i comandi con i template coi play solder esattamente come facciamo coi template di visual studio code e la cosa è molto figa perché in realtà è un attimo, ha un'interfaccia modernissima quindi anche quando giocate con git, insomma i menu sono fatti un po' svecchiati e un'altra cosa figa è che avete l'editing evoluto dal comando che andate a scrivere, quindi se volete il multicursore, se volete il comando multilinea ben fatto, tutto questo è supportato e secondo me era quello che mancava da un terminale moderno cioè va bene TMUX va bene iTerm però insomma...- Lo uso e ti amano, bravo! - Sì, io sono rimasto scioccato, mi piace tantissimo.In realtà dovrebbero migliorare un po' i temi che sembrano un po' tamarri, sembrano un po' uno turbo.Cercavo un Nord Theme fatto bene e in realtà sembra che non riesca a trovarlo, quindi me lo dovrò fare, perché i colori sono un po' quelle sfumature viola o azzurrina o verdi che vanno molto di moda e che sennò insomma io sono un boomer.Esatto però è decisamente figo quindi buttateci un occhio anche di questo trovate il link nelle note dell'episodio.Alberto finalmente ci siamo fatti una super chiacchierata io sono veramente veramente felice che tu sia venuto qua da noi.E' un piacere.E quindi voglio ringraziarti a nome mio e di tutta la community di Gitbar e io lo ripeto ogni episodio a tutti gli ospiti ma perché ci credo davvero, ci credo davvero.Gitbar, come dice il nome, Gitbar è un po' un bar, mi piace rappresentarlo come il il classico circolo del dopolavoro postale o del dopolavoro ferroviario degli anni '60, '50, dove quei circoletti arci, la prima volta che entravi, la birra la '66 di Cnusa o di Peroni costava mille lire, e andavi là perché costava molto meno del barra, con ovvia illusione fiscale, ma la prima volta che entravi ecco ti facevano la tessera e tu da quel momento potevi andare a bere tutte le birre che volevi.Quindi da oggi sentiti possessore della tessera di Gitbar nel circolo del dopolavoro degli sviluppatori e quindi quando hai qualcosa di interessante che ti fa piacere condividere con noi è casa tua, quindi pingami, vieni quando vuoi, c'è sempre una birra per quanto virtuale fresca qua nel nostro bancone.Volentieri.Io rubo ringraziando di nuovo Alberto un minuto per ricordarvi rapidamente i nostri contatti.Info@gitbar non usatelo perché grazie a Ruba non funziona.Le mail vi tornano dietro speriamo di risolverlo al più presto questa problema col dns se volete mandare per forza un email morussetechiacielagmail.com @brainrepo su twitter il nostro canale telegram cercando semplicemente gitbar e il nuovo canale youtube siamo giovani giovani quindi se non l'avete ancora fatto mi raccomando iscrivetevi e cliccate sul campanaccio è il modo per rimanere aggiornati appunto sull'uscita dei nuovi video detto questo io vi do appuntamento alla prossima settimana alla prossima ciao ciao siamo noi che nonostante il deploy fallito la CIA rossa il business incazzato ci troviamo al github e davanti a una birra tutto ci sembra un po meno grave Ciao!
