Confessioni di un CTO

Aggiornato a agosto/2020

Chi è il CTO?

CTO è un acronimo che sta per Chief Technology/Technical Officer, quando avviai la mia azienda era una figura pensata e concepita come responsabile dell’area Tecnica e sembrava fosse nata per piazzarla all’interno di un organigramma aziendale, non vi sto nemmeno a dire che appariva quasi esclusivamente in aziende di medie e grandi dimensioni, dove ci si diverte a coniare ruoli altrettanto simili e con responsabilità diverse (CXO).

Nel creare la mia azienda, nello spirito allora in voga di CTO as a Service, pensavo di calare questo ruolo nella direzione di realtà più dinamiche e in situazioni più sfidanti, là dove avvertivo sarebbe stato un ruolo più utile di quanto sembrasse esserlo in realtà consolidate. Questa figura in ambito Startup, addirittura, viene ancora apostrofata come Unicorno, tanto risulta importante e altrettanto difficile da trovare quanto da ingaggiare.

Di cosa si dovrebbe occupare un CTO?

Qui cala il mistero! Si scherza naturalmente, o forse no? Se le persone continuano a cercare prevalentemente Sviluppatori Software e non CTO avrà un fondo di verità il mistero.
Un CTO che si sporca le mani a scrivere codice è uno spreco? Io non sono di quelli che pensa che scrivere codice sia un male necessario o un’attività come tante altre. Scrivere codice secondo principi SOLID e fare codice di qualità è un’arte che si sviluppa negli anni ed è anche un’arte che va continuamente allenata quanto aggiornata, altrimenti regredisce.

Se un CTO ha al suo fianco ottimi Sviluppatori, può armeggiare su altri aspetti e facilitare il lavoro del Team cercando di concentrarsi su tutti gli altri aspetti che correlano Tecnologia e Business, spesso si parla di attività più di alto livello, ma non dovete erroneamente pensare che il termine alto significhi più nobile dell’arte di scrivere codice. Significa banalmente più vicine al Business e meno al dettaglio tecnologico, prospettiva a volo d’uccello. In realtà più piccole o quando il gioco si fa duro il CTO per primo potrebbe dare l’esempio e scrivere codice all’occorrenza.

Quando un CTO è da anni lontano dalla tastiera la T di CTO è sempre più forzata. Molti dicono che chi sta al “comando” può essere anche a digiuno di Tecnologia. Non sono naturalmente d’accordo, è come pensare che un direttore di orchestra non conosca la Musica! Il direttore può anche non essere un egregio violinista, ma se vuole condurre le danze deve conoscere la Musica e conoscere cosa deve e può fare il primo violino.

Scrivere codice non basta per mettere in piedi un sistema online e rendere un Business sostenibile. Non tutti hanno bisogno di un CTO, e con questo intendo chi non ha un business incentrato su asset tecnologici. Se avete però da affrontare periodicamente sfide tecnologiche e avete un sistema con più touchpoint da monitorare, far evolvere e processi che si basano su asset tecnologici, porre fiducia per la gestione, il mantenimento e l’evoluzione del vostro sistema ad una persona che attraverso la sua esperienza e competenza guidi l’area tecnica è fondamentale per la salute del vostro Business Online.

Il CTO in generale è responsabile che i vostri processi sotto al cofano della vostra realtà siano e rimangano produttivi e a sostegno del Business per garantirne l’operatività. Metta mano al codice o meno dipende dalla dimensione della vostra attività, dalla dimensione del Team e dal ruolo più o meno operativo che si viene a ricoprire e sulla base delle situazioni in cui venite a trovarvi. Quello di cui sono certo è, che deve essere concentrato sulla tecnologia in ottica strategica, senza dubbio questa mia riflessione ha dato vita al podcast Strategia IT.

CTO tecnico o no?

