Dallo sviluppo software all’impresa

Sui fondatori con un profilo tecnico circola un racconto ben noto: bravissimi a costruire, a disagio quando si tratta di vendere, costretti a disimparare le abitudini dell’ingegneria prima di poter guidare un’azienda. C’è del vero, ma il racconto trascura qualcosa di importante. Le discipline che fanno un buon sviluppatore software (scomporre i problemi, verificare le ipotesi, dare più peso ai fatti che all’entusiasmo) non sono un ostacolo all’impresa. Se sviluppate nel modo giusto, ne sono anzi tra le basi più solide.

Il percorso di Ahmad Athamneh è un buon caso per mettere alla prova questa idea. Comincia con una laurea in informatica, prosegue con anni di sviluppo e di consulenza tecnica, comprende una formazione manageriale a Oxford e un periodo nel marketing digitale di una piattaforma globale, e arriva a un insieme di aziende che spazia dallo streaming dal vivo a un polo fieristico, dall’intelligenza artificiale agli asset digitali. Nessuna di queste tappe, da sola, è insolita. Ciò che insegna qualcosa è il modo in cui ognuna cambia il significato delle precedenti.

L’eredità dell’ingegnere

Lo sviluppo software insegna una forma particolare di onestà. Il codice funziona oppure no; un sistema regge il carico oppure cede davanti ai suoi utenti. Lo sviluppatore impara presto che la sicurezza non è una prova e che la distanza tra un progetto plausibile e un prodotto funzionante è il luogo in cui si svolge la maggior parte del lavoro vero.

Tre abitudini di questa disciplina si trasferiscono particolarmente bene nel mondo dell’impresa. La prima è la scomposizione: l’istinto di suddividere un obiettivo ampio e indefinito in problemi più piccoli, comprensibili e risolvibili. In questo senso un’impresa è un sistema (di clienti, incentivi, processi, tecnologia e capitale) e i suoi problemi cedono alla stessa analisi paziente.

La seconda è l’iterazione. Gli ingegneri raramente si aspettano di fare la cosa giusta al primo tentativo: costruiscono, provano, osservano e correggono. I fondatori che portano questa abitudine nella strategia rischiano meno di innamorarsi di un piano e si accorgono prima quando il mercato sta dicendo qualcos’altro.

La terza è il rispetto per le modalità di guasto. Un buon ingegnere non si chiede soltanto come funziona un sistema, ma anche come si rompe. Nell’impresa questo si traduce in una visione sobria del rischio (normativo, operativo, reputazionale) che spesso manca alle forme più ottimistiche di imprenditorialità.

Ciò che l’ingegneria non insegna

Se le abitudini dell’ingegnere sono un’eredità, non sono però una formazione completa. La preparazione tecnica tende a considerare i requisiti come dati. Fare impresa richiede invece di scoprirli: capire di che cosa le persone hanno davvero bisogno, per che cosa sono disposte a pagare e che cosa le farà tornare.

È qui che l’esperienza al di fuori dell’ingegneria diventa formativa. Il marketing digitale, per esempio, è soprattutto un lavoro di comprensione del pubblico: come scopre i contenuti, che cosa ne conquista l’attenzione, come la cultura e la lingua determinano ciò che colpisce nel segno. Per chi si è formato sui sistemi è una lezione sulle variabili che non compaiono in nessuna specifica.

Una formazione manageriale strutturata aggiunge un altro livello: il linguaggio del capitale, dell’organizzazione e della strategia. Un MBA non trasforma nessuno in imprenditore, ma può offrire strumenti per domande che agli ingegneri vengono poste di rado: come valutare un’opportunità, come strutturare un’organizzazione, come pensare la concorrenza su un orizzonte di anni anziché di cicli di rilascio.

L’apprendistato della consulenza

Tra l’ingegneria pura e la fondazione di un’azienda c’è una fase sottovalutata: la consulenza. I consulenti tecnici vengono chiamati nelle organizzazioni nei momenti che contano, quando un sistema deve crescere, un servizio va ammodernato o una piattaforma deve essere costruita sotto stretta osservazione. Vedono molte organizzazioni dall’interno, spesso in poco tempo, e imparano a leggere il contesto istituzionale con la stessa cura dell’architettura tecnica.

