00:00:00 Introduzione agli audit tecnici per startup
00:01:42 Come i VC hanno portato Joannes agli audit tecnologici
00:03:24 Audit tecnologici come fonte di entrate
00:05:08 Valutazione del software nelle startup
00:06:36 L’esperienza di Joannes nel machine learning
00:08:50 Aspetti chiave di un audit tecnologico
00:10:02 Compromessi tra sicurezza e correttezza
00:11:46 Redazione efficace di report per investitori
00:14:57 Valutare le startup oltre le checklist
00:17:04 Adattare gli audit al contesto aziendale
00:20:24 Interviste con CTO e revisione del codice in diretta
00:24:12 Valutare la familiarità e la leadership degli sviluppatori
00:28:22 Giudicare la competenza degli sviluppatori
00:30:49 Segnali di allarme nella qualità del codice
00:33:47 Spunti dalla cronologia dei commit
00:37:03 Sostenibilità dei costi del cloud
00:42:14 LLM che stanno sconvolgendo le startup di NLP
00:46:29 Trovare nicchie di software redditizie
00:50:32 Rischi del debito tecnologico
00:55:34 Sovrainvestimento in scalabilità
00:59:59 La scrittura chiara è segno di una buona ingegneria
01:04:08 Perché gli audit tecnologici sono rari negli investimenti
01:07:12 Considerazioni finali
Riassunto
In un recente episodio di LokadTV, Conor Doherty ha intervistato Joannes Vermorel, CEO di Lokad, riguardo alla sua esperienza decennale nel condurre audit tecnici di startup. Gli “audit tech lightning” di Vermorel offrono ai venture capitalist valutazioni esperte degli stack tecnologici, discostandosi dai metodi tradizionali concentrandosi su valutazioni dinamiche e contestualmente specifiche. Il suo processo prevede valutazioni intensive in un solo giorno, inclusi colloqui con CTO e team di ingegneria per valutare la qualità del codice e la funzionalità del team. Vermorel sottolinea l’importanza della passione, della documentazione chiara e dell’uso saggio delle risorse nello sviluppo tecnologico. I suoi insight rivelano significative lacune nel settore ed evidenziano le migliori pratiche sia per gli investitori che per gli imprenditori tecnologici.
Riassunto Esteso
In un recente episodio di LokadTV, Conor Doherty, Direttore della Comunicazione di Lokad, ha incontrato Joannes Vermorel, CEO e Fondatore di Lokad, per approfondire una delle attività meno conosciute ma di grande impatto di Joannes: eseguire audit tecnici delle startup. Negli ultimi dieci anni, Joannes ha condotto questi audit, offrendo ai venture capitalist pareri esperti sugli stack tecnologici degli investimenti potenziali. Questa pratica, che Joannes definisce “audit tech lightning”, gli ha fornito un punto di vista unico sulle migliori e peggiori pratiche nel settore tecnologico.
Il percorso di Joannes verso gli audit tecnici è iniziato nei primi anni di Lokad quando stava valutando l’idea di accogliere investimenti, ovvero coinvolgere venture capitalist. Sebbene alla fine abbia deciso di non accettare investimenti formali, le sue interazioni con gli investitori lo hanno portato a offrire la sua esperienza nella valutazione degli aspetti tecnologici di altre startup. Questo cambio di rotta gli ha permesso di trasformare incontri che potevano richiedere molto tempo in preziose opportunità di vendita, offrendo i suoi servizi ai venture capitalist interessati a un parere esperto sugli stack tecnologici delle aziende in considerazione per un investimento.
Il fulcro del processo di audit di Joannes è una valutazione intensiva in un solo giorno che si discosta significativamente dai metodi di audit tradizionali. A differenza dell’approccio standard, che si basa pesantemente su checklist, il metodo di Joannes è dinamico e personalizzato in base al contesto specifico di ogni startup. Inizia con un colloquio di 20 minuti con il CTO per comprendere il panorama tecnologico dell’azienda, per poi dedicare il resto della giornata a colloqui individuali con il team di ingegneria. Questo approccio pratico gli consente di valutare non solo la qualità del codice, ma anche la capacità del team di operare con coerenza all’interno della propria tecnologia.
Joannes sottolinea che il suo obiettivo non è diventare un esperto della tecnologia dell’azienda, ma valutare se il team sia funzionale e se la traiettoria tecnologica sia sensata. Cerca pattern nel codice, nella cronologia dei commit e nella qualità della documentazione. Per esempio, può valutare rapidamente la qualità del codice osservando la coerenza degli stili di programmazione e la chiarezza dei messaggi nei commit. Valuta inoltre se il team fa un uso saggio delle risorse limitate, un fattore critico per le startup.
Uno degli insight più sorprendenti condivisi da Joannes è la frequenza con cui le aziende tech possono attraversare più round di investimento senza che nessuno abbia esaminato seriamente la loro tecnologia. Trova sconcertante che anche nelle fasi successive di finanziamento, lo stack tecnologico rimanga spesso incontestato. Questa mancanza di due diligence può portare a significative lacune, come è accaduto famosamente con Theranos.
Joannes ha anche discusso dell’importanza della passione e della cura nello sviluppo tecnologico. Crede che una mancanza di dedizione sia fatale per le aziende tech. Quando il CTO e il team di ingegneria sono veramente appassionati della loro tecnologia, questo si riflette nella qualità e nella coerenza del loro lavoro. Al contrario, quando le aziende esternalizzano lo sviluppo a freelance o mancano di un impegno profondo nella loro tecnologia, i risultati sono spesso disastrosi.
In termini di best practices, Joannes ha evidenziato l’importanza di una scrittura e una documentazione chiare. Sia che si tratti di commenti nel codice o dell’articolazione di enunciati di problemi nei ticket, la chiarezza e la concisione sono indicatori di un team ben funzionante. Apprezza anche l’uso di tecnologie insolite ma ben adatte, che possono indicare una profonda comprensione del panorama tecnologico e un impegno a trovare le soluzioni migliori.
L’approccio di Joannes agli audit tecnici rappresenta un rinfrescante allontanamento dalla norma, concentrandosi sulle realtà pratiche e sulle esigenze specifiche di ogni startup. I suoi insight offrono lezioni preziose sia per gli investitori che per gli imprenditori tecnologici, sottolineando l’importanza della passione, della chiarezza e di un approccio su misura nello sviluppo tecnologico. Con il continuo evolversi del settore tech, il metodo degli “audit tech lightning” di Joannes fornisce un solido framework per valutare il vero potenziale delle innovazioni tecnologiche.
Trascrizione Completa
Conor Doherty: Bentornati su LokadTV. Oggi in studio avrò Joannes Vermorel, fondatore e CEO di Lokad. Discuteremo di una delle sue attività uniche: eseguire audit tecnici di startup. Poche persone sanno che, per circa un decennio, Joannes ha valutato aziende di software, esaminando tutto, dal codice e dall’infrastruttura al personale e alla stessa leadership. Lui e io discuteremo alcune best practices così come ciò che ha imparato nel corso degli anni. Ora, come sempre, se vi piace ciò che ascoltate e apprezzate il nostro lavoro, iscrivetevi al canale YouTube e seguiteci su LinkedIn. E con questo vi presento la conversazione di oggi con Joannes Vermorel. Joannes, bentornato. Come ho menzionato nell’introduzione, siamo qui per parlare non necessariamente della nostra materia abituale, ma di qualcosa che ritengo comunque di notevole interesse. Fai molti audit tecnici, corretto?
Joannes Vermorel: Sì, ed è così da oltre un decennio, probabilmente quasi 14 anni.
Conor Doherty: E come è successo esattamente? Perché, ancora una volta, chiunque abbia seguito LokadTV—sembra sia il settimo o forse l’ottavo anno, magari Max fuori campo può confermarlo—è abituato a sentirti parlare di supply chain e di tutta la tecnologia ad essa correlata. Ma questo è probabilmente la prima volta di cui si parla, eppure hai appena detto che lo fai da 10 anni. Quindi, per quanto riguarda le attività secondarie, è stata una scelta sottile. Come è nata esattamente questa attività?
Joannes Vermorel: Nei primi anni di Lokad, stavo valutando l’idea di accogliere investimenti, sai, coinvolgere venture capitalist. Si è scoperto che non ho mai portato investitori formali nell’azienda, ma nei primi anni di Lokad ho parlato con molti di loro. Col tempo, il solito meccanismo è che o invii una email o loro te la inviano, dicendo: “Oh, prendiamoci un caffè o qualcosa del genere.” Ci vuole tempo per incontrare gli investitori e discutere della tua azienda e se potrebbero essere interessati a investire e così via. Ci vuole tempo, e a un certo punto ho pensato: “Okay, sto spendendo tutto questo tempo incontrando quei potenziali investitori, e quel tempo non lo sto dedicando allo sviluppo, né alla vendita.” Così ho pensato: “Che ne direste di vendere loro qualcosa?” Quindi, sai, ho trattato quegli incontri con i venture capitalist come se fossero incontri di vendita. Si è scoperto che dicevo a quelle persone che, se fossero interessate—non ero un contatto estremamente caldo per loro, poiché non cercavo disperatamente liquidità—ma dicevo che Lokad potrebbe non essere la startup ideale per loro perché non stavo cercando disperatamente denaro. Ma se cercavano qualcuno in grado di fornire un parere esperto su un altro investimento, potevo essere l’uomo giusto. La mia specialità non era guardare un’altra startup e giudicare se avrebbe generato profitti—è al di là della mia expertise, è molto difficile. Ma ciò che rientrava perfettamente nelle mie competenze era avere un’opinione informata riguardo al loro stack tecnologico. Si è scoperto che, quando si è un venture capitalist e si investe in aziende tech, una grande parte della valutazione per molte di queste aziende è data dalla tecnologia che stanno sviluppando. La tecnologia è veramente preziosa? Vale davvero la valutazione pre-money che i fondatori richiedono? E così, ecco, ho iniziato a fare quegli audit tecnici. Ne ho fatti circa uno, a volte due al mese per, di nuovo, credo siano passati 12 o 13 anni, quindi è da parecchio tempo. E così ho valutato molte aziende, e il formato di quegli audit è molto breve. A proposito, mi hai chiesto come faccio a trovare il tempo per farlo. Beh, ho sempre mantenuto quegli audit come audit tech lightning; tutto viene fatto in un solo giorno.
Conor Doherty: Torneremo sicuramente su questo punto, perché ci sono implicazioni nell’approccio. Entreremo nel dettaglio di come il tuo approccio differirebbe da quello che la maggior parte considererebbe lo status quo per quella che essenzialmente equivale a un servizio di consulenza. Tuttavia, solo per inquadrare correttamente il discorso, dato che hai usato il termine “parere esperto” e “expertise”, per chi non si sente qualificato per questo ruolo, sentiti libero di elencare i tuoi numerosi riconoscimenti.
Joannes Vermorel: Sono appassionato di tecnologie software da molto tempo. Ho iniziato a programmare alle elementari, ho trascorso la maggior parte della scuola media e superiore migliorando in programmazione con strumenti sempre più sofisticati, e sono sempre stato estremamente interessato a tutto ciò che riguarda il software. Al momento in cui ho iniziato a fare quegli audit, non avevo ancora 30 anni, ma ero vicino, e già avevo quasi un decennio di esperienza professionale in ambito software, con i miei progetti ma anche con altri progetti realizzati all’università e in altre aziende.
Conor Doherty: Ora, hai anche lavorato in America per un po’ presso AT&T Labs. È stato un periodo in cui erano davvero pionieri nel machine learning. Hanno iniziato a fare machine learning già negli anni ‘90.
Joannes Vermorel: Sì, erano impegnati in quelle cose di machine learning ben prima che l’intelligenza artificiale diventasse di moda e iper-saturata. C’erano persone che lavoravano su queste tematiche, ma, ancora una volta, quella era solo una parte del mio interesse. Quando effettuo audit alle aziende, molto frequentemente il machine learning è solo una piccola parte dei problemi. Molto frequentemente, non fa nemmeno parte del problema. Quelle aziende possono essere di ogni tipo. Ci sono aziende di software, ma possono spaziare da una compagnia biotech che utilizza ampiamente il software, al gioco d’azzardo online, a un’app B2B per la produttività, fino a software incorporati che vengono inseriti in un elettrodomestico situato in una sala operatoria in un ospedale. Il software si presenta in una gamma estremamente ampia di situazioni, e le tecnologie che vengono utilizzate in quelle startup variano enormemente da un’azienda all’altra, anche se il nucleo è sempre il software. È qui che credo risieda veramente la mia expertise.
Conor Doherty: Quando parli di eseguire audit tecnici, penso che la gente abbia un’idea di cosa comporti. Ma in cosa consistono esattamente? Su quali aree ti concentri? Valuti solo il software? Valuti le persone? In cosa consiste esattamente il tuo lavoro?
Joannes Vermorel: La consegna, perché dobbiamo iniziare da ciò che viene consegnato, è una memo che restituisco all’investitore. Un venture capitalist sta per investire in una startup. Di solito hanno una lettera d’intenti già firmata. Stanno per investire da 2 milioni a 20 milioni, a volte di più, di dollari o euro in un’azienda. Una gran parte della valutazione è data dalle tecnologie in cui stanno investendo. Stanno investendo in un team che, presumibilmente, ha già sviluppato qualcosa. Io non conduco quelle verifiche per le fasi seed; stiamo parlando di Serie A, a volte Serie B. Quindi stiamo parlando di persone che, normalmente a questo stadio, hanno già sviluppato qualcosa, il che giustifica una valutazione più alta. Ora la domanda è: vale quello che quelle persone chiedono? Il valore non è solo ciò che possiedono, ma anche le dinamiche tecnologiche all’interno dell’azienda, in modo da poter, se ricevono il denaro dall’investitore, completare gli obiettivi della loro roadmap. Le persone investono non solo in ciò che l’azienda è, ma soprattutto in ciò che l’azienda diventerà domani. Non posso valutare se le loro proiezioni finanziarie saranno corrette. La mia esperienza non risiede nel futuro, diciamo, dei mercati del gioco d’azzardo. Non lo so. È qualcosa che altri devono valutare. Ma se mi mostrano un’app per il gioco d’azzardo, dobbiamo verificare se sarà sicura, perché se si parla di gioco d’azzardo, ad esempio, deve essere estremamente sicura. È questo il tipo di domanda a cui posso rispondere. Se si tratta di un dispositivo che verrà utilizzato durante una procedura chirurgica, allora la correttezza è assolutamente vitale. Quasi letteralmente, se il dispositivo si guasta, può potenzialmente uccidere un paziente. Le sfide di questo tipo sono molto diverse.
Conor Doherty: Solo per tornare al punto, quando fai quell’esempio, ho capito quello sulla sicurezza e, ovviamente, con la tua giacca, ma l’idea del dispositivo chirurgico, qual è il tuo contributo in termini di valutare quella correttezza? Funzionerà in modo affidabile ciò che dovrebbe fare?
Joannes Vermorel: Non è un problema di sicurezza, perché quei dispositivi saranno isolati dalla rete. Verranno operati in un ambiente che è già molto sicuro dal punto di vista IT—nessuna connessione di rete, cose del genere. Ma la domanda è: come si fa a garantire che non ci siano glitch, bug o qualsiasi cosa che possa letteralmente compromettere il funzionamento del dispositivo? Molte macchine oggi sono automatizzate. Se gestisce una pompa che inietta un certo tipo di fluido nel paziente, come si fa a essere sicuri che non ci siano malfunzionamenti, che faccia esattamente ciò che desideri? Quindi, in definitiva, il modo in cui approccio la consegna è forgiando un parere. Quella sarebbe una memo che restituisco all’investitore su ciò che penso, sai, sia la mia opinione generale sul valore di questa azienda nei suoi termini. E questo è davvero l’aspetto importante. Sto cercando di formare un’opinione su ciò che l’azienda vale in base a quello che cerca di raggiungere. Se stai sviluppando un videogioco, la domanda è: stai creando qualcosa di estremamente coinvolgente, appassionante, divertente, ecc.? Quelli sono i tuoi termini di coinvolgimento. Se stai sviluppando una biotech in cui hai una nuova tecnologia diagnostica che presumibilmente ti permette di diagnosticare una patologia prima e più rapidamente di un metodo alternativo, funziona? È reale? Hai delle statistiche solide? Hai tutti quei processi che indicano che i tuoi risultati empirici sono esattamente come dovrebbero essere? Se abbiamo un’app di produttività, la domanda è: per un’app B2B, come si gestisce il fatto di avere centinaia, potenzialmente migliaia, di funzionalità o micro-funzionalità? Questo è il punto con le app per le aziende; possono essere come un labirinto di funzionalità, perché hai così tanti casi da gestire. Come gestisce l’azienda tutta questa complessità? Stanno semplicemente affogando nella loro stessa complessità, o la gestiscono bene? È ben organizzata? A seconda dello startup che finisco per verificare, i termini di coinvolgimento—qual è la proposta di valore, qual è l’essenza del valore—sono molto diversi. La mia consegna consiste nel formare e riflettere un’opinione che restituisco all’investitore su ciò che conta di più. Se durante questa verifica vedessi qualcosa che compromette questo valore fondamentale da consegnare, lo segnalo.
Conor Doherty: Ancora, hai detto che lo fai da circa 10 o 12 anni. Supponendo una o due al mese, stiamo parlando di almeno oltre 100 verifiche effettuate. Quindi, qual è la parte predominante? Perché hai delineato, beh, potrei esaminare un’app per il gioco d’azzardo oppure attrezzature mediche. Ovviamente, questi settori sono molto, molto diversi. Quindi, la maggior parte del tuo lavoro rientrerebbe in cosa, o qual è l’atmosfera tipica quando conduci una verifica?
Joannes Vermorel: Si tratta davvero di aziende che sviluppano software. Sono persone che realizzano software. A volte c’è anche un elemento fisico, sai, possono essere persone che sviluppano software per un dispositivo. Altre volte c’è più o meno software di terze parti da integrare. È un’app autonoma oppure sei integrato in molte altre cose? Tante situazioni. Voglio dire, ovviamente, probabilmente due terzi di quello che ho fatto sono B2B o attrezzature professionali, e un terzo è B2C. Ma per quanto riguarda la classificazione, per il resto, è estremamente vario.
Conor Doherty: Bene, ci hai fornito una panoramica efficace a livello elevato della consegna e del tuo background. Ma in termini dei passaggi principali, come formi un’opinione e quali sono i passaggi coinvolti per arrivare effettivamente a quella memo e a quell’opinione?
Joannes Vermorel: Ed è qui che il mio approccio diverge ampiamente da quello che le persone solitamente intendono per processo di verifica. Solo per riassumere per il pubblico, un auditor, e direi che il 99% delle persone che eseguono verifiche di qualsiasi tipo, ha delle checklist. Hanno delle lunghe checklist con centinaia di domande e vanno in azienda a chiedere: “Fate questo o quello?” Sì, no, sì, no, ecc. L’auditor passa semplicemente in rassegna la lista come un drone. La mia idea è che questo processo sia completamente insensato per le verifiche tecnologiche, specialmente per le startup.
Il problema è che questa checklist, qualunque essa sia, non metterà mai in discussione la startup nei suoi stessi termini. È completamente irrilevante sfidare, diciamo, un’azienda che sviluppa videogiochi sul fatto che sia super sicura. Se fai un videogioco, la sicurezza è una preoccupazione secondaria. In una startup, le risorse sono scarse. Ha senso per la maggior parte dei videogiochi investire in un responsabile della sicurezza e in funzionalità di sicurezza che complicano la vita degli utenti? Se si tratta di videogiochi casual, ad esempio, non ha alcun senso. A nessuno importa del fatto che tu stia giocando a Farmville.
In definitiva, avere delle checklist è una ricetta per sprecare un’enorme quantità di tempo per i fondatori e per distrarre massicciamente gli investitori stessi. Potrebbero dire: “Oh, la startup è conforme a centinaia di elementi irrilevanti,” e poi tu diresti: “Oh, ma non sono conformi a questi 100 elementi,” che sono anch’essi completamente irrilevanti per il successo dell’azienda. La mia visione è che abbiano un business case; dicono di voler seguire una certa direzione strategica. Lascio ad altri il compito di valutare se ci sono soldi da guadagnare. Io non mi occupo di questo. Voglio dire, sì, ho una mia opinione su se sembri plausibile, ma non mi interrogo sulle dimensioni del mercato. La mia idea è: ok, assumiamo che ci sia un mercato e che se esegui questa cosa in maniera eccellente, ci saranno persone da servire e quelle persone saranno disposte a pagarti.
Ora la domanda è davvero: riuscirai a mantenere ciò che prometti? Stai sviluppando una tecnologia che dovrebbe fare qualcosa. Riuscirai a consegnare ciò che stai effettivamente promettendo?
Conor Doherty: E sei in una posizione per fornire quel livello di approfondimento. Puoi speculare sulla tecnologia e…
Joannes Vermorel: Rispetto a un auditor, tornando alla checklist, la mia idea è che quando inizio la giornata, durante i primi 20 minuti, generalmente intervisto il CTO. L’idea è che entro 20 minuti devo architettare mentalmente una serie di domande per guidare la discussione verso ciò che è di maggiore interesse. Dopo quei 20 minuti di presentazione, tipicamente svolti tramite una conversazione informale, proseguo il resto della giornata con una serie di interviste in cui c’è qualcuno davanti a un computer che mi mostra il loro codebase. Conduco una serie di interviste one-to-one dove entrambi guardiamo lo stesso schermo, e un dipendente dell’azienda fa da guida attraverso il loro codebase.
Conor Doherty: Quindi, sei Virgil.
Joannes Vermorel: Sì, mi stanno guidando attraverso il loro codebase. Non chiedo una copia del codebase perché potrebbe creare un sacco di problemi e rendermi responsabile per la proprietà intellettuale. L’idea è che io voglia dare un’occhiata al codebase, ed è in questo modo che esamino la tecnologia. Ma i codebase possono essere estremamente estesi. Anche una piccola azienda con cinque ingegneri software che lavorano per qualche anno può facilmente avere 100.000 righe di codice o più. Se dovessi navigare questo codebase da solo, il 90% del mio tempo verrebbe sprecato per orientarmi. Quindi, ho un ingegnere seduto accanto a me, faccio domande, e loro mi mostrano il codice. Esaminiamo il codice insieme, ovviamente un campione del codice; non possiamo rivedere l’intero codebase.
Conor Doherty: Dato l’alto rischio finanziario potenziale, perché non esamineresti tutto questo semplicemente con il CTO?
Joannes Vermorel: Innanzitutto, il CTO non è necessariamente a conoscenza di tutte le parti del codebase. Se si tratta di un team di cinque persone, incluso il CTO, allora probabilmente sì, il CTO conosce l’intero codebase. Se parliamo di un’azienda in una fase più avanzata con 20 ingegneri, molto probabilmente il CTO non è competente in ogni segmento del codebase. Ma, più in generale, è anche molto interessante per me avere altre persone dell’azienda sedute accanto a me, perché così posso vedere quanto siano fluenti con il codebase. Sono completamente smarriti nella loro stessa tecnologia? Quando chiedo una domanda di base come “Come accedi al livello persistente?” o “Come accedi ai dati che hai registrato?” se le persone non ne hanno idea, non va bene. Se chiedo loro “Qual è l’ultima cosa che hai fatto?” e rispondono “Ho sviluppato questa funzionalità”, e poi sembrano persi nel mostrarmi su cosa stanno attualmente lavorando, non va bene.
Intervistare il CTO va bene, ma devo anche valutare se il team è all’altezza del CTO. Questo può andare in entrambe le direzioni. A volte il CTO è molto bravo, ma il resto del team non lo è. A volte è il contrario. A volte il CTO è molto debole, ma il resto del team è in realtà piuttosto forte. Varia, e questo influenzerà anche le opinioni che restituisco all’investitore come parte di questa memo per la consegna. Ho anche un’opinione sul fatto che i collaboratori attualmente presenti nell’azienda siano pronti ad affrontare la sfida per la prossima fase. Se l’investimento avviene, a volte quando un’azienda inizia, il loro budget è estremamente limitato e assumono persone che non sono super talentuose dal punto di vista tecnologico. Questo accade frequentemente quando il fondatore non è un fondatore tecnico. Quando il fondatore è qualcuno che aveva conoscenze interne, che sa che esiste un problema specifico da risolvere, e questa persona vede una necessità e willingness to pay. Questo succede molto frequentemente nei mercati B2B. Ma questa persona non è tecnica, quindi assume il primo ingegnere software disponibile. Potrebbero non avere un grande budget, quindi il loro primo assunto potrebbe essere qualcuno il cui principale vantaggio è essere molto economico.
Ancora, va bene, va bene. Voglio dire, parti da zero. Hai, diciamo, €20.000, li metti nell’azienda. Per te, è già un investimento considerevole. Grazie a quei €20.000, riesci a ottenere, diciamo, un seed di mezzo milione. Questo va bene. Puoi avere il tuo team di, diciamo, due ingegneri software per sviluppare il prodotto. Poi vuoi passare allo stadio successivo e ora ottenere il primo round di, diciamo, €3 milioni. Beh, a questo punto, se parliamo di un investimento multimilionario, sei in una fase in cui ora hai i fondi per avere vero talento in termini di ingegneria del software. Quindi la domanda è: le persone che hai attualmente sono pronte ad affrontare la sfida per il livello successivo, la prossima fase dell’azienda? Quindi, questa non è l’unica domanda, ma è anche una delle questioni esaminate.
Conor Doherty: Solo per essere chiari, come parte del memorandum, la consegna, potresti potenzialmente fare raccomandazioni su chi dovrebbe rimanere e chi no?
Joannes Vermorel: Sì, sì. Di nuovo, è qualsiasi cosa che possa aiutare o compromettere il valore tecnologico dell’azienda, la sua traiettoria tecnologica. A volte hai i giocatori sbagliati. Voglio dire, avevi i giocatori necessari per vincere un campionato super locale, ma se vuoi giocare a livello nazionale o addirittura puntare al campionato mondiale, allora forse hai bisogno di giocatori diversi. Portare più denaro cambia le dinamiche. Improvvisamente, puoi potenzialmente permetterti persone molto più esperte, molto più talentuose. Varia. A volte le persone sono molto talentuose, ma per qualche ragione la dinamica in azienda è pessima. A volte, per qualche motivo, si può arrivare ad avere due CTO. È successo in alcuni audit. Quindi hai due responsabili tecnologici e queste due persone stanno seguendo roadmap differenti. Il mio messaggio è: scegli uno. Non puoi rimanere completamente schizofrenico; devi scegliere. Questa sarebbe una decisione aziendale perché stai cercando di conquistare mercati differenti. Ma in definitiva, questo è proprio il tipo di problema in cui un investitore deve capire se c’è qualcosa che non va nella tecnologia o se ci sarà qualcosa in futuro. Perché a volte non c’è ancora un problema, ma aggiungere denaro è come gettare benzina sul fuoco. Se hai qualcosa di leggermente disfunzionale, se inizi a versarci sopra un paio di milioni, quello che era un piccolo problema potrebbe semplicemente essere amplificato enormemente dall’investimento stesso. Quindi anche quello può essere un problema. Di nuovo, per me non esiste una checklist, non ci sono regole. È qualsiasi cosa io veda che abbia senso in termini di problemi da risolvere o di raccomandazioni per l’investitore. Questo fa parte del mio ambito. L’idea è che mantenga questo come una missione di un giorno perché non ho il tempo per fare molto di più. Ma anche perché gli stessi fondatori sono molto occupati. Penso che parte del problema delle verifiche classiche sia che queste attività sono una totale perdita di tempo. Richiedono settimane, paralizzano completamente l’azienda e non esce nulla di buono da tutto ciò.
Conor Doherty: Beh, a proposito, quindi stai dicendo che non usi una checklist, miri ad entrare ed uscire in meno di un giorno. Quando dici un giorno, intendi una giornata lavorativa. Quindi stai parlando di, invece di un processo che dura settimane – settimane di giornate da 8 ore – stai parlando di forse 8-10 ore, escludendo taxi e voli, senza usare una checklist, e poi fare raccomandazioni molto consequenziali su cosa fare con l’azienda, cose che influenzeranno altre persone. Devo chiederti: date tutte queste restrizioni, sei davvero così brillante oppure come prendi quelle decisioni in un solo giorno senza checklist?
Joannes Vermorel: Già, intendo, prima di tutto, il code base. Se sei un po’ abituato a leggere molti code base, queste cose diventano estremamente evidenti. In pochi minuti, osservando il code base, capisci se il codice è scritto bene o se è semplicemente una merda. Di solito mi formo un’opinione entro 5 minuti di navigazione in quel code base. Se sei davvero abituato a leggere molti linguaggi di programmazione e hai visto tanti code base, non ti servono ore per decidere se si tratta di un ingegneria ben fatta, compatta, ben organizzata, che ha senso, o se è solo puro caos e incoerenza. Per esempio, se scorro un code base e vedo stili di codifica radicalmente differenti, dico: “Oh, ok, quindi abbiamo contributori diversi che non hanno alcun accordo condiviso su come dovrebbe apparire il codice.” È davvero pessimo. Controllo la cronologia dei commit? Questo mi dice molte cose. Ad esempio, se vedo che nella cronologia dei commit hai un commit per una feature e poi due dozzine di commit per sistemare bug causati dall’introduzione di quella feature, è super pessimo. Significa che ogni volta che le persone introducono qualcosa, passeranno molto tempo solo a riparare ciò che hanno appena rotto. Quindi, solo osservando superficialmente magari gli ultimi 200 commit, puoi capire se c’è un pattern. Puoi notare molti pattern. A volte, ad esempio, osservi la cronologia dei messaggi dei commit. Questa è l’evoluzione vista dal pubblico. I commit rappresentano il modo in cui modifichi il code base in modo incrementale. Apporti cambiamenti, e di solito usi Git al giorno d’oggi. Lo usiamo per il web, e da Lokad lo usiamo come tutti gli altri per il nostro stack tecnologico. La questione è, per esempio, quando vedi modifiche applicate al code base, queste modifiche hanno senso? Per esempio, se hai commit dove il titolo del commit è “more stuff”, letteralmente, cos’è questo pezzo di spazzatura? No, non hai che “alcune cosette” cambiate. Poi, per esempio, se hai un bug che viene corretto, viene fatto qualcosa insieme alla correzione del bug per assicurarsi che il bug non venga reintrodotto la prossima volta che tocchi il code base? Ci sono molti metodi per assicurarsi che il bug non riaffiori. Ci stai facendo caso? Quando osservi i contributi, i commit, le persone fanno code review? Discutono su come le cose dovrebbero essere ingegnerizzate? Di nuovo, il code base racconta una storia enorme sia su cosa sia la tecnologia, sia sulla sua storia. Puoi vedere la traiettoria, come si è sviluppata. Poi puoi concentrare l’attenzione sulle parti fondamentali. Per esempio, se sei una startup di AI o machine learning, il tuo valore fondamentale dovrebbe essere una specie di smart numerical recipe che fa qualcosa di molto difficile o simile. Come lo stai facendo? È solo un trucco, oppure hai una profonda esperienza? Quanto vantaggio competitivo possiedi? Hai un vero vantaggio, per cui replicare ciò che hai fatto sarà difficile, o è solo un trucco da illusionista in cui usi qualche libreria open-source e, bam, in realtà nulla è di tua produzione? Hai semplicemente riciclato qualcosa presente nella community. Di nuovo, questa è una domanda molto critica per l’investitore, perché se la gente dice, “Oh, abbiamo sviluppato una tecnologia di machine learning unica”, se quello che stai facendo è essenzialmente riutilizzare qualcosa di open-source, chiunque può farlo. Quindi sì, è figo, sì, funziona, ma l’investitore dovrebbe valutare la tua azienda molto in alto solo perché hai qualcosa che funziona? Beh, non proprio, perché se è open-source, significa che praticamente chiunque può farlo. Quindi, nessun vantaggio competitivo. Di nuovo, le cose che osservo dipendono davvero dalle specifiche dell’azienda.
Conor Doherty: Puoi anche, prendendo ad esempio quello di cui hai parlato e combinandolo con un aneddoto, se prendi l’esempio di guardare il registro dei commit in Git o Bitbucket—usiamo Bitbucket—puoi estrapolare parecchie informazioni. Per esempio, anche per noi del team marketing, ogni volta che pubblichiamo qualcosa sul sito, insisti su un registro dei commit molto pulito e ordinato. Si vede esattamente cosa è successo, chi l’ha approvato.
Joannes Vermorel: Esatto. E inoltre, a volte anche il modo in cui le persone interagiscono con me. Sto parlando con qualcuno, faccio una domanda a caso e vedo se questa persona è fulminea nel portarmi direttamente nel punto giusto del codice. Tipo, “Oh, c’è questa funzionalità che mi interessa, puoi mostrarmi il codice rilevante?” E poi il tipo risponde, “Oh sì, nessun problema,” bam, subito nel segno, direttamente nell’implementazione. Questo è molto positivo. Quella completa padronanza del code base, di come vengono fatte le cose, è davvero, davvero buona. Quindi, a volte, la facilità con cui le persone navigano nel code base mi dice molto. Inoltre, per esempio, quando introducono nuove funzionalità, hanno dei ticket ben scritti per giustificarli? Gli ingegneri del software sono improvvisati e fanno cose a casaccio con il codice, oppure hanno un sistema ben organizzato dove dicono, “Ok, voglio fare questo, ecco il mio ticket che descrive chiaramente perché voglio farlo,” e poi si discute dei vari modi per affrontarlo, ecc.? Quindi dipende, ma questo è tipicamente ciò che rende importanti i ticket. Sarebbe fondamentale per app B2B, app di produttività, perché hai un’infinità di funzionalità, tutte estremamente specifiche per quel dominio. Se stai sviluppando un’app enterprise, non dovresti perderti nell’infinito numero di funzionalità che potresti aggiungere. Quindi questo aspetto è molto importante per i vari tipi di aziende. Sarebbe un processo completamente diverso. Ma quello che sto cercando di dire è: come posso formarmi un’opinione in poche ore? Se sei seduto accanto a qualcuno che lavora sul code base, puoi vedere davvero tanto. Se presti attenzione ai pattern, a quello che le persone stanno facendo, e sì, si tratta di riconoscimento di pattern. C’è un numero finito di cose in cui le persone possono essere brave o cattive data una certa vocazione.
C’è un numero finito di cose in cui le persone possono essere brave o cattive data una certa vocazione.
Conor Doherty: Sì, e inoltre verifichi la coerenza, sai. Le persone stanno raccontando la stessa storia in termini di tecnologia? Tipo, chiedo, “Cosa pensi che faccia questo componente?” E se ricevo risposte completamente differenti da varie persone, dico, “Ok, quindi chiaramente in questo team non è molto chiaro che tutti capiscano veramente cosa stia succedendo.”
Joannes Vermorel: Non ho bisogno della verità per riconoscere che le cose sono incoerenti. Di nuovo, il mio obiettivo non è diventare un esperto in ciò che fanno. Il mio obiettivo è semplicemente valutare se il team è funzionale, se la traiettoria nello sviluppo della tecnologia è sensata. A volte si tratta anche di verificare, per esempio, che le risorse nel cloud computing siano sotto controllo. A volte ci sono aziende che gestiscono male le risorse cloud. Il cloud è fantastico, paghi in base all’utilizzo, il che significa che il limite è il cielo. Puoi avviare tonnellate di macchine virtuali, tonnellate di storage, tonnellate di tutto. E a volte, sai, alcune aziende impazziscono un po’ in questo senso e finiscono per spendere molto più del dovuto per le risorse di cloud computing.
Conor Doherty: Questo dipende di nuovo da quello che stanno facendo. Quanto dovresti pagare per le risorse di cloud computing? Beh, dipende davvero da cosa stai cercando di ottenere. Quindi non esiste una regola chiara, ma parte dell’esperienza consiste nel valutare qual è il carico di lavoro che stai tentando di realizzare nel cloud e se ha senso che tu stia pagando così tanto. È un risultato, ben fatto, il tuo software è altamente performante, oppure è pessimo e stai semplicemente bruciando denaro? Probabilmente offrirti tonnellate di denaro extra da bruciare non è la mossa giusta. Dovresti probabilmente sistemare quei problemi prima di ottenere qualche milione in più.
Joannes Vermorel: Se ti manca il denaro, non puoi disciplinarti per non bruciare soldi con spese sconsiderate in risorse computazionali. Le probabilità che diventi saggio una volta che hai tantissimo denaro sono davvero esigue.
Conor Doherty: A proposito, abbiamo effettivamente un altro video sul tema delle risorse computazionali, quindi dai un’occhiata alla playlist per quello. Ma parlando di denaro, quando si tratta di finanze, so che quando parliamo di supply chain, parli dell’impatto finanziario netto di qualunque scelta tu decida di fare. Adotti lo stesso approccio quando valuti un’azienda tech? Guardi quale sia l’orchestrazione finanziariamente più vantaggiosa dell’azienda tecnologica o si tratta semplicemente della migliore tecnologia a prescindere dal prezzo?
Joannes Vermorel: No, no, no. Ogni startup ha risorse limitate. L’idea – e questo è di nuovo il problema con le checklist – è che le checklist hanno una prospettiva assoluta. Dicono che devi fare questo, questo, questo e questo. La mia prospettiva è sempre completamente relativa alla maturità dell’azienda.
Conor Doherty: Sì, esattamente, secondo le loro condizioni.
Joannes Vermorel: Non vuoi, per esempio, che sarebbe pura follia per una piccola azienda puntare a una certificazione ISO. Sarebbe una totale perdita di risorse, a meno che non si operi in un mercato iper-regolato in cui non puoi sopravvivere senza quella certificazione. Quello che osservo è quanto sei bravo a sfruttare le tue risorse limitate per ottenere il massimo ritorno. Presumo semplicemente che la tua direzione sia buona, che alla fine, se avrai successo, farai soldi. Ma comunque, se prendo per scontate le tue direzioni aziendali, dico: “Ok, ammettiamo che se questo viene realizzato, allora sarai competitivo in questo mercato e ci saranno soldi da fare.” E lo assumo. Ora, ogni dollaro o euro speso per diventare il giocatore numero uno in questo mercato, è speso in modo saggio?
Conor Doherty: Assolutamente. Questo può riguardare, ad esempio, l’avere il talento giusto? A volte spendono troppo poco. Succede che, quando un’azienda raggiunge un certo grado di successo, non si separa da persone inizialmente assunte solo perché erano super economiche. Questo accade abbastanza frequentemente anche con le startup tech.
Joannes Vermorel: Soprattutto quando il fondatore non è un fondatore tech, ma è un fondatore commerciale, e poi hai il CTO che è stato originariamente il primo ingegnere del software assunto dall’azienda. Questo succede spesso, e quella persona non è al livello richiesto. Di nuovo, le eccezioni variano, i casi possono differire.
Conor Doherty: Esatto. La mia domanda è: ci sono state situazioni in cui sei entrato per valutare un’azienda, dove esamini tutte le cose di cui hai parlato – il codice, il modo in cui il team lavora, se possono raggiungere l’obiettivo con le risorse che hanno a disposizione – e poi scopri che il loro obiettivo finale era semplicemente assurdo? Per esempio, è il 2008 e questa azienda è decisa a far tornare in auge le cassette VHS, qualcosa di completamente folle che, a tuo avviso, è una enorme perdita di denaro, tempo e risorse.
Joannes Vermorel: Oh sì, succede. Sentiti libero di farlo, ma non citare nomi.
Conor Doherty: No, il punto è che alcune tecnologie software evolvono piuttosto rapidamente. Per esempio, negli ultimi due anni ho effettuato audit in parecchie aziende che lavoravano con NLP. Queste aziende sono state avviate nel 2018 o nel 2019 e si sono gettate nell’onda dell’IA, sviluppando tecnologie NLP, di natural language processing, ma pre-LLM, pre-large language models. C’era una letteratura enorme di modelli NLP e machine learning, deep learning, che non sono LLM. Gli LLM sono stati un evento di estinzione per tutte quelle tecnologie NLP.
Joannes Vermorel: Sì, c’erano molte aziende dove la mia conclusione era: questa azienda ha sviluppato 20 modelli NLP abbastanza sofisticati, ma sono tutti completamente obsoleti. Gli LLM stanno uniformemente superando tutto ciò. Puoi semplicemente buttare via tutta la tech stack e ricominciare da zero con un LLM al centro, e sarai migliore. Non c’è nulla da salvare. Succede abbastanza frequentemente, forse una su 10, una su 20, dove la tecnologia è semplicemente obsoleta per qualche motivo. A volte le persone non hanno visto esattamente quale sarà il sostituto, ma sì, quando vedo che questa cosa sta semplicemente per… stai risolvendo un problema che è già stato risolto.
Conor Doherty: Di solito, la questione non è assurda nel senso che quelle persone siano degli idioti. C’è un problema da risolvere, e hanno sviluppato qualcosa di interessante, ma c’è qualcosa di molto migliore che è già stato trovato e possibilmente gratuito. Questa cosa non è ancora popolare, non è ancora molto conosciuta. Penso che gli LLM siano davvero il caso estremo in cui quelle aziende erano un po’ disperate perché sapevano che stavano arrivando gli LLM e che rappresentavano un evento di estinzione. Ma se sei il fondatore di un’azienda, hai già investito i soldi raccolti nei round seed per farlo, e ora ti trovi di fronte alla prospettiva che la tua tecnologia sia un po’ senza valore. Cerchi magari di ottenere un investimento che ti permetta di riprogettare la tecnologia. Difficile.
Joannes Vermorel: Il mio punto di vista in questo tipo di situazione non è dire agli investitori, “Non investite.” Il mio messaggio è che la tech stack che possiedono non vale nulla. Se le persone sono brave, potrebbe comunque esserci motivo di investire in loro, ma a una valutazione molto inferiore, perché ciò che hanno è, semplicemente, un asset tecnologico completamente obsoleto. Non è più un asset, è una passività.
Il team è funzionale, e la traiettoria in termini di sviluppo della tecnologia è assurda. A volte si tratta anche di verificare, per esempio, che le risorse in termini di cloud computing siano sotto controllo. A volte ci sono aziende che gestiscono male le loro risorse cloud. Il cloud è fantastico; il pay as you go significa che il cielo è il limite. Puoi far girare tonnellate di macchine virtuali, tonnellate di storage, tonnellate di tutto. A volte le aziende esagerano e finiscono per spendere molto più di quanto dovrebbero in risorse di cloud computing. Dipende da ciò che stanno facendo. Quanto dovresti pagare per le risorse di cloud computing? Beh, dipende davvero da ciò che stai cercando di ottenere. Non esiste una regola precisa, ma parte dell’esperienza è valutare quale sia il carico di lavoro che stai cercando di realizzare sul cloud e se ha senso pagare quella cifra. È un risultato ben fatto, il tuo software è altamente performante, oppure è pessimo e stai semplicemente bruciando soldi? Probabilmente avere a disposizione tonnellate di soldi extra da spendere non è la mossa giusta. Dovresti probabilmente risolvere quei problemi prima di ottenere qualche milione in più. Se ti mancano i soldi, non puoi disciplinarti per evitare spese imprudenti in risorse computazionali. Le probabilità che tu diventi saggio una volta che avrai molti più soldi sono davvero esigue.
Conor Doherty: Mi viene in mente – e a proposito, abbiamo effettivamente un altro video sul tema delle risorse computazionali, quindi controlla la playlist per quello – che quando si parla di finanze, so che quando discutiamo di supply chain, si parla dell’impatto finanziario netto di qualsiasi scelta tu faccia. Adotti lo stesso approccio quando valuti un’azienda tecnologica? Ti focalizzi su quale orchestrazione sia la più vantaggiosa dal punto di vista finanziario, o su quella che è semplicemente la tecnologia migliore a prescindere dal prezzo?
Joannes Vermorel: No, no, no. Ogni startup ha risorse limitate. Il problema con le liste di controllo è che hanno una prospettiva assoluta, dicendo che devi fare questo, questo e questo. La mia visione è sempre completamente relativa alla maturità dell’azienda.
Conor Doherty: Sì, esattamente, a loro condizioni.
Joannes Vermorel: Non vorresti, per esempio, sarebbe pura follia per una piccola azienda puntare a una certificazione ISO. È una completa perdita di risorse, a meno che non si tratti di un mercato iper-regolamentato in cui non puoi sopravvivere senza quella certificazione. Quello che valuto è quanto sei bravo a sfruttare le tue limitate risorse per ottenere il massimo rendimento. Presumo semplicemente che la tua direzione sia buona, e che alla fine, se avrai successo, farai soldi. Ma comunque, se prendo per scontato le tue strategie aziendali, dico: ok, ammettiamo che se questo progetto va a buon fine, allora sarai competitivo in questo mercato e ci saranno soldi da fare. Lo accetto. Ora, ogni dollaro o euro speso per diventare il player numero uno in questo mercato, è speso in modo saggio? Assolutamente. Ci si chiede, ad esempio, se si ha il talento giusto. A volte, infatti, spendono troppo poco. Succede che, quando l’azienda raggiunge un certo successo, non lascia andare personale che era stato assunto inizialmente solo perché era super economico. Questo capita abbastanza frequentemente anche nelle startup tecnologiche. Soprattutto quando il fondatore non è un fondatore tecnologico, ma un fondatore commerciale, e poi c’è il CTO che era, all’inizio, il primo ingegnere software assunto dall’azienda. Questo succede spesso, e quella persona non è al livello richiesto. Ancora una volta, le eccezioni variano, la situazione dipende dal caso.
Conor Doherty: Esattamente. La mia domanda è: ci sono state situazioni in cui sei entrato in un’azienda e ne sei uscito pensando, “Ho appena incontrato il prossimo Elon Musk?”; cioè, quel tizio è un genio, hanno un diamante in mano.
Joannes Vermorel: Oh sì, succede.
Conor Doherty: Sentiti libero di condividere, ma non fare nomi.
Joannes Vermorel: Alcune tecnologie software evolvono abbastanza rapidamente. Per esempio, negli ultimi due anni ho revisionato parecchie aziende che operano nel campo degli NLP. Queste aziende sono state avviate nel 2018 o nel 2019, ed hanno cavalcato l’onda dell’AI sviluppando tecnologie NLP (Natural Language Processing), ma pre-LLM (Large Language Models). C’era un’enorme letteratura di modelli NLP, machine learning, deep learning, ma non di LLM. Gli LLM hanno rappresentato un evento di estinzione per tutte quelle tecnologie NLP. Per quelle aziende, la mia conclusione era che avevano sviluppato 20 modelli NLP abbastanza sofisticati, ma tutti completamente obsoleti. Gli LLM stanno uniformemente superando tutto ciò. Puoi semplicemente abbandonare la tech stack e ricominciare da zero con un LLM al centro. Non c’è nulla da salvare. Succede abbastanza frequentemente, forse una su 10 o una su 20, dove la tecnologia è semplicemente obsoleta per qualche motivo. A volte le persone non hanno visto esattamente quale sarà il sostituto. Quando vedo che questa cosa sta semplicemente per… stai risolvendo un problema che è già stato risolto. Di solito, non è assurdo nel senso che quelle persone siano degli idioti. C’è un problema da risolvere, e hanno sviluppato qualcosa di bello, ma c’è qualcosa di molto migliore che è già stato trovato e possibilmente gratuito. Questa cosa non è ancora popolare, non è ancora super conosciuta. Gli LLM rappresentano un caso estremo in cui le aziende erano un po’ disperate perché sapevano cosa stava arrivando, ed era un evento di estinzione. Sei il fondatore di un’azienda, hai già investito i soldi raccolti nei round seed per farlo, e ora ti trovi di fronte alla prospettiva che la tua tecnologia sia un po’ senza valore. Cerchi magari di attrarre un investimento che ti permetta di riprogettare la tecnologia. Difficile. Il mio punto di vista non è dire agli investitori di non investire. Il mio messaggio è che la tech stack che possiedono non vale niente. Se le persone sono brave, potrebbe comunque esserci motivo di investire in loro, ma a una valutazione molto inferiore, perché ciò che hanno non è più un asset, è una passività.
Conor Doherty: All’estremità opposta di quello spettro, ti è mai capitato di entrare in un’azienda e uscire pensando, “Ho appena incontrato il prossimo Elon Musk?”; cioè, quel tizio è un genio, hanno un diamante in mano.
Joannes Vermorel: Su quella scala, no. Ma sì, a volte mi sono sentito un po’ geloso rispetto alla mia stessa azienda. Soprattutto quando le persone possiedono nicchie così belle. Ci sono così tante nicchie affascinanti. I casi che mi fanno più invidia sono quei problemi belli e super di nicchia. Nessuno sa nemmeno che questo problema esiste. Si scopre che ci sono decine di milioni, possibilmente anche un miliardo in gioco. Questo è un mercato di nicchia, e alcune persone offrono una soluzione per questa nicchia, ed è bellissima. È molto semplice, diretta, al punto. Invece di affrontare un mercato iper-competitivo, per esempio, Lokad facendo supply chain ottimizzazione, abbiamo oltre mille concorrenti in tutto il mondo. È un mercato molto affollato. Abbiamo concorrenti che sono aziende multimiliardarie. Il panorama competitivo è duro. A volte incontro aziende che letteralmente non hanno concorrenti. Sono uniche. I loro clienti sono soddisfatti, e hanno una soluzione davvero tarata per un problema di nicchia di cui non avevo mai sentito parlare.
Conor Doherty: Esempi a riguardo oppure sarebbe troppo rivelatore?
Joannes Vermorel: No, sarebbe purtroppo troppo rivelatore. Cerco di non dirlo, ma in sostanza, pensa a tutto ciò che sia super specializzato.
Pensate alla manutenzione specializzata di una piattaforma petrolifera offshore. Ci sono tonnellate di cose da fare, e alcune operazioni speciali richiedono software di supporto. Ci sono aziende che fanno proprio questo. Pensa a ogni singola nicchia che probabilmente necessita di soluzioni molto dedicate.
Ci sono innumerevoli situazioni in cui puoi immaginare quanta strumentazione tecnologica utilizza un chirurgo in sala operatoria. Tanta attrezzatura, se vuoi quantificare qualcosa. Per esempio, in questo edificio, avevano un sistema per rilevare la presenza di amianto. C’era un dispositivo dotato di software per rilevare l’amianto in questo edificio. Da qualche parte esiste un’azienda che si occupa di questo. Queste possono essere nicchie molto specifiche che possono sembrare piccole, ma se si guarda al mercato globale, non lo sono affatto.
Queste nicchie super piccole potrebbero valere qualche centinaio di milioni di dollari a livello mondiale, e un’azienda avrebbe la possibilità di conquistare il 50% della quota di mercato perché non ci sono concorrenti. L’alternativa è che le persone usino metodi tradizionali con penna e carta.
Conor Doherty: Nel corso di questi 10 anni, avendo visto una vasta gamma di esempi differenti, ci sono delle best practice e worst practice generali che hai notato in termini di software o startup? Iniziamo con le cose da evitare e concludiamo su una nota positiva. Quindi, cosa è assolutamente da evitare?
Joannes Vermorel: Se non ti importa della tua tecnologia, finirà per ritorcersi contro di te. La mancanza di cura è letale. Ogni volta che vedo aziende in cui alle persone non importa la tecnologia, di solito il risultato è che la tecnologia è una completa schifezza.
Conor Doherty: Definisci cosa intendi per “non curarsene”. Vuol dire che non sono interessati a imparare a riguardo, o l’avevano fatto una volta e poi hanno smesso, o è una mancanza di competenza? Cosa intendi esattamente?
Joannes Vermorel: Il modo migliore per descriverlo è: quando il CTO fa la doccia, pensa alla sua tecnologia oppure al golf? Le persone che si interessano veramente hanno una sorta di intensità. Non si ferma all’orario d’ufficio; va oltre. Sono estremamente curiose, desiderose e appassionate. Vogliono veramente fare la cosa giusta. C’è un elemento di leggera follia in cui non si tratta solo di fare ciò che è giusto per il cliente, ma anche di fare ciò che è giusto per la tecnologia stessa.
Stai progettando qualcosa che sia davvero bello? C’è un aneddoto su Steve Jobs. Voleva che l’iPhone fosse bello anche all’interno. Quando lo smonti, i componenti all’interno dell’iPhone risulterebbero eleganti, con la giusta scelta di colori e dettagli. Questo grado di cura riflette il fatto che tieni veramente a cuore non solo l’aspetto esteriore, ma anche le parti tecnologiche che nessun cliente vedrà mai.
Quando le persone non si preoccupano, le cose vanno davvero male. Il peggio è probabilmente quando le aziende tecnologiche esternalizzano lo sviluppo delle loro tecnologie a collaboratori freelance. Non importa quanto siano bravi o meno quei freelance; il risultato finale è che la tecnologia diventa solitamente un completo disastro.
Conor Doherty: Penso che la maggior parte delle persone sia d’accordo sul fatto che la passione intrinseca e la volontà di fare bene una cosa siano qualità fantastiche. Detto ciò, se hai solo 20 minuti con il CTO, come valuti quegli intangibili senza una lista di controllo?
Joannes Vermorel: Qualcuno che ha intensità mi dirà: “Abbiamo scelto questa tecnologia per questa ragione.” Conoscono il perché. Non è semplicemente, “avevo bisogno di un’interfaccia web, quindi ho scelto questa.” Hanno opinioni ben precise sulle loro scelte tecnologiche. Le persone appassionate hanno così tante opinioni che traspaiono da ogni cosa. Non riescono a farne a meno. Ogni volta che mi confronto con una parte della tecnologia, mi dicono: “Lo facciamo in questo modo per queste ragioni.”
Conor Doherty: È la passione ciò che conta.
Joannes Vermorel: Sì, e si può percepire l’intensità del loro pensiero. Non si tratta solo di una tecnologia fatta perché c’erano dei requisiti. Le persone che producono codice all’infinito hanno un approccio molto meccanico, in cui i requisiti arrivano dal team commerciale e vengono implementati così come sono. Quella è una ricetta per una tech stack che è una completa schifezza.
Conor Doherty: Per esempio, se avessi auditato Steve Jobs in passato e lui ti avesse detto, “Guarda l’interno di questo telefono, l’ho fatto bello,” il tuo memorandum avrebbe detto che era appassionato, ma che è una follia spendere soldi per questo.
Joannes Vermorel: No, no. La domanda è: sembra che cerchino distrazioni, o fanno semplicemente quel tocco in più? Queste cose potrebbero non costare molto. È solo questione di intensità. Fai qualche percento in più in modo che il tutto sia davvero solido e ben rifinito. Non è follia. Le persone che esagerano solitamente sperimentano un effetto “second system”. È quando un team di ingegneri, al secondo tentativo, investe eccessivamente in cose non necessarie perché il primo progetto è fallito a causa di una tecnologia scadente.
Il caso più frequente è quando le persone investono troppo in scalabilità che non servirà loro a breve. Dicono: “Guarda la nostra splendida architettura; può gestire 10 milioni di utenti.” Quanti utenti hai in questo momento? “Oh, 200.” C’è un grande divario tra ciò che serve e l’eccessiva ingegnerizzazione.
Inoltre, le persone hanno pazienza per le cose sbagliate. Hai una pazienza che si dedica a una certa eleganza e bellezza della tecnologia in sé, o stai seguendo qualche tipo di dogma? Nell’industria del software ci sono in circolazione ogni sorta di dogmi. Dobbiamo farlo come in Scrum, oppure adottare lo sviluppo guidato dal dominio, o lo sviluppo guidato dai test, o utilizzare i microservizi. Ci sono molte opinioni da guru nell’industria del software, e c’è chi è un fanatico per questo. Quando dico intensità, intendo persone che amano ciò che stanno creando ma che non sono fanatismi di un’ideologia specifica. I fanatici fanno cose che non combaciano nemmeno con i loro requisiti pratici. Dicono: “Oh, ma lo dobbiamo fare così perché è il design guidato dai test.” Il fatto che sia il design guidato dai test non giustifica farlo in quel modo. Ha davvero senso procedere così rispetto ai problemi che hai?
Conor Doherty: E per quanto riguarda le best practices, non dire semplicemente il contrario di ciò che hai appena detto. Ci sono cose che, appena le vedi, ti fanno pensare, “Oh, è un buon segno”?
Joannes Vermorel: Scrittura chiara. L’hai già detto. Scrittura chiara. Ogni singolo elemento deve essere essenziale, preciso e conciso. Hai pagine di commenti nel codice che sono solo burocratici, come, “Oh, dobbiamo commentare questo”? Esiste un template, e hai una pagina di commenti che nessuno leggerà? Oppure hai commenti super concisi che sono molto interessanti? Solo leggendo un commento si fa luce su tutto il file di codice. Quando esamino i ticket, la tua descrizione del problema è scritta in modo molto chiaro, o è un caos incomprensibile? Quando hai una sfida tecnica, c’è una discussione molto articolata del problema e delle possibilità, oppure ti ritrovi con una slide pessima piena di punti elenco assurdi che non dicono nulla? La qualità della scrittura è uno dei segnali rivelatori. Un altro segnale è quando le persone usano tecnologie insolite che, però, si rivelano comunque scelte molto valide. Se usano una tecnologia insolita, molto spesso è solo per ignoranza. Non sapevano che esisteva una soluzione molto più mainstream che sarebbe stata decisamente migliore. Di solito è un aspetto negativo, ma quando si scopre che una tecnologia relativamente rara è sorprendentemente adatta a ciò che stanno facendo, è molto positivo. Significa che hanno esplorato il panorama tecnologico, specialmente quello open-source, in modo molto approfondito. È davvero bello. Oggigiorno, nessuno rimarrebbe sorpreso se le persone dicessero: “Oh, stiamo usando Python, PostgreSQL, Tailwind per CSS, React.” Questi sono componenti che ogni ingegnere del software almeno medio conosce. Ma se conoscono qualcosa di super specifico che si adatta davvero al loro problema, anche quello è molto interessante.
Conor Doherty: Bello. Beh, siamo stati in conversazione per circa un’ora. Tengo conto del tempo, quindi per concludere, hai qualche pensiero finale che vorresti condividere con tutti?
Joannes Vermorel: Sì. Penso che ciò che mi sorprende di più in questo decennio di audit sia quanto spesso le aziende tech possano letteralmente trascorrere anni e talvolta round consecutivi di investimenti senza che nessuno si soffermi sulla tecnologia. Si potrebbe pensare che Theranos, quel grande inganno, fosse un’eccezione. Un investimento così massiccio, e nessuno ha fatto la dovuta diligenza sulla tecnologia. Ma la cosa divertente è che è la norma. Per me, ciò che è davvero intrigante è quanto siano rari questi audit tecnologici. Quando parlo con quei fondatori di startup, di solito mi dicono: “Non avevamo idea che avresti fatto questo tipo di domande.” Pensano che verrò con una lista di controllo assurda e stupida. Immagina Theranos; le persone avrebbero facilmente ingannato la lista di controllo. C’erano molte liste di controllo in circolazione, tipo, “Sei conforme a questo e a quello?” Sì, sì, sì, sì. Ma la domanda fondamentale, quella che contava, era: “La tua tecnologia per l’analisi del sangue è reale?” Nessuno fece quella domanda. Era tutto super basilare.
Conor Doherty: Questo ritorna al punto che avevi fatto prima sul “skin in the game”. Se i venture capitalist devono investire milioni nella tua azienda, hanno “skin in the game”.
Joannes Vermorel: Quello che trovo davvero sorprendente è che di solito, anche se arrivo al terzo round, nessuno ha esaminato seriamente lo stack tecnologico. È molto strano. Hai auditor che si limitano a spuntare caselle, ma secondo me quei controlli non contano. Fanno solo finta di lavorare. Non fanno nulla di sostanziale. È facilissimo ingannare queste persone perché tutto ciò che serve è mentire. Basta dire: “Lo fate?” “Sì, lo facciamo.” “Mostraci.” Mostri qualcosa che non ha alcun senso. L’auditor non è una persona tecnica, quindi potresti mostrargli qualsiasi cosa, e lui direbbe semplicemente: “Ok, casella spuntata.” Alla fine di questi audit, è davvero intrigante. Nei normali audit, l’auditor dice: “Per favore, firma questo documento che attesta che non ci hai mentito, e se hai mentito, decliniamo ogni responsabilità.” Personalmente, non lo farò mai. Non presumo che le persone mi dicano la verità. Ecco perché voglio vedere il codice sorgente. Sì, puoi ingannarmi e dirmi un sacco di cose, ma quando esaminiamo il codice, falsificare un codice, falsificare migliaia di commit, centinaia di ticket, e tutti i documenti di supporto, è molto più difficile. Quello che mi sorprende è che il costo sia di un solo giorno di audit. Sì, non sono esattamente economico, ma comunque, è un giorno. Anche dopo aver fatto questi audit per più di un decennio, noto ancora che quando arrivo, anche al secondo o terzo round, nessuno ha messo realmente in discussione la tecnologia. Le persone presumono semplicemente che sia buona, che funzioni, e seguiranno la loro roadmap. Nessun controllo di alcun tipo. Per me, è piuttosto sconcertante.
Conor Doherty: Beh, si spera che qualcosa di cui abbiamo discusso oggi faccia la differenza, forse anche ispiri alcune persone a contattarti. Credo che tu sia disponibile anche per bat mitzvah e compleanni.
Joannes Vermorel: Sì.
Conor Doherty: Bene, Joannes, ti ringrazio moltissimo per il tuo tempo e per aver risposto a tutte le mie domande. Grazie infinite, e grazie per averci seguito. Ci vediamo la prossima volta.
