Franchising di progetti indipendenti: perché le grandi aziende di software dovrebbero far emergere l'innovazione invece di eliminarla

      TL;DRLe grandi aziende software costruiscono regolarmente strumenti interni che si rivelano preziosi, per poi lasciarli decadere quando le priorità cambiano. Robert Brownstein propone il “franchising di progetti indipendenti”: consentire agli ingegneri più vicini a uno strumento interno convalidato di svilupparlo come un'impresa autonoma, con la società madre come primo cliente e partner di licenza. I dati di PwC mostrano che il 42% dei CEO teme di non trasformarsi abbastanza rapidamente; Deloitte avverte che i concorrenti snelli e nativi dell'IA stanno abbassando il costo minimo per il software.

      L'innovazione di solito non muore perché un esperimento fallisce. Muore quando la proprietà scompare. Le grandi aziende software possono costruire uno strumento accessorio, dimostrare che risolve un problema reale e comunque privarlo di attenzione una volta che la leadership reindirizza il team verso il prodotto di punta o la prossima iniziativa urgente. Il mio argomento è semplice: quando un progetto interno utile non si adatta più alla roadmap aziendale, le aziende dovrebbero considerare di dargli indipendenza prima di abbandonarlo.

      Il tempismo è importante. Nel Global CEO Survey 2026 di PwC, il 42% dei dirigenti ha dichiarato che la loro maggiore preoccupazione era se si stessero trasformando abbastanza rapidamente per tenere il passo con il cambiamento tecnologico, mentre il 29% ha messo in dubbio se la loro capacità di innovazione fosse adeguata. Tuttavia, un'analisi correlata di PwC ha rilevato che, sebbene la metà dei CEO consideri l'innovazione centrale nella strategia, solo l'8% ha implementato sostanzialmente almeno 5 delle 6 pratiche associate al suo supporto. L'industria non manca di ambizione. Manca di strutture durevoli per portare avanti lavori promettenti attraverso un cambiamento di priorità.

      Gli ingegneri software conoscono il modello. Un'azienda decide di aver bisogno di una capacità, assegna persone per costruirla e crea slancio attorno al lavoro. Mesi dopo, il progetto viene dichiarato “sufficiente”. Gli ingegneri si spostano altrove, ma i rapporti sui bug, le preoccupazioni per la sicurezza, le esigenze di integrazione e le richieste di funzionalità rimangono. Chiamo il ciclo ripetuto “frustrazione dell'iniziativa”: i team costruiscono contesto e convinzione, poi perdono entrambi quando arriva una nuova direttiva.

      Il costo non è limitato al budget di sviluppo originale. Nella mia esperienza, gli ingegneri continuano a possedere il rischio del codice che non hanno più tempo per migliorare. Quando se ne vanno, la loro conoscenza istituzionale se ne va con loro. Il prossimo team deve ricostruire decisioni passate, lavorare attorno a un'architettura trascurata o riscrivere ciò che non può mantenere con fiducia. Un progetto apparentemente completato può quindi diventare una responsabilità organizzativa ricorrente.

      Questo problema sta diventando più urgente man mano che l'economia del software cambia. L'Outlook 2026 dell'industria software globale di Deloitte afferma che la creazione di software sta diventando più veloce e più economica, mentre i concorrenti snelli e nativi dell'IA stanno mettendo pressione sulle aziende consolidate. Tuttavia, una produzione più rapida non crea proprietà a lungo termine. Può semplicemente aiutare le organizzazioni a produrre più progetti che successivamente competono per la manutenzione.

      Propongo una via di mezzo tra mantenere tutto all'interno e ucciderlo: il franchising di progetti indipendenti. Non sto descrivendo un franchising al dettaglio convenzionale. Intendo consentire alle persone più vicine a una capacità promettente e non core di formare una piccola impresa indipendente attorno ad essa. La società madre potrebbe diventare un cliente ancorato, mantenere una licenza o un interesse economico di minoranza e fornire un finanziamento di transizione limitato. La nuova azienda guadagnerebbe la libertà di servire altri clienti e costruire un prodotto duraturo piuttosto che una funzionalità interna una tantum.

      Quell'accordo può contenere rischi da entrambe le parti. La madre evita di fare un impegno aperto per un prodotto non provato. L'impresa guadagna un primo cliente noto, ingegneri esperti e un problema già osservato nella pratica. Se la domanda non emerge, l'esperimento rimane limitato. Se il prodotto ha successo, la madre può continuare a licenziarlo, approfondire la partnership, acquisirlo o riportare la capacità all'interno. L'indipendenza diventa un meccanismo di prova, non un rito di separazione.

      Il mio passaggio dallo sviluppo software aziendale alla costruzione di prodotti indipendenti ha cambiato il modo in cui vedo questo problema. Ora sviluppo e test prodotti in modo indipendente, inclusi strumenti grafici basati su browser. Senza le priorità aziendali che reindirizzano il mio lavoro ogni pochi trimestri, posso seguire lo stesso problema tecnico attraverso prodotti e clienti. Quella continuità non garantisce il successo. Rende l'apprendimento cumulativo perché le persone che ricevono feedback rimangono responsabili di ciò che il codice diventa successivamente.

      Questo modello dovrebbe essere selettivo. Un'azienda non dovrebbe separare il proprio prodotto di punta, infrastrutture strategicamente sensibili o software che non può essere separato in sicurezza da dati e sistemi protetti. Né l'imprenditorialità dovrebbe diventare un'etichetta educata per trasferire il rischio aziendale ai dipendenti senza finanziamenti, diritti o una base clienti realistica. L'indagine 2026 di EY sui leader tecnologici in Irlanda ha rilevato che il 36% ha citato lacune di talento e circa il 30% ha citato limiti di budget come sfide chiave. Un spinout non risolverà nessuno dei due problemi se inizia sottodimensionato e sottofinanziato.

      Prima di approvarne uno, i leader dovrebbero richiedere prove di domanda oltre a un singolo sponsor interno, un proprietario tecnico impegnato, confini chiari di proprietà intellettuale e dati, un accordo di supporto, traguardi di finanziamento e un processo di chiusura concordato. Il team deve sapere cosa possiede. La madre deve sapere cosa può usare. Entrambi devono sapere cosa succede se il mercato dice di no.

      Le grandi aziende software continuano a chiedere come preservare l'innovazione all'interno della corporation. Quella domanda potrebbe essere troppo ristretta. Dovrebbero chiedere come una buona idea possa ricevere abbastanza autonomia, tempo e proprietà responsabile per dimostrare se merita un mercato. Il maggiore rischio per l'innovazione aziendale non è che ogni esperimento possa fallire. È che lavori promettenti non saranno mai autorizzati a diventare un vero esperimento.