Il curioso caso Orosz vs. McKinsey. Come misurare gli sviluppatori e... una riflessione sull'autorevolezza

Una polemica tanto vivace, quanto istruttiva

Original in Italian; automatic translation into English available here.

Intro

Gergely Orosz, noto anche come il Pragmatic Engineer, è una delle personalità più influenti nel mondo della tecnologia.

Il suo percorso professionale non è esattamente insignificante: da sviluppatore per J.P. Morgan, a Skype e Skyscanner, per poi approdare a Uber. Qui è stato responsabile degli sviluppi del modulo dei pagamenti: un piccolo mostro di complessità, visto che oltre a tutti gli standard del mondo occidentale supporta una serie di metodi di pagamento specifici di paesi emergenti (ad esempio, indiani) e fa girare cifre da capogiro.

Di fatto, è l’engineering manager/director per eccellenza: una figura che capisce ampiamente il business, dialogando regolarmente con la C-suite di un’azienda, per poi guidare un gruppo di sviluppatori (o in generale esperti di dati e tecnologia), mantenendo una buonissima conoscenza tecnica di cosa c’è “dietro le quinte”.

Se siete curiosi e volete farvi un’idea del profilo di questo professionista, vi consiglio una sua spiegazione di alcuni aspetti dell’app di Uber, semplicemente magistrale:

Si capisce che è abituato a parlare al business e si capisce che è un ingegnere che conosce realmente la materia: un mix raro e di valore, che in Italia spesso non esiste. Anzi, esiste ma spesso è poco compreso.

Ora Orosz è autore di un blog interessante e con quasi 500.000 iscritti, un numero pazzesco per il settore.

Ma cosa c’entra con McKinsey, il colosso della consulenza strategica che non necessita di introduzione?

La valutazione della produttività degli sviluppatori, un problema annoso su cui anche aziende che fanno del software un proprio pilastro (come Google e Microsoft) non hanno mai trovato una vera e propria soluzione.

La pietra dello scandalo

Tutto è partito dall’articolo “Yes, you can measure software developer productivity”, firmato da alcuni partner di McKinsey.

Ho avuto la fortuna di leggerlo pochi giorni dopo la pubblicazione e confesso: ho immaginato subito che sarebbe scoppiato un caso, a causa di frasi come questa.

For example, one company found that its most talented developers were spending excessive time on noncoding activities such as design sessions or managing interdependencies across teams. In response, the company changed its operating model and clarified roles and responsibilities to enable those highest-value developers to do what they do best: code.

Anche senza volere prendere ogni parola alla lettera, e pur tenendo in considerazione alcune semplificazioni che si richiedono per non essere troppo prolissi, questo paragrafo è un po’ avventuroso. È fisiologico che gli sviluppatori senior spendano tempo in attività di design o di comprensione delle interdipendenze tra team (che non sono strettamente coding): serve una visione e una seniority che non può avere un developer junior e tantomeno un manager senza competenze tech. Anzi, per un junior è molto più comune mettersi a testa bassa a scrivere codice su un singolo task o una funzionalità di un prodotto.

Non è mia intenzione entrare tanto nel merito dell’articolo: Linkedin pullula di esperti developer, engineer manager e director che lo discutono in lungo e in largo.

Vi consiglio primo tra tutti proprio Orosz, che in due articoli molto equilibrati approfondisce la tematica (parte 1, parte 2), comprendendo il legittimo interesse di CEO, CIO e affini verso la misurazione delle performance, ma al tempo stesso spiegandone pro e contro. E facendo riferimento alla legge di Goodhart, che voglio parafrasare così: attenzione a misurazioni hackerabili, perché poi i “misurati” si adeguano e un obiettivo legittimo diventa un boomerang!

Da Sketchplanations

Le risposte sono decine, anche alcuni punti in comune ma ovviamente rispecchiano l’indole dell’autore: ad esempio Kent Beck, guru assoluto del mondo dello sviluppo (come potete capire dal suo profilo su Wikipedia), nonché co-autore dell’Agile Manifesto, forse non ha nella diplomazia il suo punto di forza:

The report is so absurd & naive that it makes no sense to critique it in detail.

In realtà penso sia un articolo da leggere, che innanzitutto fa capire che questo è un tema sentito da parte dei CxO, ed in combinata con le risposte di Orosz ci si può fare una propria personale opinione.

I problemi dell’autorevolezza

Del resto il tema della misurazione, così come di incentivi e disincentivi, è molto complesso: ne parliamo io e Stefano Gatti in un capitolo intero su Data Culture, di cui vi condivido la prima pagina… che proprio cita la legge di Goodhart!

Quello che trovo francamente più affascinante - e per cui questa vicenda è un perfetto caso di scuola - è una serie di dinamiche che ruotano attorno al concetto di autorevolezza, su cui si basano anche tante scelte strategiche delle più grandi aziende.

