Recensione del Libro: «Good Strategy / Bad Strategy» di Richard Rumelt
Ho letto «Good Strategy / Bad Strategy» di Richard Rumelt per la prima volta nel 2019. L'ho riletto due volte da allora. È il tipo di libro che diventa più nitido a ogni lettura perché continui a riconoscere i suoi schemi nelle tue stesse decisioni — specialmente in quelle sbagliate.
L'argomento centrale di Rumelt è ingannevolmente semplice: la maggior parte di ciò che passa per strategia non è strategia affatto. Sono obiettivi travestiti da linguaggio aspirazionale. Sono dichiarazioni di visione su una slide. Sono elenchi di priorità così lunghi che niente è veramente prioritizzato. E nel mondo delle startup, dove la "strategia" viene citata in ogni riunione del consiglio e in ogni all-hands, questo problema è endemico.
Se guidi un team di ingegneria, gestisci un prodotto o dirigi una startup, questo libro cambierà il tuo modo di pensare alle decisioni. Ecco perché.
Il Nucleo della Buona Strategia
Rumelt definisce la buona strategia come composta da tre parti — quello che chiama il nucleo (kernel):
1. Diagnosi: Qual è la vera sfida?
La diagnosi è una valutazione onesta della situazione. Non ciò che vorresti fosse vero. Il problema reale.
Sono stato in riunioni di strategia dove la diagnosi era "dobbiamo crescere più velocemente". Non è una diagnosi — è un desiderio. Una diagnosi reale: "Il nostro tasso di conversione da prova a pagamento è del 4%, la metà del benchmark di settore, perché l'onboarding perde il 60% degli utenti prima che vedano il valore centrale."
In termini ingegneristici, una buona diagnosi: "Il nostro ciclo di deployment richiede 3 settimane perché non abbiamo test automatizzati, un processo QA manuale e una strategia a singolo ramo." Specifico. Azionabile. Nomina il vero vincolo.
Una cattiva diagnosi: "Dobbiamo rilasciare più velocemente." Tutti annuiscono. Nessuno sa cosa fare.
2. Politica Guida: L'approccio
La politica guida è l'approccio complessivo alla sfida diagnosticata. Non un'azione specifica — la direzione che vincola le tue azioni.
L'analogia di Rumelt: una politica guida è come un guardrail su una strada di montagna. Non ti dice dove sterzare, ma ti impedisce di cadere nel precipizio.
Per l'esempio del deployment: "Investiremo nell'automazione per rendere i deployment self-service ed eliminare il coordinamento manuale." Questo non specifica quale strumento CI/CD usare né come gestire le migrazioni. Fissa la direzione.
La caratteristica chiave di una buona politica guida è che fa scelte. Dice "faremo questo, non quello". Se la tua "strategia" non esclude nulla, non è una strategia.
3. Azioni Coerenti: Passi coordinati
Il terzo elemento è un insieme di azioni coordinate che implementano la politica guida. Non una lista dei desideri. Non 47 iniziative. Un insieme focalizzato di mosse che si rafforzano a vicenda.
Per il nostro problema di deployment: (1) introdurre feature flag per disaccoppiare il deployment dal rilascio, (2) configurare una CI con suite di test automatizzati per i due servizi ad alto traffico, (3) passare allo sviluppo trunk-based. Queste tre mosse sono coerenti — ognuna supporta le altre, e insieme affrontano il problema diagnosticato.
La coerenza è ciò che separa la strategia da una lista di cose da fare. Un elenco di progetti di miglioramento non correlati non è una strategia. Un insieme di azioni mutuamente rafforzanti mirate a una sfida specifica lo è.
La Cattiva Strategia È Ovunque
La tassonomia della cattiva strategia di Rumelt mi ha colpito come un treno merci perché ho riconosciuto ogni schema nelle aziende con cui avevo lavorato:
La retorica vuota. Linguaggio gonfiato che non dice nulla. "Leveraggeremo le nostre capacità di piattaforma sinergiche per sbloccare valore in tutto l'ecosistema." Togli il gergo e non rimane niente sotto.
Confondere gli obiettivi con la strategia. "La nostra strategia è essere il leader di mercato negli strumenti per sviluppatori." Questo è un obiettivo, non una strategia. Dov'è la diagnosi? Dov'è la politica guida?
Non fare scelte. Lo schema più dannoso. Un'azienda che elenca 12 "priorità strategiche" ha zero priorità strategiche. La strategia significa decidere cosa NON fare. Se il tuo team di ingegneria sta contemporaneamente riscrivendo il backend, costruendo tre funzionalità, migrando verso un nuovo cloud e riducendo il debito tecnico del 40%, hai una fantasia, non una strategia.
Ignorare la sfida. Saltare direttamente agli obiettivi e alle azioni senza identificare cosa è davvero difficile. Il risultato sono playbook generici che non affrontano i vincoli specifici.
Perché la Maggior Parte degli OKR Non Sono Strategia
È qui che il framework di Rumelt fa davvero male nel mondo tech. Gli OKR — Obiettivi e Risultati Chiave — sono eccellenti strumenti di esecuzione. Ma non sono strategia, e trattarli come se lo fossero è uno degli errori più comuni che vedo.
Un OKR come "Aumentare l'affidabilità della piattaforma al 99,95% di uptime" è un obiettivo con un risultato misurabile. Ti dice come appare il successo. Non ti dice:
- Perché l'affidabilità è la sfida più importante adesso (diagnosi)
- Quale approccio adotterai per migliorarla (politica guida)
- Quali azioni specifiche e coordinate eseguirai (azioni coerenti)
Gli OKR si trovano a valle della strategia. La operazionalizzano. Ma se imposti OKR senza una strategia, finisci con una collezione di obiettivi misurabili che non si collegano tra loro e non affrontano la tua sfida centrale. Ogni team raggiunge i propri OKR e l'azienda non avanza ancora, perché nessuno ha posto la domanda difficile: "Qual è il problema più importante che dobbiamo risolvere, e cosa faremo al riguardo?"
Applicare Rumelt alle Decisioni di Ingegneria
È qui che il libro diventa intensamente pratico per chiunque guidi l'ingegneria:
Decisioni architetturali. Dovrei riscrivere o refactorizzare? Il framework di Rumelt ti forza a iniziare con la diagnosi. Qual è il vero problema? Se è "il monolite è lento da deployare", la politica guida potrebbe essere estrarre i moduli ad alta rotazione in servizi — non una riscrittura completa. Le azioni coerenti seguono: identificare i 3 moduli principali per frequenza di cambiamento, definire i confini del servizio, implementare un'estrazione come proof of concept.
Build vs. buy. "Costruiamo tutto internamente" non è una strategia — è un default. Una buona diagnosi: "Spendiamo il 30% del tempo di ingegneria a manutenere infrastruttura banale." Politica guida: "Comprare servizi gestiti per i non-differenziatori; costruire solo dove abbiamo un vantaggio unico." Ora ogni decisione futura ha un filtro.
Scaling del team. "Assumere 20 ingegneri" è un obiettivo. La versione strategica: "La velocità di delivery si è dimezzata perché due team si ostacolano a vicenda in una codebase condivisa." Politica guida: "Stabilire la proprietà del dominio prima di aumentare il personale." Azioni coerenti: definire contesti delimitati, dividere la codebase, creare API di team, poi assumere nella nuova struttura.
La Parte Difficile: Fare Scelte
La verità più scomoda in questo libro è che la buona strategia richiede di dire no. Non "non adesso". No.
Se sei una startup con 8 ingegneri e stai cercando di costruire contemporaneamente un'app mobile, un'app web, una piattaforma API e una funzionalità AI, non hai una strategia. Hai FOMO. Rumelt ti direbbe di diagnosticare il tuo vero vantaggio competitivo, scegliere l'unica cosa che conta di più ed eseguirla con coerenza.
Questo significa dire a qualcuno — un co-fondatore, un membro del consiglio, un cliente — che non farai la cosa che vuole. Ecco perché la cattiva strategia è molto più comune di quella buona. La cattiva strategia ti permette di evitare il conflitto. La buona strategia lo richiede.
In Conectia, vediamo questo schema costantemente con le startup con cui lavoriamo. I fondatori vengono da noi con il bisogno di ingegneri, ma la vera conversazione spesso inizia con "cosa dovremmo costruire prima?" Quando integriamo ingegneri senior in un team, non scrivono solo codice — pongono le domande diagnostiche che affinano la strategia. Qual è il vero collo di bottiglia? Cosa dovremmo smettere di fare? Dove aggiungere capacità risolve davvero il problema rispetto a rendere il caos semplicemente più veloce?
È ciò che portano gli ingegneri esperti: non solo esecuzione, ma giudizio su cosa eseguire.
Stai costruendo il tuo team di ingegneria e vuoi persone che pensino strategicamente, non solo che scrivano codice? Parla con un CTO — integriamo ingegneri senior LATAM che fanno le domande giuste prima di scrivere la prima riga.