Chi ha competenze tecnologiche ti dirà che il CTO (T sta per Technical /Technology) deve avere almeno un background tecnologico, operativo o meno che sia. Chi non ha competenze tecnologiche ma vuole ricoprire questo ruolo ti dirà che non sono necessariamente importanti competenze tecniche, dato che quest’ultimo dovrà solo coordinare ed essere di raccordo tra Business e Team tecnico.

Non entriamo in polemica su quello che va fatto. Sta a te decidere se mettere una persona senza competenze tecniche nel ruolo di responsabile dell’area tecnica :).

Diventa più un PMO che un CTO.
Se dovessi aver preso o stai per decidere di prendere un CTO non tecnico sappi solo che quest’ultimo dovrà comunque affidarsi a personale fortemente tecnico per prendere decisioni tecnologicamente complesse; quindi sarà essenzialmente una persona tra il Business e chi si occuperà nelle retrovie di realizzare e manutenere il tutto.
Chi non vi consiglia un CTO tecnico non necessariamente è in malafede, dovete solo capire che chi lo fa probabilmente non è forte sul lato tecnico.

Il CTO non è un tuttologo, avrà limitate conoscenze e su specifiche tecnologie, quindi una volta individuati i problemi e le possibili soluzioni che dovrete implementare, prendete le distanze dal CTO che non rientra come skills nell’area dove andate ad operare e il CTO di turno a sua volta se non rientra nella specifica area di competenza dovrà delegare o fare un passo indietro senza prendersi l’onere del progetto.

Team

Un’idea di Business è solo qualcosa che ci ronza nella nostra testa, una soluzione ad un problema o ad un bisogno che abbiamo individuato.
Ovviamente se la nostra soluzione rasenta la banalità o è davvero semplice da creare, sarà altrettanto semplice per i vostri competitor metterla in piedi e la concorrenza crescerà fino a limitare i vostri margini e andrà a bloccare prima la crescita fino a ridurre le possibilità di distinguerci e sopravvivere sul mercato.
Quindi non basta avere un’idea, ma la soluzione “deve” essere complessa, sfidante. Se c’è complessità, ci servono almeno 2 cose:

1. Passione
2. Team

Dove ho scritto passione avevo scritto da subito la parola competenza. Non voglio fare il romantico e quindi vi dico da subito che serve competenza e preparazione e non guasta(è un must have) essere esperti di Dominio nel settore dove vi state muovendo. Ma dalla passione può nascere la competenza nel tempo. Le competenze richieste non sono mai abbastanza e sono spesso trasversali indipendentemente da cosa volete realizzare. Qui entra in gioco il ruolo del Team. Un bel gruppo di persone motivate eterogeneo e con una visione strategica a cui tutti sono allineati.

Ma il team deve essere “interno” o esterno? Con questa domanda spesso si intende: posso assoldare CTO o senior developer o un grafico o un DevOps, insomma dei liberi professionisti per un periodo o una tantum o devo costruire da subito un team forte e coeso? Ora non mi resta che rivolgermi al Totem della Complessità (DIPENDE). Non è la sola domanda che viene posta quando si tratta della gestione e creazione di un team di lavoro.
Ma limitiamoci a questa per ora. La domanda giusta da porsi è, sarebbe bello avere un team pronto all’azione, ma lo abbiamo? E costruirlo quanto tempo richiederà? Costruirlo secondo standard qualitativi e quantitativi intendo.

La mia risposta è: create un team con le persone giuste e lasciate che questo processo sia lento ed accurato. Nel frattempo dato che è tanto raro quanto poco fattibile vedere un team formato da sole persone interne, soprattutto da subito, iniettare nel team persone con lunga esperienza e competenze dovrebbe dare un boost al vostro progetto. Al giorno d’oggi creare uno zoccolo duro interno ed essere pronti ad essere contaminati da nuovi approcci e nuove competenze è l’ideale, questo è possibile se potete introdurre nel vostro workflow di lavoro qualcuna/o, sempre se questa/o qualcuna/o possa portare valore e sia allineato alla vostra roadmap.

