00:00:00 Introduzione agli audit tecnologici delle startup
00:01:42 Come i VC hanno portato Joannes agli audit tecnici
00:03:24 Gli audit tecnici come fonte di reddito
00:05:08 Valutare il software nelle startup
00:06:36 L’esperienza di Joannes nell’apprendimento automatico
00:08:50 Aspetti chiave di un audit tecnico
00:10:02 Trade-off tra sicurezza e correttezza
00:11:46 Scrivere report per gli investitori in modo efficace
00:14:57 Valutare le startup al di là delle checklist
00:17:04 Adattare gli audit al contesto aziendale
00:20:24 Intervistare i CTO e revisionare il 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 pericolo nella qualità del codice
00:33:47 Intuizioni dalla storia dei commit
00:37:03 Sostenibilità dei costi cloud
00:42:14 LLM che sconvolgono le startup di NLP
00:46:29 Trovare nicchie di software redditizie
00:50:32 Rischi del debito tecnico
00:55:34 Sovrinvestire nella scalabilità
00:59:59 Una scrittura chiara indica una buona ingegneria
01:04:08 Perché gli audit tecnici 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, sulla sua esperienza decennale nel condurre audit tecnici delle startup. Gli ‘audit tecnici fulminei’ di Vermorel offrono ai venture capitalist valutazioni esperte degli stack tecnologici, discostandosi dai metodi tradizionali concentrandosi su valutazioni dinamiche e specifiche del contesto. Il suo processo prevede valutazioni intensive di un giorno, comprese interviste con i CTO e i 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. Le sue intuizioni rivelano significative lacune nel settore e mettono in evidenza 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 presso Lokad, si è seduto con Joannes Vermorel, CEO e Fondatore di Lokad, per approfondire una delle attività meno conosciute ma altamente impattanti di Joannes: svolgere audit tecnici delle startup. Nel corso dell’ultimo decennio, Joannes ha condotto questi audit, fornendo ai venture capitalist pareri esperti sugli stack tecnologici degli investimenti potenziali. Questa pratica, che Joannes definisce ‘audit tecnici fulminei’, gli ha fornito un punto di vista unico sulle migliori e peggiori pratiche all’interno dell’industria tecnologica.
Joannes ha iniziato il suo percorso negli audit tecnici nei primi anni di Lokad quando stava considerando di coinvolgere i venture capitalist. Anche se alla fine ha deciso di non accettare investimenti formali, le sue interazioni con gli investitori lo hanno portato ad offrire la sua esperienza nella valutazione degli aspetti tecnologici di altre startup. Questa svolta gli ha permesso di trasformare ciò che avrebbero potuto essere incontri dispendiosi in preziose opportunità di vendita, offrendo i suoi servizi ai venture capitalist che avevano bisogno di un parere esperto sugli stack tecnologici delle aziende che stavano considerando per gli investimenti.
Il nucleo del processo di audit di Joannes è una valutazione intensiva di un 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 al contesto specifico di ciascuna startup. Inizia con un’intervista di 20 minuti con il CTO per comprendere il panorama tecnologico dell’azienda e poi trascorre il resto della giornata conducendo interviste individuali con il team di ingegneria. Questo approccio pratico gli permette di valutare non solo la qualità del codice, ma anche la fluidità e coerenza del team nel navigare nella propria tecnologia.
Joannes sottolinea che il suo obiettivo non è diventare un esperto nella tecnologia dell’azienda, ma valutare se il team è funzionale e se la traiettoria tecnologica è sana. Cerca pattern nel codice, nella storia dei commit e nella qualità della documentazione. Ad esempio, può rapidamente valutare la qualità del codice guardando la coerenza degli stili di codifica e la chiarezza dei messaggi di commit. Valuta anche se il team sta facendo un uso saggio delle proprie risorse limitate, un fattore critico per le startup.
Una delle intuizioni più sorprendenti condivise da Joannes è la frequenza con cui le aziende tecnologiche possono passare attraverso molteplici round di investimento senza che nessuno abbia mai dato un’occhiata seria alla loro tecnologia. Trova sconcertante che anche nei round di investimento successivi, lo stack tecnologico rimanga spesso incontestato. Questa mancanza di dovuta diligenza può portare a significative mancanze, come è stato famosamente il caso di Theranos.
Joannes ha anche discusso dell’importanza della passione e della cura nello sviluppo tecnologico. Crede che la mancanza di cura sia un killer per le aziende tecnologiche. Quando il CTO e il team di ingegneria sono genuinamente appassionati della propria tecnologia, ciò si riflette nella qualità e coerenza del loro lavoro. Al contrario, quando le aziende esternalizzano lo sviluppo ai freelance o mancano di un impegno profondo nella propria tecnologia, i risultati sono spesso disastrosi.
Per quanto riguarda le migliori pratiche, Joannes ha sottolineato l’importanza della scrittura chiara e della documentazione. Che si tratti di commenti nel codice o dell’articolazione delle dichiarazioni di problema nei ticket, chiarezza e concisione sono indicatori chiave di un team ben funzionante. Valuta anche l’uso di tecnologie insolite ma ben adatte, che possono indicare una profonda comprensione del panorama tecnologico e un impegno nel trovare le migliori soluzioni.
L’approccio di Joannes agli audit tecnici è una piacevole deviazione dalla norma, concentrandosi sulle realtà pratiche e sui bisogni specifici di ciascuna startup. Le sue intuizioni offrono preziose lezioni sia per gli investitori che per gli imprenditori tecnologici, sottolineando l’importanza della passione, della chiarezza e di un approccio personalizzato allo sviluppo tecnologico. Mentre l’industria tecnologica continua a evolversi, il metodo di Joannes degli audit tecnici fulminei fornisce un solido quadro per valutare il vero potenziale delle innovazioni tecnologiche.
Trascrizione Completa
Conor Doherty: Bentornati su LokadTV. Oggi sarò in studio con Joannes Vermorel, fondatore e CEO di Lokad. Discuteremo di una delle sue missioni secondarie uniche: svolgere audit tecnici delle startup. Pochi sanno effettivamente che per circa un decennio, Joannes ha valutato aziende software, controllando tutto, dal codice e dall’infrastruttura allo staff e alla leadership stessa. Io e lui discuteremo alcune best practice e cosa ha imparato lungo il cammino. Ora, come sempre, se vi piace ciò che sentite e apprezzate ciò che facciamo, iscrivetevi al canale YouTube e seguici 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 solita materia ma di qualcosa che penso sia comunque di notevole interesse. Fai molti audit tecnici, è corretto?
Joannes Vermorel: Sì, e è così da oltre un decennio, probabilmente quasi 14 anni o giù di lì.
Conor Doherty: E come è successo esattamente? Perché, di nuovo, chiunque abbia guardato LokadTV - cosa sono adesso, il settimo o forse ottavo anno, forse Max fuori campo può confermare - è familiare con te che parli di supply chain e di tutta la tecnologia coinvolta in questo. Ma questa è probabilmente la prima volta che qualcuno ne sente parlare, eppure hai appena detto che lo fai da 10 anni. Quindi, per quanto riguarda le missioni secondarie, è stata una sottile. Come è successo esattamente?
Joannes Vermorel: Nei primi anni di Lokad, stavo considerando l’idea di prendere investimenti, sai, portare a bordo venture capitalist. È emerso che non ho mai portato investitori formali in azienda, ma nei primi anni di Lokad, ho parlato con parecchi di loro. Dopo un po’, sai, il modo in cui va è che o mandi una mail o ti mandano una mail dicendo, “Oh, prendiamo un caffè o qualcosa del genere.” Ci vuole tempo per incontrare gli investitori per discutere della tua azienda e se sarebbero interessati a investire e così via. Ci vuole tempo, e ad un certo punto, pensavo, “Ok, sto spendendo tutto questo tempo incontrando questi potenziali investitori, e questo è tempo che sto spendendo non costruendo, non vendendo.” Così ho pensato, “E se invece gli vendessi qualcosa?” Quindi, sai, trattare quegli incontri con i venture capitalist come incontri di vendita. È emerso che ho accennato a quelle persone che se fossero interessate - quindi non ero un lead super caldo per loro perché non stavo cercando disperatamente denaro - ma dicevo loro che Lokad potrebbe non essere la loro startup ideale perché non sto cercando disperatamente denaro. Ma se cercavano qualcuno per forgiare un’opinione esperta su un altro investimento, potevo essere la persona giusta. La mia specialità non era dare un’occhiata ad un’altra startup e giudicare se avrebbero fatto soldi - è al di là della mia competenza, è molto difficile. Ma ciò che rientrava pienamente nella mia competenza era avere un’opinione informata sul loro stack tecnologico. È emerso che quando sei un venture capitalist e investi in aziende tech, una grande parte della valutazione per molte di quelle aziende è la tecnologia che stanno sviluppando. La tecnologia è veramente preziosa? Vale la valutazione pre-money che i fondatori stanno chiedendo? E così, ecco, ho iniziato a fare quegli audit tecnici. Ne ho fatti circa uno, a volte due al mese per, di nuovo, penso che siano stati 12 o 13 anni, quindi è stato parecchio tempo. E così ho fatto molte aziende, e il formato di quegli audit è molto breve. A proposito, chiedevi come faccio a trovare il tempo per farlo. Beh, ho sempre mantenuto quegli audit come audit tecnici fulminei; tutto viene fatto in un giorno.
Conor Doherty: Torneremo sicuramente su questo perché ci sono implicazioni per l’approccio. Approfondiremo come il tuo approccio differirebbe da quello che la maggior parte delle persone considererebbe lo status quo per ciò che essenzialmente equivale a un servizio di consulenza. Tuttavia, solo per inquadrare correttamente questo, poiché hai usato il termine “opinione esperta” e “competenza”, per chi non è familiare con ciò che ti qualifica per questo ruolo, sentiti libero di delineare i tuoi numerosi allori.
Joannes Vermorel: Sono appassionato delle tecnologie software da molto tempo. Ho iniziato a programmare alle elementari, ho trascorso la maggior parte della scuola media e superiore migliorando la programmazione con cose più sofisticate, e sono sempre stato estremamente interessato a tutto ciò che riguarda il software. Al momento in cui ho iniziato a fare quei audit, non avevo ancora 30 anni ma ero vicino, e in quel momento avevo già quasi un decennio di esperienza professionale nel software con i miei progetti software ma anche altri progetti che avevo fatto all’università e in altre aziende.
Conor Doherty: Hai anche lavorato in America per un po’ di tempo presso AT&T Labs. È stato un periodo in cui erano veri pionieri nel machine learning. Hanno iniziato a fare machine learning già negli anni ‘90.
Joannes Vermorel: Sì, erano già su quelle cose di machine learning molto prima che l’intelligenza artificiale diventasse cool e di tendenza. C’erano persone che lavoravano su queste cose, ma di nuovo, quella era solo una parte del mio interesse. Quando faccio audit alle aziende, molto spesso il machine learning è solo una piccola parte dei problemi. Molto spesso, non fa nemmeno parte del problema. Queste aziende possono essere di tutti i tipi. Ci sono aziende software, ma possono essere qualsiasi cosa, da un’azienda biotech che utilizza ampiamente il software, al gioco d’azzardo online, a un’app di produttività B2B, a un software embedded che va in un apparecchio situato in una sala operatoria di un ospedale. Il software si presenta in una vastissima gamma di situazioni, e le tecnologie che vanno in quelle startup variano enormemente da un’azienda all’altra, anche se il nucleo è sempre il software. È lì che penso risieda veramente la mia competenza.
Conor Doherty: Quando parli di effettuare audit tecnici, penso che le persone probabilmente abbiano un’idea di cosa sia. Ma cosa esattamente comporta? Su quali aree ti concentri? Stai valutando solo il software? Stai valutando le persone? Cosa comporta esattamente?
Joannes Vermorel: Il prodotto finale, perché dobbiamo partire da ciò che viene consegnato, è un memo che consegno all’investitore. Un venture capitalist sta per investire in una startup. Di solito hanno già firmato una lettera d’intenti. Stanno per investire da 2 a 20 milioni, a volte di più, di dollari o euro in un’azienda. Una grande parte della valutazione sono le tecnologie in cui stanno investendo. Stanno investendo in un team che ha presumibilmente già sviluppato qualcosa. Non faccio quegli audit per il seed stage; 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 ciò che chiedono quelle persone? Il valore non è solo ciò che hanno, ma anche la dinamica tecnologica all’interno dell’azienda in modo che saranno in grado, se ottengono i soldi dall’investitore, di 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 previsioni finanziarie saranno corrette. La mia competenza non risiede nel futuro dei mercati del gioco d’azzardo, per esempio. Non lo so. Questo è per altre persone valutare. Ma se mi mostrano un’app per il gioco d’azzardo, dobbiamo verificare se sarà sicura perché se stiamo parlando di gioco d’azzardo, ad esempio, deve essere estremamente sicura. Questo è il tipo di domanda a cui posso rispondere. Se è un apparecchio che verrà utilizzato durante un intervento chirurgico, allora la correttezza è assolutamente vitale. Letteralmente, se la cosa funziona male, potresti potenzialmente uccidere un paziente. Le sfide sono molto diverse.
Conor Doherty: Solo per tornare indietro, quando hai dato l’esempio lì, ho capito quello sulla sicurezza e ovviamente con il tuo giubbotto, ma l’idea dell’attrezzatura medica, qual è il tuo contributo in termini di valutare quella correttezza? Farà in modo affidabile ciò che dovrebbe fare?
Joannes Vermorel: Non è come un problema di sicurezza perché quelle cose saranno isolate dalla rete. Saranno utilizzate in un ambiente che è già molto sicuro dal punto di vista IT, senza connessione di rete, queste cose. Ma la domanda è, come assicurarsi di non avere problemi, bug o qualsiasi cosa possa compromettere il fatto che la cosa funzionerà? Molte macchine ora sono automatizzate. Se opera una pompa che pompa qualche tipo di liquido nel paziente, come fai a essere sicuro che non stia funzionando male, che faccia esattamente ciò che vuoi che faccia? Quindi, in sostanza, il modo in cui affronto il risultato è formando un’opinione. Questo sarebbe un memo che restituisco all’investitore su cosa penso, sai, qual è la mia opinione generale sul valore di questa azienda nei suoi termini. Ed è davvero la cosa importante. Sto cercando di formare un’opinione su quanto vale l’azienda in base a ciò che stanno cercando di raggiungere. Se stai sviluppando un videogioco, la domanda è, stai sviluppando qualcosa di molto coinvolgente, divertente, ecc.? Questi sono i tuoi termini di impegno. Se stai sviluppando una biotecnologia in cui hai una nuova tecnologia diagnostica che dovrebbe permetterti di diagnosticare una patologia in modo più precoce e veloce rispetto a un metodo alternativo, funziona? È reale? Hai delle statistiche valide? Hai tutti i processi che sembrano indicare che i tuoi risultati empirici sono esattamente come dovrebbero essere? Se abbiamo un’applicazione di produttività, la domanda è, per un’applicazione B2B, come affronti il fatto di avere centinaia, potenzialmente migliaia, di funzionalità o micro-funzionalità? Questo è il problema con le applicazioni enterprise; quelle cose possono essere come un labirinto di funzionalità perché hai così tanti casi da gestire. Come fa l’azienda a gestire tutta questa complessità? Stanno solo annegando sotto la propria complessità, o la gestiscono bene? È ben organizzato? A seconda del tipo di startup che finisco per auditare, i termini di impegno, qual è la proposta di valore, qual è l’essenza del valore, sono molto diversi. Il mio risultato è formare e riflettere un’opinione che restituisco all’investitore su ciò che conta di più. Se c’è qualcosa che vedo durante questo audit che comprometterebbe la consegna di questo valore fondamentale, lo segnalo.
Conor Doherty: Di nuovo, hai detto che lo fai da circa 10 o 12 anni. Supponendo uno o due al mese, stai parlando di almeno più di 100 eseguiti. Quindi, qual è il grosso? Perché hai delineato, beh, potrei guardare un’app per il gioco d’azzardo, potrei guardare attrezzature mediche. Ovviamente, questi settori sono molto, molto diversi. Quindi, la maggior parte del tuo lavoro sarebbe stata in o qual è il tipico clima quando fai un audit?
Joannes Vermorel: Sono davvero aziende software. Sono persone che sviluppano software. A volte c’è un elemento fisico, sai, che possono essere persone che sviluppano software per un pezzo di attrezzatura. A volte c’è più o meno software di terze parti da integrare. È un’applicazione che funziona da sola, o è integrata in molte altre cose? Molte situazioni. Voglio dire, ovviamente, probabilmente due terzi di ciò che ho fatto è B2B o attrezzature professionali, e un terzo sarebbe B2C. Ma questo è tutto per quanto riguarda la classificazione; altrimenti, è estremamente diversificato.
Conor Doherty: Beh, ci hai dato una visione efficace dei risultati e del tuo background. Ma in termini di passaggi principali, come formi un’opinione e rifletti su quali sono i passaggi coinvolti nel giungere effettivamente a quel memo e a quell’opinione?
Joannes Vermorel: Qui il mio approccio si discosta ampiamente da ciò che le persone considerano di solito come un processo di audit. Solo per far capire al pubblico, un revisore, direi il 99% delle persone che fanno audit di qualsiasi tipo, hanno delle checklist. Hanno le loro lunghe checklist con diverse centinaia di domande, e andrebbero dall’azienda e chiedere, “Fate questo o quello?” Sì, no, sì, no, ecc. Il revisore passa semplicemente attraverso l’elenco come un drone. Il mio punto di vista è che questo processo è assolutamente insensato per gli audit tecnologici, specialmente per le startup.
Il problema è che questa lista, qualunque essa sia, non metterà mai alla prova la startup nei suoi termini. È completamente irrilevante mettere alla prova, diciamo, un’azienda che fa giochi su quanto sia 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 investire pesantemente in funzionalità di sicurezza che complicano la vita degli utenti? Se stai facendo giochi casuali, ad esempio, non ha senso. A nessuno importa del fatto che tu stia giocando a Farmville.
In conclusione, avere delle checklist è una ricetta per essere un enorme spreco di tempo per i fondatori e una distrazione enorme per gli investitori stessi. Potrebbero dire, “Oh, la startup è conforme a centinaia di elementi irrilevanti,” e poi tu diresti, “Oh, ma non sono conformi su questi 100 elementi,” che sono anch’essi completamente irrilevanti per il successo dell’azienda. Il mio punto di vista è che hanno un caso aziendale; dicono che vogliono andare in una certa direzione dal punto di vista aziendale. Lascio che siano gli altri a valutare se c’è del denaro da guadagnare. Io non valuto questo. Voglio dire, sì, ho la mia opinione su se sembra plausibile, ma non metto in discussione le dimensioni del mercato. Il mio punto di vista è che, ok, supponiamo che ci sia un mercato e che se esegui questa cosa in modo eccellente, ci saranno persone da servire, e queste persone saranno disposte a pagarti.
Ora la vera domanda è, riuscirai a mantenere la tua promessa? Stai sviluppando una tecnologia che dovrebbe fare qualcosa. Riuscirai a mantenere ciò che stai promettendo?
Conor Doherty: E sei in grado di fornire quel livello di approfondimento. Puoi speculare sulla tecnologia e…
Joannes Vermorel: Rispetto a un revisore, se torno alla checklist, il mio punto di vista è che quando inizio la giornata, durante i primi 20 minuti, intervisterò tipicamente il CTO. L’idea è che entro 20 minuti, devo progettare mentalmente una serie di domande per guidare la discussione verso le cose di maggiore interesse. Dopo i 20 minuti di presentazione, tipicamente fatta solo da una conversazione informale, conduco il resto della giornata attraverso una serie di interviste in cui c’è qualcuno di fronte a un computer che mi mostra la loro base di codice. Conduco una serie di interviste uno a uno in cui entrambi guardiamo lo stesso schermo, e un dipendente dell’azienda funge da mia guida attraverso la loro base di codice.
Conor Doherty: Quindi, tu sei Virgilio.
Joannes Vermorel: Sì, mi stanno guidando attraverso la loro base di codice. Non chiedo una copia della base di codice perché potrebbe creare un sacco di problemi e rendermi responsabile della proprietà intellettuale. L’idea è che voglio dare un’occhiata alla base di codice, ed è così che guardo la tecnologia. Ma le basi di codice possono essere estremamente estese. Anche una piccola azienda con cinque ingegneri del software che lavorano per un paio d’anni può facilmente avere 100.000 righe di codice o più. Se dovessi navigare in questa base di codice da solo, il 90% del mio tempo sarebbe sprecato a capire la strada. Quindi, ho un ingegnere seduto accanto a me, e faccio domande, e mi mostrano il codice. Rivediamo il codice insieme, ovviamente un campione del codice; non possiamo rivedere l’intera base di codice.
Conor Doherty: Date le potenziali postazioni finanziarie qui, perché non guarderesti semplicemente questo con il CTO?
Joannes Vermorel: Prima di tutto, il CTO non è necessariamente esperto di tutte le parti della base di codice. Se è un team di cinque persone, compreso un CTO, allora probabilmente sì, il CTO è competente su tutta la base di codice. Se stai parlando di un’azienda in una fase successiva con 20 ingegneri, molto probabilmente il CTO non è competente su ogni segmento della base di codice. Ma più in generale, è anche molto interessante per me avere altre persone dell’azienda sedute accanto a me perché posso vedere quanto sono fluenti con la base di codice. Sono persi nella propria tecnologia? Quando faccio una domanda di base come, “Come accedi al tuo livello persistente?” o “Come accedi ai dati che hai registrato?” Se le persone non hanno idea, non è buono. Se chiedo loro, “Qual è l’ultima cosa che hai fatto?” e dicono, “Ho sviluppato questa funzionalità,” e sono persi nel cercare di mostrarmi su cosa stanno attualmente lavorando, non è buono.
Intervistare il CTO è buono, ma devo anche valutare se il team è all’altezza del CTO. Questo può andare in entrambi i modi. A volte il CTO è molto bravo, ma il resto del team non è così bravo. A volte è il contrario. A volte il CTO è molto debole, ma il resto del team è effettivamente abbastanza forte. Varia, e questo farà parte delle opinioni che darò all’investitore come parte di questa nota per le consegne. Ho anche un’opinione su se i contributori attualmente parte dell’azienda siano all’altezza della sfida per la prossima fase. Se l’investimento avviene, a volte quando un’azienda inizia, il loro budget è estremamente limitato, e scelgono persone non super talentuose in termini di tecnologia. Questo accade frequentemente quando il fondatore non è un fondatore tecnico. Quando il fondatore è qualcuno che aveva conoscenze interne, che sa che c’è un problema specifico che deve essere affrontato, e questa persona vede una necessità e disponibilità a pagare. Questo accade molto frequentemente nei mercati B2B. Ma questa persona non è tecnica, quindi prendono il primo ingegnere del software che possono trovare. Potrebbero non avere un grande budget, quindi la loro prima assunzione potrebbe essere qualcuno il cui principale vantaggio è essere molto economico.
Di nuovo, va bene, va bene. Voglio dire, stai partendo da zero. Hai, diciamo, €20.000, li stai mettendo nell’azienda. Per te, è già un bel investimento. Grazie a quei €20.000, riesci ad avere come un mezzo milione di seed. È buono. Puoi avere il tuo team di, diciamo, due ingegneri del software per sviluppare il prodotto. Poi vuoi passare alla fase successiva e ora avere il primo round di, diciamo, €3 milioni. Beh, a questo punto, se stiamo parlando di un investimento multimilionario, è una fase in cui ora hai i soldi per avere un vero talento in termini di ingegneria del software. Quindi la domanda è, i giocatori che hai attualmente sono all’altezza della sfida per il prossimo livello, la prossima fase dell’azienda? Quindi anche questo, non è l’unica domanda, ma è anche una delle domande che vengono esaminate.
Conor Doherty: Solo per essere chiari, come parte della nota, del prodotto consegnabile, potresti potenzialmente fare raccomandazioni su chi dovrebbe restare e chi no?
Joannes Vermorel: Sì, sì. Di nuovo, è tutto ciò che potrebbe aiutare o compromettere il valore tecnologico dell’azienda, il suo percorso tecnologico. A volte hai i giocatori sbagliati. Voglio dire, avevi i giocatori di cui avevi bisogno per vincere un super campionato locale, ma se vuoi giocare a livello nazionale o addirittura puntare al campionato del mondo, allora forse hai bisogno di giocatori diversi. Portare più soldi cambia le dinamiche. Improvvisamente, potresti permetterti persone molto più esperte, molto più talentuose. Varia. A volte le persone sono molto talentuose, ma per qualche motivo la dinamica in azienda è terribile. A volte possono esserci due CTO per qualche motivo. È successo in alcune verifiche. Quindi hai due responsabili tecnologici, e queste due persone stanno perseguendo roadmap diverse. Allora il mio messaggio è, scegli uno. Non puoi rimanere completamente schizofrenico; devi scegliere. Questa sarebbe una decisione aziendale perché sono mercati diversi che stai cercando di conquistare. Ma in definitiva, è il tipo di problema in cui un investitore deve sapere se c’è qualcosa che non va con la tecnologia o se ci sarà qualcosa di sbagliato in futuro con la tecnologia. Perché a volte non c’è ancora un problema, ma aggiungere denaro è come aggiungere benzina al fuoco. Se hai qualcosa di leggermente disfunzionale, se inizi a versarci sopra un paio di milioni, ciò che era un piccolo problema potrebbe essere amplificato enormemente dall’investimento stesso. Quindi anche questo può essere un problema. Di nuovo, non c’è una checklist per me, non ci sono regole. È tutto ciò che vedo che ha senso in termini di problemi da risolvere o raccomandazioni per l’investitore. Questo fa parte del mio campo di azione. L’idea è che tengo questa missione come di un giorno perché non ho il tempo di fare molto di più. Ma anche perché i fondatori stessi sono molto occupati. Penso che parte del problema con le verifiche classiche sia che sono una tale perdita di tempo. Ci vogliono settimane, paralizzano completamente l’azienda, e non ne esce nulla di buono.
Conor Doherty: Beh, su questo punto in realtà, quindi stai dicendo che non usi una checklist, miri a entrare ed uscire in meno di un giorno. Quando dici un giorno, intendi un giorno lavorativo. Quindi stai parlando invece di un processo di diverse settimane, che sono multiple settimane di giorni di 8 ore, stai parlando di forse 8 a 10 ore escludendo taxi e voli, senza usare una checklist, e poi fare raccomandazioni molto importanti su cosa dovrebbe essere fatto con l’azienda, cose che avranno un impatto su altre persone. Devo chiedere, date tutte queste limitazioni, sei semplicemente così brillante, o come fai esattamente a prendere quelle decisioni in un solo giorno senza una checklist?
Joannes Vermorel: Sì, voglio dire, innanzitutto, la base di codice. Se sei abituato a leggere molti codici, queste cose diventano estremamente ovvie. In pochi minuti guardando la base di codice, vedi se il codice è ben scritto o semplicemente una schifezza. Di solito ho un’opinione entro 5 minuti di navigazione in quella base di codice. Se sei davvero abituato a leggere molti linguaggi di programmazione e hai visto molte basi di codice, non hai bisogno di ore per forgiare un’opinione su se sia bello, ingegneria stretta, ben organizzato, abbia senso, o se sia solo caos puro e inconsistente. Ad esempio, se vado attraverso una base di codice e vedo stili di codifica radicalmente diversi, dico, “Oh, ok, quindi abbiamo diversi contributori che non hanno alcun accordo condiviso su come dovrebbe apparire il codice.” È davvero brutto. Guardo la storia dei commit? Questo mi dice molte cose. Ad esempio, se vedo che nella storia dei commit, hai un commit per una funzionalità e poi una ventina di commit per correggere bug causati dall’introduzione di questa funzionalità, è super brutto. Questo significa che ogni volta che le persone introducono qualcosa, spenderanno poi molto tempo solo a sistemare le cose che hanno appena rotto. Quindi vedi, solo guardando superficialmente gli ultimi forse 200 commit, puoi vedere se c’è un pattern. Puoi vedere molti pattern. A volte, ad esempio, hai la storia dei messaggi di commit. Questa è l’evoluzione per il pubblico. I commit sono il modo in cui modifichi incrementalmente la base di codice. Fai modifiche 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 domanda è, ad esempio, quando vedi cambiamenti applicati alla base di codice, i cambiamenti hanno senso? Ad esempio, se hai commit in cui il titolo del commit è “più roba,” letteralmente, che cosa è questa schifezza? No, non hai alcune cose che sono state cambiate. Poi, ad esempio, se hai un bug che viene corretto, c’è qualcosa che viene fatto insieme alla correzione del bug per assicurarsi che il bug non venga reintrodotto la prossima volta che tocchi la base di codice? Ci sono molti modi per assicurarsi che il bug non venga reintrodotto. Ti stai occupando di questo? Quando guardi le contribuzioni, i commit, le persone fanno revisioni del codice? Discutono su come dovrebbero essere ingegnerizzate le cose? Di nuovo, la base di codice racconterà una grande storia sia sulla tecnologia che sulla sua storia. Puoi vedere la traiettoria, come si è sviluppata. Poi puoi zoomare nelle parti centrali. Ad esempio, se sei una startup di intelligenza artificiale o di machine learning, il tuo valore principale dovrebbe essere qualche ricetta numerica intelligente che fa qualcosa di molto difficile o altro. Come lo stai facendo? È solo un trucco, o hai una profonda esperienza? Quanto fossato hai? Hai un fossato reale dove replicare ciò che hai appena fatto sarà difficile, o è solo un trucco illusionistico dove stai solo usando qualche tipo di libreria open-source e bam, in realtà nulla è di tua produzione? Hai appena riciclato qualcosa che è nella comunità. Di nuovo, questa è una domanda molto critica per l’investitore perché se le persone dicono, “Oh, abbiamo sviluppato una tecnologia di machine learning unica,” se ciò che stai facendo è essenzialmente riutilizzare un pezzo di open-source, chiunque può farlo. Quindi sì, è figo, sì, funziona, ma l’investitore dovrebbe valutare la tua azienda in modo elevato solo perché hai qualcosa che funziona? Beh, non proprio, perché se è open-source, significa che praticamente chiunque può farlo anche. Quindi nessun fossato. Di nuovo, le cose che sto guardando dipendono davvero dalle specifiche dell’azienda.
Conor Doherty: Puoi anche, anche solo prendendo l’esempio e poi combinandolo con un po’ di aneddoto, se prendi l’esempio di guardare il log dei commit in Git o Bitbucket—noi usiamo Bitbucket—puoi estrapolare parecchio. Ad esempio, anche per noi nel team di marketing, ogni volta che pubblichiamo qualcosa sul sito web, insisti su un log dei commit molto pulito e ordinato. Puoi vedere esattamente cosa è successo, chi l’ha approvato.
Joannes Vermorel: Esatto. E anche, a volte solo il modo in cui le persone interagiscono con me. Sto parlando con una persona, faccio una domanda casuale, questa persona è velocissima nel portarmi subito al posto giusto nel codice? Tipo, “Oh, c’è questa funzionalità che è abbastanza interessante, puoi mostrarmi il codice relativo a quella?” E poi il ragazzo dice, “Oh sì, nessun problema,” bam, direttamente sul punto, proprio nell’implementazione. Questo è molto buono. Quella completa padronanza della base di codice, di come le cose vengono fatte, è molto, molto buona. Quindi a volte solo il modo in cui le persone dimostrano facilità nel navigare nella base di codice mi dice molto. Inoltre, ad esempio, quando introducono funzionalità, hanno ticket ben scritti per giustificarle? Gli ingegneri del software sono disorganizzati e fanno cose con il codice, o hanno qualcosa di ben organizzato dove, “Okay, voglio fare questo, ecco il mio ticket che descrive chiaramente perché voglio farlo,” e poi discuto i diversi modi per farlo, ecc. Quindi dipende, ma di solito è importante dei ticket. Sarebbe tipicamente critico per le app B2B, le app di produttività, perché hai un elenco infinito di funzionalità che sono tutte super specifiche del settore. Se stai facendo un’app enterprise, non dovresti davvero perderti nella quantità infinita di funzionalità che potresti aggiungere alla tua app. Quindi sarebbe molto importante per diversi tipi di aziende. Sarebbe un processo completamente diverso. Ma quello che sto dicendo è che in termini di come puoi forgiarti un’opinione in poche ore? Se stai solo seduto accanto a qualcuno che interagisce con la base di codice, puoi vedere davvero molto. Se stai solo prestando attenzione ai modelli, a ciò che le persone stanno facendo, e sì, è il riconoscimento dei modelli. 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 controlli anche la coerenza, sai. Le persone raccontano la stessa storia in termini di tecnologia? Tipo, chiedo, “Cosa pensi che faccia questo componente?” E se ottengo diverse persone che mi danno storie completamente diverse, dico, “Okay, quindi chiaramente all’interno di questo team, non è molto chiaro che le persone capiscano davvero cosa sta succedendo.”
Joannes Vermorel: Non ho bisogno della verità per riconoscere che le cose sono inconsistenti. Di nuovo, il mio obiettivo non è diventare un esperto in ciò che stanno facendo. Il mio obiettivo è solo valutare se il team è funzionale, la traiettoria in termini di sviluppo della tecnologia è sana. A volte si tratta anche di verificare, ad esempio, che le risorse in termini di risorse di cloud computing siano sotto controllo. A volte ci sono aziende che stanno gestendo male le loro risorse cloud. Il cloud è fantastico, paghi in base all’utilizzo, il che significa che il cielo è il limite. Puoi creare tonnellate di macchine virtuali, tonnellate di storage, tonnellate di tutto. E a volte, sai, alcune aziende esagerano un po’ su questo e finiscono con una traiettoria in cui stanno spendendo troppo su risorse di cloud computing rispetto a quanto dovrebbero.
Conor Doherty: Anche questo 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. Quindi non c’è una regola chiara, ma parte dell’esperienza è valutare quale sia il carico di lavoro che stai cercando di realizzare sul cloud e ha senso che tu stia pagando così tanto? È un risultato, ben fatto, il tuo software è altamente performante, o è terribile e stai solo bruciando denaro? Probabilmente darti tonnellate di soldi extra da bruciare non è la mossa giusta. Dovresti probabilmente risolvere quei problemi prima di ottenere qualche milione in più.
Joannes Vermorel: Se ti manca denaro, non puoi disciplinarti a non bruciare denaro attraverso spese non sagge in risorse computazionali. Le probabilità che diventi saggio una volta che hai molto più denaro sono molto basse.
Conor Doherty: A proposito, abbiamo effettivamente un altro video sul tema delle risorse computazionali, quindi controlla la playlist per quello. Ma parlando di denaro, quando si parla di finanze, so che quando parliamo di supply chain, si parla dell’impatto finanziario del fondo di bilancio di qualsiasi scelta tu stia per fare. Segui lo stesso approccio quando valuti una società tecnologica? Guardi qual è l’orchestrazione più vantaggiosa dal punto di vista finanziario dell’azienda tecnologica o qual è semplicemente la 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 i loro termini.
Joannes Vermorel: Non vuoi, ad esempio, sarebbe pura follia per una piccola azienda ottenere una certificazione ISO. È uno spreco completo di risorse a meno che non sia un mercato iper-regolamentato dove non puoi sopravvivere a meno che non abbia questa certificazione. Quello a cui guardo è quanto sei bravo a fare uso delle tue risorse limitate per ottenere il massimo risultato con il tuo denaro. Parto dal presupposto che la tua direzione sia buona, che alla fine se avrai successo, farai soldi. Ma ancora, se prendo le tue direzioni aziendali per scontate, dico, “Ok, ammettiamo che se questa cosa viene fatta, allora sarai competitivo in questo mercato e ci saranno soldi da fare.” Prendo questo. Ora, ogni dollaro o euro che viene speso per diventare il numero uno in questo mercato, viene speso saggiamente?
Conor Doherty: Assolutamente. Può essere, hai il talento giusto? A volte spendono troppo poco. Succede che a volte l’azienda raggiunge un certo grado di successo e non licenzia le persone che erano state originariamente assunte solo perché erano molto economiche. Questo accade anche abbastanza frequentemente con le startup tecnologiche.
Joannes Vermorel: Specialmente quando il fondatore non è un fondatore tecnico, ma un fondatore commerciale, e poi hai il CTO che era originariamente il primo ingegnere del software mai assunto dall’azienda. Questo accade frequentemente, e questa persona non è al livello. Di nuovo, le eccezioni variano, i risultati possono variare.
Conor Doherty: Esattamente. La mia domanda è, ci sono state situazioni in cui sei entrato per valutare un’azienda, sei lì per valutare tutte le cose di cui hai parlato: il codice, il modo in cui lavora il team, potrebbero concepibilmente raggiungere l’obiettivo utilizzando le risorse che hanno? Ma sei entrato e il loro obiettivo finale era solo assurdo. Ad esempio, è il 2008 e questa azienda è determinata a riportare indietro il nastro VHS, come qualcosa di assolutamente folle che hai una forte opinione sia uno spreco enorme di denaro, tempo e risorse.
Joannes Vermorel: Oh sì, succede. Sentiti libero di farlo, ma non dare nomi.
Conor Doherty: No, il punto è che alcune tecnologie software evolvono piuttosto rapidamente. Ad esempio, negli ultimi due anni, ho auditato diverse aziende che stavano facendo NLP. Queste aziende sono state avviate nel 2018 o 2019, e sono entrate in questa ondata di intelligenza artificiale e hanno sviluppato NLP, tecnologie di elaborazione del linguaggio naturale, ma pre-LLM, pre-modelli di linguaggio di grandi dimensioni. C’era una vasta letteratura di modelli NLP e di apprendimento automatico, 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 in cui la mia conclusione era che questa azienda aveva sviluppato 20 modelli NLP piuttosto sofisticati, erano tutti completamente obsoleti. Gli LLM stanno uniformemente superando tutto questo. Puoi semplicemente gettare via l’intero stack tecnologico e ricominciare da zero con un LLM al centro, sarai migliore. Non c’è nulla da salvare. Succede abbastanza frequentemente, forse una su dieci, una su venti, 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 per diventare, stai risolvendo un problema che è già risolto.
Conor Doherty: Di solito, il punto è che non è assurdità nel senso che quelle persone sono idioti. C’è un problema da risolvere, e hanno sviluppato qualcosa di bello, ma c’è qualcosa di molto meglio che è già stato trovato e possibilmente gratuito. Questa cosa non è ancora popolare, non è ancora molto conosciuta. Penso che LLM sia davvero il caso estremo in cui le persone, quelle aziende erano un po’ disperate perché sapevano che gli LLM stavano arrivando e sarebbero stati un evento di estinzione. Ma tu sei il fondatore di un’azienda, hai già investito i soldi che hai raccolto nelle fasi iniziali per farlo, e ora ti trovi di fronte alla prospettiva che la tua tecnologia sia un po’ inutile. Cerchi forse un investimento che ti permetta di rielaborare 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 lo stack tecnologico che hanno è semplicemente nullo. Se le persone sono brave, potrebbe ancora esserci un motivo per investire in loro, ma solo a una valutazione molto più bassa perché quello che hanno è, questo asset tecnologico è completamente obsoleto. Non è più un asset, è un passivo.
Il team è funzionale, e la traiettoria in termini di sviluppo della tecnologia è folle. A volte, si tratta anche di verificare, ad esempio, che le risorse in termini di risorse di cloud computing siano sotto controllo. A volte, ci sono aziende che stanno gestendo male le loro risorse cloud. Il cloud è fantastico; pagare in base all’utilizzo significa che il cielo è il limite. Puoi creare tonnellate di macchine virtuali, tonnellate di storage, tonnellate di tutto. A volte, le aziende esagerano un po’ su questo e finiscono con una traiettoria in cui stanno spendendo troppo su risorse di cloud computing rispetto a quanto dovrebbero. Dipende da cosa stanno facendo. Quanto dovresti pagare per le risorse di cloud computing? Beh, dipende davvero da cosa stai cercando di ottenere. Non c’è una regola chiara, ma parte dell’esperienza è valutare quale sia il carico di lavoro che stai cercando di realizzare sul cloud e se ha senso che tu stia pagando così tanto. È un risultato ben fatto, il tuo software è altamente performante, o è molto cattivo e stai solo bruciando denaro? Probabilmente darti tonnellate di soldi extra da bruciare non è la mossa giusta. Probabilmente dovresti risolvere quei problemi prima di ottenere qualche milione in più. Se ti manca denaro, non puoi disciplinarti per non bruciare denaro attraverso spese non sagge in risorse computazionali. Le probabilità che diventerai saggio una volta che avrai molto più denaro sono molto basse.
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. Ma parlando di soldi, quando si parla di finanze, so che quando parliamo di supply chain, si parla dell’impatto finanziario del fondo di bilancio di qualsiasi scelta tu stia per fare. Segui lo stesso approccio quando valuti un’azienda tecnologica? Guardi quale sia l’orchestrazione più vantaggiosa dal punto di vista finanziario, o qual è semplicemente la migliore tecnologia indipendentemente 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 prospettiva è sempre completamente relativa alla maturità dell’azienda.
Conor Doherty: Sì, esattamente, secondo i loro termini.
Joannes Vermorel: Non vuoi, ad esempio, sarebbe pura follia per una piccola azienda puntare a una certificazione ISO. È uno spreco completo di risorse a meno che non si tratti di un mercato iper-regolamentato in cui non si può sopravvivere senza questa certificazione. Quello a cui guardo è quanto sei bravo a sfruttare al meglio le tue risorse limitate per ottenere il massimo ritorno sull’investimento. Parto dal presupposto che la tua direzione sia corretta, che alla fine, se avrai successo, farai soldi. Ma ancora, se prendo le tue direzioni aziendali per scontate, dico, ok, ammettiamo che se questa cosa viene fatta, allora sarai competitivo in questo mercato e ci saranno soldi da guadagnare. Prendo questo. Ora, ogni dollaro o euro speso per diventare il numero uno in questo mercato, è speso saggiamente? Assolutamente. Questo può riguardare, hai il talento giusto? A volte, si spende troppo poco. Succede che a volte l’azienda raggiunge un certo grado di successo e non licenzia le persone che erano state assunte solo perché erano molto economiche. Questo accade abbastanza frequentemente con le startup tecnologiche. Specialmente quando il fondatore non è un fondatore tecnico, ma un fondatore commerciale, e poi hai il CTO che era il primo ingegnere del software mai assunto dall’azienda. Questo accade frequentemente, e questa persona non è al livello. Di nuovo, le eccezioni variano, i risultati possono variare.
Conor Doherty: Esattamente. La mia domanda è, ci sono state situazioni in cui sei entrato per valutare un’azienda e il loro obiettivo finale era solo assurdità? Ad esempio, è il 2008 e questa azienda è determinata a riportare indietro il nastro VHS. Qualcosa completamente folle che tu ritieni sia uno spreco enorme di denaro, tempo e risorse.
Joannes Vermorel: Oh sì, succede.
Conor Doherty: Sentiti libero di condividere, ma non dare nomi.
Joannes Vermorel: Alcune tecnologie software evolvono piuttosto rapidamente. Ad esempio, negli ultimi due anni ho auditato diverse aziende che si occupano di NLP. Queste aziende sono state avviate nel 2018 o nel 2019 e sono entrate in questa ondata di intelligenza artificiale sviluppando tecnologie NLP (Elaborazione del Linguaggio Naturale), ma pre-LLM (Large Language Models). C’era una vasta letteratura di modelli NLP e di apprendimento automatico, di deep learning, ma non di LLM. Gli LLM sono stati un evento di estinzione per tutte quelle tecnologie NLP. Per quelle aziende, la mia conclusione è stata che avevano sviluppato 20 modelli NLP piuttosto sofisticati, ma erano tutti completamente obsoleti. Gli LLM stanno costantemente superando tutto ciò. Puoi semplicemente scartare l’intero stack tecnologico e ricominciare da zero con un LLM al centro. Non c’è nulla da salvare. Succede abbastanza frequentemente, forse una volta su 10 o una volta su 20, che la tecnologia sia semplicemente obsoleta per qualche motivo. A volte le persone non hanno visto esattamente quale sarà il sostituto. Quando vedo che questa cosa sta per diventare, stai risolvendo un problema che è già risolto. Di solito, non è assurdità nel senso che quelle persone sono stupide. C’è un problema da risolvere e hanno sviluppato qualcosa di bello, ma c’è qualcosa di molto meglio che è già stato trovato e possibilmente gratuito. Questa cosa non è ancora popolare, non ancora molto conosciuta. Gli LLM sono un caso estremo in cui le aziende erano un po’ disperate perché sapevano cosa stava arrivando ed era un evento di estinzione. Se sei il fondatore di un’azienda, hai già investito i soldi raccolti nelle fasi iniziali per farlo e ora ti trovi di fronte alla prospettiva che la tua tecnologia sia un po’ inutile. Cerchi forse di ottenere un investimento che ti permetta di rielaborare la tecnologia. Difficile. Il mio punto di vista non è dire agli investitori di non investire. Il mio messaggio è che lo stack tecnologico che hanno è semplicemente nullo. Se le persone sono valide, potrebbe ancora esserci un motivo per investire in loro, ma solo a una valutazione molto più bassa perché ciò che hanno non è più un asset, è un passivo.
Conor Doherty: Dall’altra parte di questo spettro, sei mai entrato in un’azienda e hai pensato, ho appena incontrato il prossimo Elon Musk? Tipo, quel ragazzo è un genio, stanno seduti su un diamante.
Joannes Vermorel: Su quella scala, no. Ma sì, a volte ho provato un po’ di invidia rispetto alla mia azienda. Soprattutto quando le persone hanno nicchie così belle. Ci sono così tante belle nicchie. I casi che mi fanno più invidia sono problemi belli che sono super di nicchia. Nessuno sa nemmeno che questo problema esiste. Risulta che ci siano decine di milioni, forse un miliardo in gioco. Questo è un mercato di nicchia e alcune persone portano una soluzione per questa nicchia ed è bellissima. È molto semplice, diretta, al punto. Invece di passare attraverso un mercato iper-competitivo, ad esempio, Lokad che fa ottimizzazione della supply chain, abbiamo oltre mille concorrenti in tutto il mondo. È un mercato molto affollato. Abbiamo alcuni concorrenti che sono aziende da miliardi. Il panorama competitivo è difficile. A volte incontro aziende che letteralmente non hanno concorrenti. Sono l’unica. I loro clienti sono felici, hanno una soluzione che è davvero adatta a un problema di nicchia di cui non avevo mai sentito parlare prima.
Conor Doherty: Esempi lì o sarebbe rivelare troppo?
Joannes Vermorel: No, purtroppo sarebbe troppo rivelatore. Cerco di, ma in definitiva, pensa a, diciamo, qualcosa di super specializzato.
Pensate alla manutenzione specializzata di una piattaforma petrolifera offshore. Ci sono tonnellate di cose da fare e alcune operazioni speciali necessitano di software come supporto. Ci sono aziende che fanno questo. Pensate a ogni singola nicchia che probabilmente ha bisogno di soluzioni molto dedicate.
Hai molte situazioni in cui puoi immaginare quanta attrezzatura tecnologica un chirurgo utilizza in sala operatoria. Tonnelate di attrezzature, anche se vuoi misurare qualcosa. Ad esempio, in questo edificio, c’era un controllo per rilevare se c’era amianto. C’era un pezzo di attrezzatura con software per rilevare l’amianto in questo edificio. C’è un’azienda da qualche parte che fa questo. Queste possono essere nicchie molto specifiche che possono sembrare piccole, ma quando guardi il mercato globale, non è così piccolo.
Queste nicchie super piccole potrebbero valere qualche centinaio di milioni di dollari in tutto il mondo, e un’azienda ha l’opportunità di conquistare il 50% del mercato perché non ci sono concorrenti. L’alternativa è che le persone utilizzino metodi tradizionali con carta e penna.
Conor Doherty: Nel corso di quei 10 anni e avendo visto una vasta gamma di esempi diversi, ci sono delle migliori pratiche generali e delle peggiori pratiche che hai notato in termini di software o startup? Cominciamo con le cose da evitare assolutamente e concludiamo su una nota positiva. Quindi, cose da evitare assolutamente?
Joannes Vermorel: Se non ti interessa la tua tecnologia, ti esploderà in faccia. La mancanza di interesse è un killer. Ogni volta che vedo aziende in cui le persone non si interessano alla tecnologia, di solito la tecnologia è una completa schifezza.
Conor Doherty: Definisci cosa intendi per “non interessarsi”. È che non sono interessati a imparare qualcosa al riguardo, o lo erano in un certo momento e ora non lo sono più, o è una mancanza di competenza? Cosa intendi con ciò?
Joannes Vermorel: Il modo migliore per descriverlo è, quando il CTO si fa la doccia, pensa alla sua tecnologia o pensa al golf? Le persone che si interessano veramente hanno una sorta di intensità. Non si ferma all’orario d’ufficio; va oltre. Sono estremamente curiosi, desiderosi e appassionati. Vogliono fare davvero la cosa giusta. C’è questo 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 è veramente bello? C’era questa aneddoto su Steve Jobs. Voleva che l’iPhone fosse bello anche all’interno. Quando lo smonti, i componenti all’interno dell’iPhone sarebbero eleganti di per sé, con la giusta scelta di colori e cose del genere. Questo grado di cura riflette che ti interessi profondamente, non solo per come appare in superficie, ma anche per le parti tecnologiche che nessun cliente vedrà mai.
Quando le persone non si interessano, è davvero brutto. Il peggio è probabilmente quando le aziende tecnologiche esternalizzano lo sviluppo delle loro tecnologie a collaboratori freelance. Non importa quanto bravi o cattivi possano essere quei freelance; il risultato netto è che la tecnologia è di solito un completo disastro.
Conor Doherty: Penso che la maggior parte delle persone concorderebbe sul fatto che la passione intrinseca e la volontà di fare bene una cosa siano una qualità fantastica. Detto ciò, se hai solo 20 minuti con il CTO, come valuti questi aspetti intangibili senza una checklist?
Joannes Vermorel: Qualcuno con intensità mi dirà, “Abbiamo scelto questa tecnologia per questo motivo.” Conoscono il perché. Non è solo, “Avevo bisogno di un’interfaccia web, quindi ho scelto questa.” Hanno opinioni sulle loro scelte tecnologiche. Le persone appassionate hanno così tante opinioni; fuoriescono da loro. Non possono fare a meno. Ogni volta che tocco una parte della tecnologia, dicono, “Lo facciamo in questo modo per questi motivi.”
Conor Doherty: È la passione che li interessa.
Joannes Vermorel: Sì, e puoi vedere l’intensità del loro pensiero. Non è solo un pezzo di tecnologia in cui l’hanno fatto perché c’erano dei requisiti. Le persone che producono codice a chilometro hanno un approccio super pedestre in cui i requisiti provengono dal team delle vendite e loro li implementano solo. Questo è un ricetta per uno stack tecnologico che è una completa schifezza.
Conor Doherty: Ad esempio, se avessi auditato Steve Jobs in passato e ti avesse detto, “Guarda l’interno di questo telefono, l’ho reso bellissimo,” il tuo memorandum direbbe che è appassionato, ma è una cosa folle su cui spendere soldi.
Joannes Vermorel: No, no. La domanda è, sembra che stiano cercando distrazioni, o fanno solo un extra di lucidatura? Queste cose potrebbero non essere molto costose. È solo l’intensità. Fai qualche percentuale in più in modo che la cosa sia davvero solida e piacevole. Questo non è pazzia. Le persone che esagerano tipicamente hanno un effetto di secondo sistema. È quando un team di ingegneri, nel loro secondo tentativo, investe troppo in cose di cui non hanno bisogno perché la prima volta è fallita a causa di una tecnologia scadente.
Il caso più frequente è quando le persone investono troppo nella scalabilità di cui non avranno bisogno a breve. Dicono, “Guarda la nostra bellissima architettura; può gestire 10 milioni di utenti.” Quanti utenti hai in questo momento? “Oh, 200.” C’è un’enorme discrepanza tra ciò che è necessario e l’eccessiva ingegnerizzazione.
Inoltre, le persone che sono pazienti per le cose sbagliate. Hai una pazienza che è per una certa eleganza e bellezza della tecnologia per sé, o stai seguendo qualche tipo di dogma? Nelle industrie del software, ci sono tutti i tipi di dogmi che fluttuano. Dobbiamo farlo come Scrum, o dobbiamo fare sviluppo guidato dal dominio, o sviluppo guidato dai test, o microservizi. Ci sono molte prese guru-esche nell’industria del software, e ci sono persone che sono zelanti per questo. Quando dico intensità, intendo persone che amano ciò che stanno creando ma che non sono zelanti riguardo a una specifica ideologia. Gli zeloti fanno cose che non corrispondono affatto ai propri requisiti pratici. Dicono, “Oh, ma dobbiamo farlo in quel modo perché è un design guidato dai test.” Il fatto che sia un design guidato dai test non è una giustificazione per farlo in quel modo. Ha davvero senso farlo in quel modo rispetto ai problemi che hai?
Conor Doherty: E per quanto riguarda le migliori pratiche, non dire semplicemente il contrario di ciò che hai appena detto. Ci sono delle cose che ti vengono in mente, quando le vedi, pensi, “Oh, questo è un buon segno”?
Joannes Vermorel: Scrittura chiara. Hai detto prima. Scrittura chiara. Ogni singolo pezzo deve essere diretto, preciso e conciso. Hai pagine di commenti nel codice che sono solo burocratiche, tipo, “Oh, dobbiamo commentare questo”? C’è un modello, e hai una pagina di commenti che nessuno leggerà? O hai commenti molto stretti che sono molto interessanti? Solo leggendo un commento, fa luce sull’intero file di codice. Quando guardo i ticket, la tua dichiarazione di problema è scritta in modo molto chiaro, o è un pasticcio incomprensibile? Quando hai una sfida tecnica, c’è una discussione molto articolata del problema e delle possibilità, o hai una slide scadente con punti elenco folli che non dicono nulla? La qualità della scrittura è uno dei segnali distintivi. Un altro è quando le persone utilizzano tecnologie insolite che si rivelano essere scelte molto valide. Se utilizzano un pezzo di tecnologia insolito, molto frequentemente è solo per ignoranza. Non sapevano che c’era una soluzione molto più diffusa che sarebbe stata molto migliore. Di solito è un aspetto negativo, ma quando si scopre che un pezzo di tecnologia relativamente raro è sorprendentemente adatto a ciò che stanno facendo, è molto buono. Significa che hanno esplorato il panorama tecnologico, specialmente il panorama tecnologico open-source, in modo molto esteso. Questo è molto bello. Oggi, nessuno si sorprenderebbe se le persone dicessero, “Oh, stiamo usando Python, PostgreSQL, Tailwind per CSS, React.” Questi sono componenti che ogni ingegnere del software competente conosce. Ma se conoscono qualcosa di super specifico che si adatta davvero al loro problema, è anche molto interessante.
Conor Doherty: Bene, siamo stati in giro per circa un’ora. Sono consapevole del tempo, quindi per concludere, ci sono pensieri finali che vorresti condividere con tutti?
Joannes Vermorel: Sì. Ciò che mi sorprende di più in questo decennio di audit è quanto frequentemente le aziende tecnologiche possano letteralmente passare anni e a volte turni successivi di investimenti senza che nessuno dia un’occhiata alla tecnologia. Si penserebbe che Theranos, questa grande frode, fosse un’eccezione. Un investimento così massiccio, e nessuno ha fatto alcun controllo sulla tecnologia. Ma la cosa divertente è che è la norma. Per me, ciò che è molto intrigante è quanto siano rari questi audit tecnologici. Quando parlo con quei fondatori di startup, di solito mi dicono, “Non avevamo idea che avresti fatto quelle domande.” Pensano che arriverò con questa lista di controllo folle e stupida. Immagina solo Theranos; le persone avrebbero facilmente ingannato la lista di controllo. C’erano molte liste di controllo in giro, tipo, “Siete conformi a questo e a quello?” Sì, sì, sì, sì. Ma la domanda fondamentale, che era, “La vostra tecnologia di analisi del sangue è reale?” Nessuno ha fatto quelle domande. Erano super basiche.
Conor Doherty: Questo torna al punto che hai fatto prima riguardo all’essere coinvolti. Se i venture capitalist stanno per investire milioni nella tua azienda, hanno un interesse in gioco.
Joannes Vermorel: La cosa che trovo molto sorprendente è che di solito, anche se arrivo al terzo round, nessuno ha dato un’occhiata seria allo stack tecnologico. È molto strano. Ci sono revisori che si limitano a spuntare delle caselle, ma secondo me, quelli non contano. Fingono solo di fare il lavoro. Non fanno nulla di sostanziale. È super facile ingannare quelle persone perché tutto quello che devi fare è mentire. Basta dire, “Fate questo?” “Sì, lo facciamo.” “Mostraci.” Mostri qualcosa che non ha senso. Il revisore non è una persona tecnica, quindi potresti mostrargli qualsiasi cosa, e lui direbbe semplicemente, “Ok, casella spuntata.” Alla fine di quegli audit, è molto intrigante. Nei classici audit, il revisore dirà, “Per favore firma questo documento che attesta che non ci hai mentito, e se hai mentito, decliniamo ogni responsabilità.” La mia opinione è che certamente non farò questo. Non assumo 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 guardiamo il codice sorgente, falsificare un codice sorgente, falsificare migliaia di commit, falsificare centinaia di ticket, falsificare tutti i documenti di supporto, è molto più difficile. Ciò che mi sorprende è che il costo è di un 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 davvero messo alla prova la tecnologia. Le persone assumono solo che sia buona, funzioni, faranno il loro piano di lavoro. Nessun controllo in alcun modo. Per me, è un po’ sconcertante.
Conor Doherty: Beh, speriamo che qualcosa di quanto discusso oggi possa fare la differenza, forse ispirare anche alcune persone a contattarti. Sei disponibile anche per bat mitzvah e compleanni, credo.
Joannes Vermorel: Sì.
Conor Doherty: Beh, Joannes, ti ringrazio molto per il tuo tempo e per aver risposto a tutte le mie domande. Grazie mille, e grazie per aver guardato. Ci vediamo la prossima volta.