Contribuire a piattaforme di servizi digitali su larga scala, in particolare, insegna cose difficili da imparare in altro modo. L’affidabilità smette di essere una metrica e diventa un obbligo morale. Il coordinamento tra molti team diventa la sfida centrale. E il consulente impara che la soluzione tecnica migliore non è sempre quella che un’istituzione è in grado di adottare: una lezione che ogni fondatore prima o poi incontra quando tratta con partner, autorità di regolamentazione o grandi clienti.

La svolta del fondatore

A un certo punto molte persone con questo tipo di percorso si trovano davanti a una scelta: continuare a costruire e a consigliare sistemi che appartengono ad altri o avviare qualcosa di proprio. La decisione raramente dipende dalle capacità tecniche. Dipende dalla disponibilità ad assumersi un’altra forma di responsabilità: per gli stipendi, per la strategia, per le conseguenze di decisioni che non si possono più rimettere a qualcun altro.

Fondare una piattaforma di streaming dal vivo, come ha fatto Ahmad con YouLive nel 2019, mostra come si combinano le fasi precedenti. Una piattaforma dal vivo è tecnicamente impegnativa, culturalmente delicata ed economicamente fragile. Ha bisogno di un’ingegneria che funzioni in tempo reale, di una comprensione di come si comportano pubblico e creator e di un modello di business che remuneri equamente chi partecipa. Nessuna delle esperienze precedenti basterebbe da sola; insieme, costituiscono una base credibile.

Da un’azienda a un portafoglio

Le fasi successive di una carriera simile tendono ad allargarsi più che ad approfondirsi. La proprietà di un’attività fieristica, due progetti operativi nelle tecnologie per la sanità e per l’istruzione e una piattaforma di scambio in fase di sviluppo possono sembrare interessi sparsi. Viste con gli occhi dell’ingegnere, condividono una struttura: ciascuna è un sistema che mette in relazione partecipanti che hanno bisogno di trovarsi, fidarsi l’uno dell’altro e scambiare.

Questa continuità conta perché determina il modo in cui si valutano i progetti. Le domande restano le stesse. Il problema di fondo è reale? Il sistema può essere costruito al livello richiesto? Chi si assume il rischio, ed è giusto che sia così? Stiamo distinguendo con precisione ciò che esiste oggi da ciò che è ancora un progetto?

Cinque abitudini da portare con sé

Per gli ingegneri che stanno pensando a un percorso simile, queste sono le abitudini che di solito contano di più:

• Considerare le proprie abitudini tecniche una risorsa, non un limite. Scomposizione, iterazione e rispetto dei fatti sono rari in mercati che premiano la narrazione. Vanno messi a frutto.
• Esporsi deliberatamente a ciò che l’ingegneria tralascia. Ruoli nel marketing, nelle vendite, nelle operations o nella consulenza insegnano le variabili umane e istituzionali che decidono se una tecnologia conta davvero.
• Dare valore all’apprendistato della consulenza. Vedere molte organizzazioni dall’interno è una formazione accelerata su come si prendono davvero le decisioni.
• Essere precisi sullo stato dei progetti. La credibilità di un fondatore si fonda su distinzioni chiare tra ciò che è operativo, ciò che è in sviluppo e ciò che è ancora un’idea.
• Scegliere problemi in cui la propria combinazione di competenze sia rara. La posizione più solida per un fondatore tecnico si trova spesso all’incrocio di discipline che di rado si incontrano.

L’ingegneria, in senso più ampio

Il passaggio dallo sviluppo software all’impresa viene talvolta descritto come un abbandono dell’ingegneria. Sarebbe più esatto dire che l’ingegneria si allarga: dai sistemi di codice ai sistemi di persone, incentivi e istituzioni. Il fondatore che compie bene questa transizione non rinuncia alla disciplina dello sviluppatore. La applica a problemi più grandi e più ricchi di conseguenze, e la unisce a quella comprensione dei mercati e delle persone che il codice, da solo, non potrebbe mai offrire.