Cosa più importante: trattate la persona che entrerà nel progetto, anche se temporaneamente, come fosse della famiglia.
Chi entra nel team darà un contributo, intendo dire che sarebbe bello pensare, prendo un esperto e mi farà l’80% del lavoro. Una persona per quanto brava darà un contributo che sarà ben più piccolo di quello che ognuno di noi ha in mente quando vede il suo CV.

Il team nella sua interezza farà la differenza non un Uomo/Donna solo/a al comando.
Non importa quanto il team è distribuito ma quanto è allineato e quanto ricorre ad una mutua assistenza.

Come coinvolgo i primi dipendenti o collaboratori?

Coinvolgere persone non richiede solo “potere” economico, ma principalmente chiarezza di intenti; avere chiaro cosa davvero vuoi portare nel Settore a cui ti stai dedicando e cosa chiedi portino le persone che coinvolgerai nel tuo percorso. Capire se quello che fai è la cosa giusta e se le persone che coinvolgi sono davvero le persone che aumenteranno l’entusiasmo e la fiducia nel progetto.

Nessuna promessa di diventare i numeri 1 del mercato, di seguire a 360 gradi ogni cosa, ma solo cose che puoi mantenere nell’immediato. Non devi nascondere le tue ambizioni e altrettanto il ruolo che vorresti giocasse chiunque sia coinvolto. Comunicare in modo trasparente e ascoltare veramente crea fiducia; va preteso anche dai propri collaboratori.

Esperto di Dominio

In un team non deve mancare l’esperto di dominio. Significa una o più persone che siano ferrate del settore e di quello che andate a costruire. Non necessariamente persone con background tecnico, ma capaci di mettersi in relazione con i “tecnici” per mettere a terra il vostro progetto, spostarlo dalla vostra testa fino a portarlo in produzione.

Avviare un progetto è rischioso per definizione, farlo senza conoscere bene il contesto in cui vi state muovendo è davvero un campo minato.
Significa che se non siete esperti di un settore o di una specifica tecnologia ad esempio, dovete abbandonare l’idea di mettere in pratica le vostre suggestioni?
Certo che no, quello che sto dicendo è che dovete imparare nel minor tempo possibile a capire come funziona l’ecosistema dove nutrite ambizioni di tracciare un vostro percorso personale e per farlo avete 2 strade non necessariamente esclusive: dovete avvicinare gli esperti di dominio e/o diventarlo voi stessi.

Competenze

Le competenze è un tema vasto, se ci limitiamo a parlare di CTO già qui ci sono visioni diverse, quelli come il Sottoscritto che vede il ruolo occupato da un esperto di Tecnologia, con un background molto tecnico e chi si orienta più verso un ruolo dove la T sta per lo più per T-shaped, dove a fronte di una specializzazione solitamente tecnica e verticale, la persona unisce soft skills generaliste allargandosi su più aspetti non meno necessari.

La cosa importante qui, è capire il percorso e le sfide che il Team deve compiere e gradualmente introdurre le competenze necessarie. In una prima fase imprenditoriale, potreste decidere di prendere risorse esterne e nel frattempo coltivare talenti al vostro interno. L’importante è tenere sempre d’occhio quale cultura e quale missione si pone il team nella sua interezza e partire dalle persone prima ancora delle competenze. Iniziate da subito a progettare il vostro team quanto a modellare la vostra Idea.

Cosa realizzare

Web API

Il mio posizionamento è sulle Web API.
Appena lo dico le persone non tecniche mi guardano annuendo, ma la loro comunicazione non verbale non sempre mente brillantemente.
Per capire perché sono importanti le Web API vi scrivo 2 righe o quanto basta.

L’analogia che spesso gira è quella del Menu al ristorante; Il menu è l’interfaccia dove sono esposte le dichiarazioni delle API, quello che posso ordinare con tutti i dettagli, prezzo ingredienti foto etc.
L’offerta del ristorante è tutta esposta nel menu, noi se vogliamo il cibo non dobbiamo fare altro che fare un ordine, dire al cameriere quali voci di menu desideriamo e in tutta risposta ci arriverà il cibo.