È su questo che mi focalizzerò oggi, provando a schematizzare 3 idee che ho messo a fuoco col tempo.

1. L’autorevolezza è un concetto locale

Diciamocelo: non è mai esistito periodo migliore nella storia per chi unisce velocità di apprendimento¹ e determinazione.

Ed il motivo è semplice: sono crollate le barriere di accesso all’informazione. Secoli fa, studiare (ma anche solo saper leggere e scrivere) era un privilegio di una ristrettissima elite: principalmente ricchi e benestanti, oppure esponenti del clero. Da quei tempi l’accelerazione è stata notevole…

Oggi ci sono ancora settori in cui l’accesso alle informazioni di alto livello è più intermediato di altri (penso al mondo giuridico e a quello medico), ma se guardo agli ambiti a me più vicini (dati, algoritmi, AI e tecnologia), chiunque può accedere gratuitamente o a cifre ridicole a tantissimo materiale di altissima qualità. Non è più questo il collo di bottiglia… sono i due punti che ho menzionato poco sopra, che posso anche esprimere come capacità e costanza.

Viene quindi spontaneo adottare una sorta di proprietà transitiva: se una persona è autorevole su un tema, potrà rapidamente diventarlo su qualunque, assumendo quasi un ruolo di oracolo.

Da Unsplash

Non credo in questo, principalmente perché c’è un elemento che manca: ci vuole tempo per accumulare esperienza e farsi le cicatrici (per dirla come in un celebre speech di Steve Jobs) necessarie per accumulare veramente competenza ed autorevolezza su un tema.

L’autorevolezza non è plug and play. È dalla combinazione tra chi capisce le esigenze dei CxO (come McKinsey) e chi ha diretta e prolungata esperienza sul campo (come Orosz, che è il mio preferito, ma certamente non l’unico) che si può ottenere una sintesi di livello!

Sarebbe stato bello avere una vista a 4 mani sin da subito, invece di un botta e risposta dove si rischia che in molti sentano una sola delle due campane. Pazienza: una volta di più, ci si rimette all’intelligenza e determinazione dei lettori, che devono mettere assieme i due punti di vista.

2. Ci vuole competenza per riconoscere la vera autorevolezza

Se avessi davanti 10 oculisti, di cui 1 luminare e 9 qualsiasi, difficilmente riuscirei a individuare il luminare (da ingegnere quale sono). Probabilmente sbaglierei: dovendo indovinare, mi baserei solo su soft skills e magari sceglierei il più affabile, cortese, brillante, simpatico.

Un altro medico (specializzato in una differente disciplina) capirebbe probabilmente qualcosa di più. Ma tra di loro, diciamo tra oculisti, tutti saprebbero chi davvero è il luminare.

È così su qualsiasi ambito, e la tecnologia non è da meno.

Ho un’esperienza di prima mano su questo fronte. Molte persone che leggono questo blog (ma non tutte!) sanno che nel 2018 sono diventato il primo italiano ad entrare nel top tier delle competizioni di Machine Learning / AI su Kaggle, società comprata da Google nel 2017 che ha erogato oltre 15M$ di premi a data scientists in tutto il mondo (soldi veri). Ai tempi eravamo in 110 persone, ora siamo in 302 e rimango l’unico italiano nel top tier, cioè i Gran Mastri (GM)² delle competizioni Kaggle.

Questi sono i tier (le fasce) su Kaggle.

Per chi è curioso, questo è il mio profilo e qui trovate una bella mappa, fatta dal bravissimo Stefano Morelli. Potete vedere in giallo i GM e in arancione i Maestri (M). In Italia, 1 GM + 10 M.

Parlerò di Kaggle in un’altra occasione, ma un concetto importante è questo: tutto è oggettivo. La classifica di una competizione è automatica e stilata su criterei noti a priori. In un mondo di autoproclamati esperti di AI, non è un fatto marginale, anche se sicuramente Kaggle cattura solo una porzione delle skill richieste da un data scientist.

Questa piattaforma è così nota nel settore che ci sono grandi aziende che si vantano di avere creato team di Kaggle GM tra i propri dipendenti, come Nvidia e H2O, e ho avuto il piacere di essere invitato a parlare di questi temi in mezza Europa. Ma chi (ri)conosce e apprezza tutto ciò?

Sicuramente data scientists e machine learning engineers: capiscono perfettamente l’argomento, che è pubblico e noto nel settore. Una discreta comprensione dell’argomento può caratterizzare alcuni esperti di dati in senso più ampio (da analisti più tradizionali a persone con profilo puramente ingegneristico).

Ma nella mia esperienza, chi non è del settore difficilmente metterà a fuoco quanto sopra, esattamente come l’ingegnere che prova a indovinare chi è il luminare tra 10 oculisti.

3. L’autorevolezza non è onniscienza / infallibilità

