Il Test delle Due Settimane

Fai un esperimento mentale: il tuo CTO parte domani mattina per due settimane. Niente emergenze, niente dimissioni — solo ferie, nessuna reperibilità.

Cosa si blocca?

Non la strategia, quella può aspettare o le decisioni architetturali, che ci sono sempre state e ci saranno ancora.

Quello che conta è l'operatività quotidiana: chi fa il deploy se serve, chi ha accesso alle dashboard critiche, chi risponde a un cliente enterprise se c'è un problema tecnico, chi può sbloccare una decisione di routine senza aspettare che torni.

Se le risposte sono vaghe — o se la risposta a tutte le domande è "nessuno" — stai guardando il vero rischio, che il tuo CTO se ne vada ma che la tua azienda abbia un Single Point of Failure poco evidente.

C'è una distinzione importante poco nota ma che cambia tutto.

La dipendenza strategica dal CTO è normale, sana, è esattamente quello per cui lo hai assunto: la visione tecnologica, le decisioni architetturali, il dialogo tra tech e business devono passare per lui, e non puoi né devi eliminare questa dipendenza.

La dipendenza operativa è un'altra cosa. È quando il team non riesce a fare un deploy perché solo il CTO conosce la procedura, quando le credenziali di un sistema critico esistono solo nella sua testa, quando una decisione di routine — che potrebbe prendere chiunque con le informazioni giuste — si accumula in attesa che lui abbia un momento libero.

Il CEO che non distingue le due pensa di avere un CTO indispensabile mentre in realtà ha un collo di bottiglia.

La dipendenza operativa raramente nasce dalla mala fede, ma da come si lavora nel tempo.

Un CTO in modalità command & control — spesso inconsapevolmente, spesso per un passato da developer in cui fare da soli era più veloce — accentra le decisioni, gestisce gli accessi in prima persona, diventa il nodo attraverso cui passa tutto, non perché voglia creare un problema, ma perché nell'immediato funziona.

Il risultato è sempre lo stesso: zero documentazione operativa, accessi centralizzati, team abituato ad aspettare, non perché sia incompetente, ma perché non ha mai avuto il permesso reale di agire in autonomia.

Il segnale che il CEO fatica a vedere non è il CTO sovraccarico quanto il team che aspetta invece di decidere.

C'è però una responsabilità che appartiene al CTO: rendere visibile questo rischio, non solo gestirlo in silenzio.

Nominare il problema, mettere nero su bianco cosa succede se certe condizioni non ci sono, è parte del lavoro.

C'è un modo per trasformare l'esperimento mentale dell'apertura in una diagnosi concreta: chiedi al tuo CTO di prendersi una settimana di ferie senza reperibilità.

Quello che si rompe in quella settimana è la tua mappa del rischio.
Quasi nessun CEO lo fa davvero, ma il solo pensiero di farlo è già la diagnosi ed è anche interessante scoprire cosa ne penserebbe il tuo CTO, se può permettersi di farlo.

L'obiettivo non è rendere il CTO sostituibile, ma costruire un'organizzazione che non si paralizzi quando manca

C'è un paradosso che vale la pena nominare: il miglior CTO si misura non da cosa succede quando c'è, ma da cosa succede quando non c'è.

Un team che funziona in autonomia, una documentazione che regge, processi che girano senza che nessuno debba aspettare — tutto questo non è l'assenza del CTO, è la prova che ha fatto bene il suo lavoro.