Da developer a partner: una carriera nei servizi IT

Mi capita spesso di sentire persone parlare di carriera come se fosse una scala. Un gradino dopo l’altro, un titolo dopo l’altro, e alla fine una specie di senso compiuto. Poi guardo la mia e mi viene da sorridere, perché non ci vedo una scala. Ci vedo più una serie di stanze diverse, ognuna con una finestra su un pezzo del mercato dei servizi IT.

Non è un racconto “motivazionale”. È più una cosa da taccuino, quasi un’anatomia. Perché a posteriori mi accorgo che ogni fase mi ha lasciato una lente diversa. E oggi, che lavoro come Head of Tech e partner in una piccola realtà ICT, quelle lenti iniziano davvero a sovrapporsi.

## La cosa strana delle carriere non lineari

Le carriere lineari forse non sono mai esistite davvero, ma per un po’ ci abbiamo creduto. Io sicuramente sì. Poi mi sono ritrovato a passare da Interface Developer in uno dei più grandi gruppi e-commerce di lusso europei (prima che entrasse nell’orbita Richemont), a CTO in una startup deep-tech sull’oil & gas, fino a gestire un portfolio di progetti molto diversi tra loro in una società di circa dieci persone.

Se devo dire cosa accomuna queste tappe, non è la tecnologia. Quella cambia, e cambia più in fretta di quanto ci piaccia ammettere. Il filo conduttore è un altro: ogni ruolo mi ha fatto vedere *come si comprano e si vendono* servizi IT. E soprattutto perché spesso le decisioni che sembrano tecniche, tecniche non sono.

## Fase 1: dentro un grande player, dal lato del codice

Quando sei in una grande organizzazione e non sei nel management, rischi di pensare che certe dinamiche non ti riguardino. In realtà ti attraversano lo stesso, solo che le vivi “di riflesso”. Io ero nel codice, ma lavorare in un gruppo di quella scala ti fa vedere cose che da fuori restano invisibili.

Per esempio, come si gestisce davvero la relazione con i fornitori tecnologici. Non in teoria, non nel deck, ma nel quotidiano. Ho visto che dietro una scelta architetturale spesso c’è una scelta organizzativa, di budget, a volte persino di potere. E ho visto anche una differenza che all’inizio mi dava fastidio, poi ho capito che era semplicemente reale: vendor scelti per competenza e vendor scelti per inerzia contrattuale non sono la stessa cosa, ma nei documenti sembrano identici.

La prima regola che mi porto dietro da quella fase è questa, e forse è un po’ cinica, ma mi sembra vera.

**Il fornitore migliore non è quello con la proposta migliore, è quello che capisce come funziona l’organizzazione del cliente.**

È una regola difficile da mettere in un framework. È qualitativa, contestuale. E richiede una comprensione delle dinamiche interne che spesso si acquisisce solo stando lì, per osmosi. Mi chiedo ancora oggi quante gare e quante selezioni falliscano non perché il provider non sia capace, ma perché non ha letto il “sistema nervoso” del cliente.

## Fase 2: la startup, cioè il costo reale delle scelte

Il salto verso la startup è stato, senza esagerare, quello che mi ha cambiato di più. Come CTO di una startup deep-tech verticale sull’oil & gas mi sono ritrovato a fare tutto. Stack tecnologico, assunzioni, processi, budget, clienti, delivery. Tutto insieme, spesso nello stesso giorno.

E lì impari una cosa che nelle grandi aziende resta più sfumata: il costo delle decisioni non è un concetto astratto. È immediato. Ogni scelta ha un impatto diretto sul conto economico, sul time-to-market, sulla sostenibilità del team.

In quella fase ho imparato a prezzare i servizi IT non “in base al mercato”, ma in base alla struttura dei costi reali. Che sembra banale finché non ti ci schianti contro. Ho imparato anche che un servizio prezzato troppo basso è più pericoloso di uno prezzato troppo alto, perché prima o poi qualcuno pagherà la differenza. E spesso a pagare è il cliente, sotto forma di debito tecnico, ritardi, turnover, patch messe di corsa.

Un altro pezzo importante sono stati i contratti. Non quelli scritti per vincere una trattativa, ma quelli che ti permettono di lavorare. Ho capito che esistono contratti che “proteggono” e contratti che “funzionano”. I primi sono pieni di penali che nessuno vuole applicare. I secondi definiscono incentivi allineati, una zona di collaborazione dove entrambe le parti hanno convenienza a fare la cosa giusta.

La seconda regola, qui, è diventata quasi una convinzione.

**La qualità di un servizio IT si decide prima che il progetto inizi, nelle scelte architetturali e nei processi che il provider mette in piedi.**

Quando il codice comincia a scorrere, molte partite sono già state giocate. Non tutte, certo. Ma tante sì.

## Fase 3: il portfolio multi-cliente, dove i confini sfumano

Oggi lavoro in una realtà ICT piccola, circa dieci persone, che opera come partner tecnologico B2B. I clienti vanno da grandi corporate a Pubbliche Amministrazioni. Il mio ruolo è un incrocio continuo tra leadership tecnica, sprint planning, DevOps, compliance e architettura. E soprattutto è un lavoro “a portfolio”, quindi con contesti molto diversi che convivono.

