Guardo indietro di sei mesi e faccio già fatica a ricordare come lavoravamo un anno fa. Non per nostalgia, per pura estraneità. Come quando torni in una casa in cui hai vissuto e non riconosci più le stanze.
È iniziato come un esperimento senza nome. Oggi non ne ha ancora uno, ma ha una forma riconoscibile. In Dcycle, tutta l'azienda contribuisce al codice del prodotto. Non solo gli ingegneri. Il Customer Success distribuisce automazioni. Il Marketing costruisce i propri flussi di dati. Le Ops assemblano dashboard che prima richiedevano tre riunioni e un ticket. Nessuno deve chiederglielo esplicitamente. Gli strumenti semplicemente lo permettono e la curiosità fa il resto.
Quello che è successo, durante quell'esperimento, è che la velocità ha cambiato la cultura. Non il contrario. Non è che prima abbiamo progettato un manifesto dell'autonomia e poi le persone hanno iniziato a costruire. È che qualcuno del CS si è stancato di aspettare due cicli per risolvere un problema che conosceva bene, ha aperto Claude Code e l'ha risolto. Quando il team ha visto il risultato, nessuno ha chiesto se quello fosse "il suo ruolo". Hanno chiesto come farlo.
Avevamo già il gene dell'autonomia dentro di noi, ma gli strumenti l'hanno fatto esplodere.
Quella che è una decisione consapevole è mantenerla. Spero che ogni persona in questo team abbia il riflesso di risolvere prima del riflesso di delegare. Se vedi un problema e puoi risolverlo, risolvilo. Hai già il permesso. Se non puoi, impara abbastanza per poterlo fare la prossima volta. Cerca un modo per imparare; se non lo trovi, chiedi aiuto. Troverai sempre una mano amica nelle vicinanze.
Il tuo titolo non descrive più quello che fai
C'è qualcosa che non si dice abbastanza su quello che succede quando tutti possono costruire soluzioni: il tuo titolo smette di descrivere esclusivamente quello che fai.
Marina è ancora nel Customer Success. Ma la settimana scorsa ha distribuito un bot che incrocia i dati di utilizzo con i segnali di churn e genera alert su Slack suggerendo azioni. Juan è ancora in Finance, ma ha costruito un sistema di riconciliazione finanziaria che prima richiedeva due giorni e ora ne richiede dieci minuti. Non hanno smesso di fare il loro lavoro. È che il loro lavoro ora include progettare le macchine che fanno parte del loro lavoro.
So che questo può sembrare un imprenditore di LinkedIn. Ma viverlo ha un sapore molto diverso dal leggerlo. Viverlo assomiglia più a un disorientamento produttivo: la sensazione che quello che sapevi fare non basta più, ma che quello che puoi fare è più di sempre. Ne so qualcosa.
Manager di sé e di molti
Lo chiamiamo "manager di sé e di molti" e so che suona strano. Ma cattura qualcosa di reale.
Ogni persona in Dcycle gestisce il proprio lavoro. Questo è il "di sé". Ha l'autonomia di decidere cosa costruire, come risolvere qualsiasi cosa o quando iterare. Non aspetta approvazioni per migliorare qualcosa. La tendenza è verso l'azione.
E ogni persona orchestra anche degli agenti. Questo è il "di molti". Non in modo fantascientifico. In modo pratico: progetta prompt, definisce flussi, rompe cose e le ripara, supervisiona gli output, corregge errori. Ha un team di agenti che amplifica la sua capacità. Siamo passati dal "fare" al "progettare come si fa" e poi verificare che sia stato fatto bene.
L'"Agent Manager" non è un nuovo titolo di lavoro (se lo vedete in giro, diffidate, è il nuovo 'Direttore dell'Innovazione'). È un nuovo livello di competenza che si colloca sotto tutto il resto. Non importa se sei nel CS, nel prodotto o nelle vendite. Se non sai orchestrare agenti, stai usando il venti per cento della tua capacità e impattando il dieci per cento di quello che potresti.
Questo non è opzionale. Mi aspetto che tutti dedichino tempo a imparare a lavorare con gli agenti. È la differenza tra qualcuno che esegue compiti e qualcuno che progetta sistemi. E qui, ora, cerchiamo i secondi.
I silos sono finiti
Ed ecco la conseguenza che meno mi aspettavo: i silos funzionali sono finiti. Non perché organizziamo un workshop di collaborazione interfunzionale. Non perché abbiamo un OKR condiviso. Si dissolvono perché quando puoi fare più cose, tocchi inevitabilmente più territorio.
La dipendenza tra i team era il collante che teneva i silos al loro posto. Eliminando la dipendenza, i silos perdono la loro ragione di esistere. Quello che resta sono persone che sanno sempre di più su tutto e che si muovono tra i problemi invece di muoversi tra i dipartimenti.
Non c'è un comitato per l'innovazione. Non c'è un laboratorio separato dal resto. Quello che c'è è una palla di neve che ogni persona spinge in una direzione diversa, e il risultato è qualcosa che nessuno di noi avrebbe potuto progettare da solo. La frontiera non è pianificata. Viene scoperta, ogni giorno, quando qualcuno attraversa un confine che nessuno gli aveva detto di poter attraversare.
Rileggi questa frase
La settimana scorsa, il nostro Talent Manager ha corretto un bug in produzione. Non ha sbagliato professione. Ha visto qualcosa di rotto, ha imparato abbastanza per capirlo e l'ha corretto. Presto, uno sviluppatore si siederà ad ascoltare registrazioni di chiamate a prospect, da una cadenza di prospecting che un SDR avrà progettato dall'inizio alla fine, ma che non esegue da solo. L'SDR progetta la strategia, gli agenti la eseguono, e lo sviluppatore vuole ancora capire cosa dicono i clienti per migliorare quello che sta costruendo.
Un SDR che progetta ma non esegue. Uno sviluppatore che ascolta chiamate di vendita. Un Talent Manager che fa push di codice. Se lo guardi dalla logica dell'organigramma, è un disastro. Se lo guardi dalla logica dei risultati, è il più efficiente che siamo mai stati.
Questo è quello che succede quando smetti di proteggere i confini tra i ruoli e inizi a proteggere la curiosità. La palla di neve cresce in tutte le direzioni. E la frontiera non è davanti. È ovunque.
Le tensioni
Non voglio dipingere tutto questo come un Eden. Ha le sue tensioni.
La più ovvia: se tutti possono costruire, chi decide cosa viene costruito? L'autonomia senza allineamento è caos. La risposta non è meno autonomia, ma più visibilità. Per questo mi aspetto qualcosa di molto specifico: condividi quello che stai costruendo, prima di costruirlo. Pensa ad alta voce. Pubblica prima di perfezionare. La trasparenza non è un di più. È quello che fa funzionare l'autonomia senza farla diventare anarchia.
C'è una trappola silenziosa nella capacità di costruire: è molto facile confondere l'output con l'outcome. Costruire qualcosa che funziona non è la stessa cosa che risolvere qualcosa che conta.
Prima di aprire Claude Code, prima di progettare il flusso, c'è una domanda che spero ognuno di voi si faccia: cosa deve essere diverso quando questo sarà finito? Non "cosa costruirò", ma "cosa deve essere cambiato". L'output è il mezzo; l'outcome è il punto.
Questo non rallenta l'azione: la orienta. Un builder che sa esattamente cosa sta cercando di cambiare costruisce più velocemente, non più lentamente, perché ogni decisione ha un nord chiaro.
La seconda tensione: l'identità professionale. Se non sei più "solo marketing" o "solo ops", cosa sei? Questo crea disagio. Ci sono persone che trovavano sicurezza nella specializzazione e che ora sentono il terreno muoversi. Capisco. Ma spero che abbracciate quel disagio invece di fuggirne. Perché quello che sei è un builder che sa molto di marketing. Un learner che padroneggia le ops. La tua competenza non scompare. Diventa la tua prospettiva, non il tuo perimetro. Espandere il perimetro è segno di una buona direzione.
60 persone, 100 volte più capacità
Siamo le stesse sessanta persone. Ma l'output di questa azienda sarà irriconoscibile rispetto a un anno fa. Non perché lavoriamo più ore. Lavoriamo, e lavoreremo, le stesse ore. È che ogni persona, con un team di agenti dietro di sé che amplifica tutto quello che fa, moltiplica il proprio raggio d'azione per 100. Quello che prima richiedeva due persone e una settimana, ora una persona può risolverlo in un pomeriggio. Non sempre. Ma sempre più spesso.
Questo ha implicazioni enormi su come pensiamo alla crescita. La domanda non è più "quante persone dobbiamo assumere" ma "quanto possiamo amplificare la capacità di quelle che abbiamo già". Non è un argomento contro le assunzioni. È un argomento per assumere in modo diverso: persone che sanno orchestrare, che imparano velocemente, che si sentono a proprio agio nell'ambiguità di un ruolo che cambia ogni trimestre. E mi aspetto lo stesso da chi è già qui: che ogni mese siate capaci di fare di più di quanto potevate il mese prima. Non più ore. Più capacità.
Builders e learners
Così descriviamo quello che cerchiamo e come ci approcciamo al lavoro.
Builder perché costruisci. Non solo pensi, non solo pianifichi, non solo fai strategia (tantomeno PowerPoint). Metti cose nel mondo. Codice, automazioni, documenti, sistemi. Cose che funzionano, che hanno un output, che qualcuno può usare domani. Mi aspetto che ogni settimana, ogni persona in questo team abbia messo nel mondo qualcosa che non esisteva lunedì.
Learner perché quello che sai oggi non basta per domani. Sei mesi fa nessuno in questo team sapeva orchestrare agenti. Tre mesi fa alcuni lo facevano con difficoltà. Oggi sta diventando lo standard. La velocità con cui cambiano gli strumenti, la soglia del possibile, esige una velocità equivalente di apprendimento. Non aspettare che qualcuno venga a insegnarti. Vai e impara. È più facile che mai. Chi smette di imparare, si ferma. Mi aspetto curiosità instancabile. Mi aspetto che rompiate cose provando. Mi aspetto domande prima di certezze. Se hai imparato qualcosa di nuovo, condividilo, dentro e fuori Dcycle.
Non sono due cose diverse. Sono la stessa: costruisci per imparare e impari per costruire.
La mia parte
Tutto quanto sopra è quello che mi aspetto da voi. Ora, la mia parte.
Se vi chiedo di costruire, mi impegno a togliere gli ostacoli dal cammino. Ogni processo che non apporta nulla, ogni approvazione che esiste solo per inerzia, ogni riunione che potrebbe essere un messaggio: è mia responsabilità eliminarli. Segnalatelo quando lo vedete. La vostra energia deve andare a costruire, non a navigare la burocrazia.
Se vi chiedo di rompere cose provando, mi impegno a fare in modo che rompere cose non abbia conseguenze. L'errore in buona fede qui non viene penalizzato. Viene analizzato, si impara, e si va avanti. L'unico errore imperdonabile è non provarci. Se mai doveste sentire che sbagliare ha un costo politico, ditemelo. Perché quello significherà che qualcosa nella cultura si è rotto, e ripararlo sarà la mia priorità numero uno.
E se vi chiedo di imparare costantemente, mi impegno a imparare con voi. Non da un ufficio. Dalle stesse trincee. Se smetto di costruire, di rompere cose, di fare domande scomode, avete il diritto di farmelo notare. Questo patto funziona in entrambe le direzioni o non funziona.
La cosa più trasformativa di tutte
Non so se tra un anno lavoreremo ancora esattamente così. Probabilmente no. Probabilmente avremo scoperto problemi che ora non vediamo, e avremo inventato soluzioni che ora non possiamo immaginare.
E questo, credo, è la cosa più trasformativa di tutte. Non la tecnologia. Non gli agenti. Non il codice. È la mentalità di qualcuno che smette di aspettare e inizia a risolvere. Di qualcuno che vede un problema e, invece di escalare, costruisce. Questo è quello che mi aspetto da ogni persona in questa azienda. Né più, né meno.
Ecco come lavoriamo in Dcycle. Builders. Learners. Manager di sé e di molti. E il cammino continua a farsi camminando.
J.