Penso che l’Elon Musk di un paio di anni fa abbia regalato parecchie perle (molto più di quello odierno). Una è racchiusa in poche battute (all’interno di una lunga intervista). Riporto qua sotto direttamente il momento clou:

It's particularly dangerous, if a smart person gave you the requirements, because you might not question them enough. […] Everyone's wrong, no matter who you are, some of the time.

Tutti sbagliano, ogni tanto. Sicuramente chi è autorevole su un tema lo fa molto meno degli altri, ma succede.

Il rischio di essere considerati autorevoli è quello di diminuire le proprie capacità di ascolto e al tempo stesso essere messo sempre meno in discussione. L’intervistatore di Musk cita che la parola di persone smart e autorevoli rischia di essere vista come il Vangelo, è ci prende in pieno.

Questo è un problema enorme e genera un circolo vizioso: il rischio è che nessuno poi abbia il coraggio di alzare la mano quando una persona autorevole fa o dice una stupidaggine: per timore reverenziale, per timidezza, per convenienza e valutazione di opportunità.

Oppure per conformarsi.

Penso sia utile per qualsiasi manager conoscere l’esperimento di Asch.

Da Wikipedia

Se chiedo a 10 persone di dire se la lunghezza del bastoncino a sinistra è A, B, oppure C, tutti diranno C.

È ampiamente provato e riprovato che in una stanza con alcuni attori sotto copertura che dicono tutti A, l’unico vero partecipante al test si adeguerà e dirà A in una grande percentuale di casi, prossima ad uno stratosferico 37%. Riproponendo l’esperimento su più casi, solo il 5% dei partecipanti andrà avanti per la propria strada, dicendo sempre la risposta giusta (e diversa dal gregge di attori), non preoccupandosi di fare il bastian contrario. Almeno una volta il restante 95% si conformerà agli altri, e ricordiamo: in un contesto senza trucchi, il tasso di errore è <1%.

Aggiungiamoci che in questo esperimento sono tutti pari, mentre in altri contesti c’è in mezzo anche la gerarchia…

La conseguenza è ovvia: l’assenza di opposizioni non è sufficiente a giustificare l’autorevolezza. È possibile che semplicemente in tanti preferiscano non esporsi.

Conclusioni

I tre aspetti che ho menzionato non si sommano: si moltiplicano.

Da Unsplash

E il risultato è l’autoreferenzialità. Si considera che una persona autorevole su un argomento lo sia automaticamente su tutto, non si hanno le competenze per valutarlo, si crea un circolo vizioso in cui questa persona si considera infallibile e non chiede pareri terzi, disincentivando anche le critiche costruttive.

Supefluo dirlo ma… non è un bello scenario.

È un tema così complesso che ci vorrebbe un libro³… ma forse qualche spunto o accorgimento organizzativo non è poi così inimmaginabile.

Penso che tutto si riconduca al fatto che una delega verso il basso (a livello gerarchico) non deve essere vista come una perdita di ruolo/potere del delegante, quanto semplicemente una dimostrazione di maturità. Tutto questo funziona ovviamente solo se il delegante è in grado in qualche altro modo di giustificare il proprio ruolo… ma qui il tema si allarga.

Vista l’esplosione negli ultimi 10 anni del mondo Dati & AI, penso che qualche riflessione sia utile. La discussione sulla vera autorevolezza è sempre più importante in un mondo trainato dalla tecnologia e dalle aziende tech che hanno molte difficoltà, ma a mio avviso non quelle menzionate in questo articolo.

E giusto un memo: già negli Stati Uniti, la forbice Big Tech vs. resto del mondo si continua ad allargare. Non penso che il quadro nel Vecchio Continente sia migliore, anzi!

Non ho mostrato Nvidia, oggi tra le top 10 aziende americane per capitalizzazione: è fuori scala con un +600% negli ultimi 5 anni. Non penso però sia dovuto al team di Kaggle GM :)

1. O con una parola tanto difficile da definire formalmente, quanto intuitivamente chiara a chiunque: intelligenza.

2. Da associare più al concetto scacchistico che a quello massonico :)

Per chi è curioso, ci sono altri 3 ranking, tutti relativi a come si arricchisce la community: chi ha condiviso dataset interessanti, chi ha reso pubblico codice di qualità, chi è molto attivo nelle discussioni sui forum. Questi 3 sono aspetti che non hanno premi in palio, mentre io mi riferisco alle competizioni: essere GM significa essere regolarmente stato in grado di ottenere risultati almeno nel “top 1%” dei partecipanti, in competizioni con premi tra i 20K e 1M di dollari. Sono tanti per tutti… non parliamo di alcune nazioni popolose, come l’India, dove anche i premi più piccoli possono essere anni e anni di lavoro.

3. Ma no, non ho intenzione di prendere questa direzione! Anche perché appunto… sono così autorevole sul tema per andare oltre un articoletto come questo? Direi di no!