Ecco fatta l’analogia,  se pensate che al posto del menu ci siano le API, al posto del cliente troviamo un’applicazione ed infine al posto del ristorante c’è il backend di un’altra applicazione gestita dal ristorante responsabile di fornire il cibo(dati) come risultato, dovreste aver capito che i software si scambiano ordini e dati attraverso le API.

E il cameriere? Forse è lui l’assassino? Facciamo i seri almeno questa volta! Il cameriere potrebbe essere l’implementazione delle API.
Perché il menu espone cosa viene offerto, ma poi ci deve essere qualcosa o qualcuno che renda possibile lo scambio di dati e ordini tra voi e il ristorante.

Tutto il Web funziona con le Web API, quando navigate su un sito state caricando delle risorse invocando un’API, quando riempite un modulo online e cliccate su Invia pure; quando installate un’integrazione tra il vostro sito e un sistema di pagamento anche.


Volete fare un’app? Dovete “consumare” delle API.

Insomma se conoscete la celebre frase Il software si sta mangiando il Mondo, capirete subito che questo magna magna avviene grazie alle API.
E non è un caso che sia stato coniato il termine API Economy.

Ma sulla generazione di nomi e acronimi non ci soffermeremo. In futuro verrà chiamata in modo sicuramente diverso, dato che il termine API è sempre risultato, per ovvie ragioni, sin troppo tecnico date le sue origini.

Sappiamo che le questioni tecniche per quanto fondamentali, sono destinate a rimanere nell’ombra, per ora nella penombra.

Ogni azienda per così dire Tech si apre alle API, perché?

Perché le vedono come un asset! Parlo sempre di asset e non vado a specializzarmi su ciò che abilita a creare asset e di fatto risulta esso stesso un asset?

Le API di fatto permettono alla tua Azienda o Startup di diventare più appetibile sul mercato, gli altri saranno stimolati, invece di occuparsi di ogni aspetto della loro applicazione, di costruire parte  della loro soluzione integrandosi con la tue API.
Ogni piccola o grande azienda che sia, dove naturalmente si sia compreso questo potere, sarà in grado di adottarle, produrrà e consumerà API.

Mentre consumare Web API è ormai in ogni cosa che facciamo, costruire API proprie sarà indice di lungimiranza e comprensione di come funziona la Rete.

Alle volte le API sembrano grezze, ma proprio questo aspetto stimola l’ecosistema e l’indotto.
Altre volte sono sofisticate ed eleganti perché non espongono solo l’accesso ai dati ma assorbono anche la business logic, dove risiede proprio il valore della vostra soluzione.

Tutto questa esposizione per dirvi che, vi piaccia o no, consapevoli o meno, state consumando API, e se intendete costruite asset, sarete costretti a produrre Web API. Sorry! Qualcuno ve lo doveva dire 😉

Chiedetevi quando iniziate il vostro percorso, se siete API-first o seguite un approccio Design by Contract.

MVP

Va citato almeno una volta il cosiddetto MVP, fa parte di diritto della bibliografia Startuppara.
MVP è un acronimo e questo potevate scoprirlo da soli atterrando su Wikipedia, e di certo avrete trovato in rete pure la classica immagine che vi dovrebbe indicare meglio cosa si intende per MVP. (Like this…)

Ho fatto un episodio sul podcast per indicarvi quanto sia molto di più di una versione minimale e non fake da rilasciare in produzione per ricevere feedback.

Quello che vi dovrebbe animare è il tentativo di uscire(pubblicare online) prima possibile, offrire qualcosa da far provare al vostro primo sostenitore o early adopter in gergo, per poter ricevere quanto prima feedback volti a far evolvere la vostra prima versione del prodotto.

Il prodotto per quanto semplice deve comunque essere più che utile per risolvere un problema fortemente sentito dalla vostra audience di riferimento, per tanto sentito, intendo, che una volta scoperta la soluzione al problema sarà facile stimolare la disponibilità a pagare da parte del vostro lead. Chi non vorrebbe alleviare il proprio dolore?