L'IT manager non dovrebbe viaggiare da solo
sul valore di avere un consulente architetturale che ti accompagna davvero - non uno che ti vende qualcosa
Ci sono due tipi di consulenti nel mondo IT.
Il primo ti porta una proposta, ti spiega perché la sua soluzione è quella giusta, chiude il contratto e poi ti manda un tecnico junior a fare l’implementazione. Il secondo entra nel tuo progetto, capisce il tuo contesto, ti fa domande scomode e - soprattutto - non sparisce quando le cose si complicano.
Questo articolo parla del secondo tipo. E di perché ogni IT manager, a un certo punto della propria journey digitale, ha bisogno di qualcuno così.
Il problema che nessuno nomina
Essere IT manager oggi significa prendere decisioni continue su tecnologie che evolvono più velocemente di qualunque percorso formativo. Significa scegliere architetture che dureranno anni, in un contesto in cui l’AI, la compliance europea, la sicurezza e i carichi di lavoro ibridi ridisegnano le regole quasi ogni trimestre.
Il problema non è la competenza tecnica: gli IT manager che conosco sono spesso molto preparati. Il problema è la profondità del ragionamento richiesta da certe decisioni.
Prendiamo un esempio banale: valutare se portare un workload critico su cloud pubblico o mantenerlo on-premise. Sembra una scelta tecnica. In realtà è una decisione che tocca simultaneamente:
la latenza e le dipendenze applicative (livello tecnico),
i costi reali nel tempo, inclusi egress e licenze (livello economico),
la postura di sicurezza e i requisiti normativi (livello di compliance),
il rapporto con i fornitori e i loro incentivi commerciali (livello strategico),
la fiducia del cliente finale su dove vivono i suoi dati (livello reputazionale).
Cinque livelli. Spesso affrontati come se fossero uno.
K-level reasoning: perché le decisioni difficili richiedono più strati
C’è un concetto che viene dalla teoria delle decisioni strategiche - il k-level reasoning - che descrive qualcosa di molto concreto: la capacità di ragionare non solo su “cosa faccio io” ma su “cosa farà l’altro in risposta a quello che faccio io, e cosa farò io in risposta a quello, e così via”.
Nella sua versione originale (teoria dei giochi, economia comportamentale) studia come le persone anticipano le mosse degli altri con profondità variabile. La maggior parte delle persone si ferma a uno o due livelli. Chi ragiona a tre o quattro livelli prende decisioni strutturalmente migliori in scenari complessi e dinamici.
Applicato al lavoro dell’IT manager, questo significa non fermarsi alla domanda “quale tecnologia uso?” ma spingersi a chiedersi: cosa succede se tra due anni il vendor cambia le condizioni? Cosa succede se il mio cliente cresce e cambia i requisiti? Cosa succede se il regolatore europeo introduce un nuovo obbligo? Come rispondo a uno scenario di breach su questa architettura che sto scegliendo oggi?
Non è pessimismo. È progettazione a più livelli.
Il punto critico è che questo tipo di ragionamento è molto difficile da fare da soli, soprattutto sotto pressione operativa. Un IT manager ha sempre mille urgenze: un ticket critico, un contratto in scadenza, un board che vuole la presentazione per dopodomani. Il pensiero strategico profondo richiede spazio, distanza e - spesso - un interlocutore con cui ragionare ad alta voce.
Training vs learning on the Job: una distinzione che cambia tutto
Quando un IT manager si aggiorna, di solito lo fa attraverso training: corsi, certificazioni, webinar, documentazione tecnica. Tutto utile. Ma il training ha un limite strutturale: trasferisce nozioni standardizzate, in un contesto artificiale, separato dal problema reale che stai cercando di risolvere.
Il learning on the job è un’altra cosa. È l’acquisizione di competenza contestuale, dentro il progetto vero, con il vincolo reale, nella conversazione con il cliente reale. È quella cosa che succede quando - mentre stai ridisegnando la segmentazione di rete per un cliente - capisci perché certe scelte architetturali che sembravano sensate su carta non funzionano in produzione.
La ricerca sul tema è consistente: la maggior parte della competenza professionale reale si sviluppa attraverso esperienze sul campo e apprendimento sociale, non attraverso formazione formale da sola.
Il ruolo di un buon consulente architetturale non è fare training all’IT manager. Non è spiegargli le best practice in aula. È stare accanto a lui nel momento in cui le decisioni vengono prese, portare la propria esperienza su casi diversi, fare le domande che non ci si è ancora posti, e lasciare che la competenza si costruisca nell’azione, non prima di essa.
È una differenza sottile, ma nel tempo fa tutta la differenza.
Cosa porta davvero un consulente architetturale (che non stia solo vendendo)
Ci tengo a fare una distinzione netta: non sto parlando del consulente che viene con un vendor in background, con quote commerciali da chiudere e un catalogo di soluzioni preconfezionate. Quel modello esiste, ha la sua utilità, ma non è questo.
Sto parlando di qualcuno che porta:
Visione architetturale trasversale: ha visto molti contesti, molte migrazioni, molti fallimenti. Non per fare il saggio, ma per aiutarti a riconoscere pattern che dall’interno del tuo contesto sono difficili da vedere.
Ragionamento a più livelli nel momento in cui serve: non una consulenza una tantum, ma la presenza quando stai valutando una scelta importante, per aiutarti ad allargare il frame prima di decidere.
Autonomia crescente come obiettivo: un consulente che vale non vuole renderti dipendente. Vuole che, dopo sei o dodici mesi, tu sia in grado di fare da solo certe conversazioni che prima non riuscivi a fare. Il suo successo si misura nella tua crescita, non nella lunghezza del contratto.
Un linguaggio diverso verso il business: spesso l’IT manager è tecnicamente solido ma fa fatica a tradurre le sue scelte in un linguaggio comprensibile al CFO, al board, ai responsabili di business. Un buon consulente architetturale ti aiuta a costruire questo ponti, non li costruisce al posto tuo.
Assenza di urgenza commerciale: la differenza tra chi ti accompagna e chi ti vende sta spesso nel tipo di domande che fa. Chi ha qualcosa da piazzare tende a convergere in fretta verso la soluzione. Chi ti accompagna rallenta, fa emergere la complessità, e si sente a proprio agio nell’incertezza.
Il paradosso dell’IT manager “bravo”
C’è un paradosso interessante: spesso sono gli IT manager più capaci a resistere di più all’idea di avere un consulente accanto. Perché sono abituati a risolvere i problemi, a non dipendere dagli altri, a sapere le risposte.
Ma la journey digitale che stiamo vivendo non premia chi sa le risposte: premia chi sa fare le domande giuste, in anticipo, e costruire sistemi che resistano a scenari che oggi non riusciamo ancora a immaginare.
Avere un interlocutore di fiducia - che non ti giudica, che non ha un interesse commerciale nella tua risposta, che conosce abbastanza del tuo contesto da essere utile senza essere invadente - non è una debolezza. È una scelta strategica.
Una domanda per chi legge
Se sei un IT manager o un CIO, ti chiedo una cosa sola: nell’ultima decisione architetturale importante che hai preso, con quante persone hai ragionato prima di decidere - non per farla approvare, ma per metterla in discussione?
E quelle persone avevano incentivi commerciali nel tuo sì, oppure no?
La risposta a quella domanda dice molto su quanto stai davvero ragionando a più livelli - e quanto invece stai decidendo da solo, in fretta, sotto pressione operativa, senza rete.