Nello stesso periodo possiamo essere coinvolti su un sistema informativo sanitario regionale, su una piattaforma SaaS di people analytics, su un’infrastruttura IoT industriale, su servizi di cybersecurity come partner certificato di un vendor leader, su progetti di compliance normativa e su sviluppo custom per la PA.

Questa fase è quella in cui le due esperienze precedenti si incastrano. Da un lato ho la memoria del grande player, quindi capisco come ragionano i clienti enterprise, cosa li preoccupa davvero, quali sono i vincoli impliciti. Dall’altro ho la sensibilità della startup, quindi so cosa vuol dire fare efficienza con risorse limitate, e quanto contino automazione e disciplina operativa.

Ma la lezione nuova, quella che non mi aspettavo, è un’altra.

**Il mercato dei servizi IT è frammentato in modi che molti framework di advisory non catturano.**

Non siamo un system integrator generalista, ma non siamo nemmeno una boutique ultra-specialistica. Siamo quella cosa un po’ scomoda da etichettare: un partner tecnologico agile con competenze trasversali. E in certi contesti competiamo con player dieci volte più grandi, non perché siamo “migliori” in assoluto, ma perché i processi sono più snelli e, sempre di più, perché l’AI-assisted development sta cambiando i rapporti tra capacità produttiva e dimensione del team.

Forse è qui che mi sono reso conto di quanto la mappa non coincida con il territorio. Nei quadranti e nei report alcune categorie sono nitide. Nella vita reale, molto meno.

## Cosa mi hanno insegnato queste fasi sul sourcing IT

Se provo a tradurre tutto questo in implicazioni pratiche per il sourcing, mi vengono in mente tre idee, che poi sono tre “difetti” ricorrenti nel modo in cui si valutano i provider.

La prima viene dalla grande azienda: le decisioni di sourcing sono spesso decisioni organizzative mascherate da decisioni tecniche. Quindi chi fa advisory dovrebbe capire le dinamiche interne del cliente tanto quanto capisce le capability del provider. Altrimenti rischia di consigliare il “migliore sulla carta” e ottenere il peggiore in pratica.

La seconda viene dalla startup: l’economia dei servizi IT è molto più granulare di quanto appaia nei report di mercato. Il margine di un provider su un singolo progetto può oscillare in modo enorme in base alle scelte architetturali, al livello di automazione, alla maturità dei processi. E se non leggi queste dinamiche, non proteggi davvero il cliente. Lo proteggi solo formalmente.

La terza viene dal lavoro a portfolio: il mercato reale è più diversificato di quanto i framework suggeriscano. Le PMI tecnologiche che servono il tessuto economico europeo spesso non appaiono nei quadranti, ma erogano una quota significativa dei servizi IT. Se non conosci quel segmento, stai offrendo ai clienti un set di opzioni incompleto. E magari nemmeno te ne accorgi.

## Il valore cumulativo, e perché conta adesso

C’è un pattern che noto nelle carriere che producono valore “non convenzionale”. Non è la singola esperienza a fare la differenza, ma l’intersezione.

Un analista che ha lavorato solo in consulting conosce i framework, ma magari non ha mai vissuto il delivery quando le cose vanno storte. Un tecnico che ha lavorato solo in development conosce il codice, ma non sempre vede il business. Un manager che ha lavorato solo in corporate conosce le dinamiche politiche, ma rischia di perdere il contatto con i costi reali e con la fatica operativa.

Il senso della mia traiettoria, se ne ha uno, è attraversare questi mondi. E mi sembra che oggi questa capacità di connessione non sia più un “plus”. Con ai che entra nei processi, compliance europea che diventa sempre più stringente, modelli di pricing che cambiano, reshoring e nuove aspettative su sicurezza e sovranità del dato, la complessità non diminuisce. Aumenta.

E quando la complessità aumenta, le risposte semplici iniziano a suonare sospette.

## Il passo successivo, con un po’ di onestà

Negli ultimi tempi sento che la naturale evoluzione di questo percorso sia portare questa prospettiva integrata a chi deve prendere decisioni di sourcing ad alto impatto.

Non come consulente operativo, quello lo faccio già. Piuttosto come analista di mercato, ricercatore, advisor strategico. In un contesto in cui la profondità di esperienza operativa e la capacità di produrre insight azionabili siano il cuore della proposta di valore.

È il tipo di ruolo che alcune aziende, con molta fatica e molti investimenti, provano ad incarnare bene.

Non perché io abbia le risposte giuste. Su molte cose, sinceramente, non sono nemmeno sicuro di avere una risposta unica. Ma perché credo di avere le domande giuste, quelle che vengono dall’aver visto il mercato dei servizi IT da angolazioni diverse. E forse è proprio questo, oggi, che serve di più.

*Prossimo nella serie: come la tempesta regolatoria europea sta ridefinendo i criteri di valutazione dei provider IT, e perché il mercato dell’advisory non è ancora pronto.*