Crítica de Llibre: «Good Strategy / Bad Strategy» de Richard Rumelt
Vaig llegir «Good Strategy / Bad Strategy» de Richard Rumelt per primera vegada el 2019. L'he rellegit dues vegades des d'aleshores. És el tipus de llibre que es torna més nítid cada vegada perquè continues reconeixent els seus patrons en les teves pròpies decisions — especialment en les dolentes.
L'argument central de Rumelt és enganyosament simple: la major part del que passa per estratègia no ho és en absolut. Són objectius disfressats de llenguatge aspiracional. Són declaracions de visió en una presentació. Són llistes de prioritats tan llargues que res no està realment prioritzat. I en el món de les startups, on "estratègia" s'esmenta a cada reunió del consell i a cada all-hands, aquest problema és endèmic.
Si lideres un equip d'enginyeria, gestiones un producte o dirigeixes una startup, aquest llibre canviarà com penses sobre les decisions. Aquí tens el perquè.
El Nucli de la Bona Estratègia
Rumelt defineix la bona estratègia com composta per tres parts — el que anomena el nucli (kernel):
1. Diagnòstic: Quin és el repte real?
El diagnòstic és una avaluació honesta de la situació. No el que voldries que fos cert. El problema real.
He estat en reunions d'estratègia on el diagnòstic era "hem de créixer més ràpid". Això no és un diagnòstic — és un desig. Un diagnòstic real: "La nostra conversió de prova a pagament és del 4%, la meitat del benchmark del sector, perquè l'onboarding perd el 60% dels usuaris abans que vegin el valor central."
En termes d'enginyeria, un bon diagnòstic: "El nostre cicle de desplegament tarda 3 setmanes perquè no tenim proves automatitzades, un procés de QA manual i una estratègia de branca única." Específic. Accionable. Nomena la restricció real.
Un mal diagnòstic: "Hem de llançar més ràpid." Tothom assenteix. Ningú sap què fer.
2. Política Orientadora: L'enfocament
La política orientadora és l'enfocament general davant el repte diagnosticat. No una acció específica — la direcció que condiciona les teves accions.
L'analogia de Rumelt: una política orientadora és com una barrera de protecció en una carretera de muntanya. No et diu cap on girar, però t'impedeix caure per l'espadat.
Per a l'exemple del desplegament: "Invertirem en automatització per fer que els desplegaments siguin d'autoservei i eliminar la coordinació manual." Això no especifica quina eina CI/CD fer servir ni com gestionar les migracions. Fixa la direcció.
La característica clau d'una bona política orientadora és que pren decisions. Diu "farem això, no allò". Si la teva "estratègia" no descarta res, no és una estratègia.
3. Acció Coherent: Passos coordinats
El tercer element és un conjunt d'accions coordinades que implementen la política orientadora. No una llista de desitjos. No 47 iniciatives. Un conjunt enfocat de moviments que es reforcen mútuament.
Per al nostre problema de desplegament: (1) introduir feature flags per desacoblar el desplegament del llançament, (2) configurar CI amb suites de proves automatitzades per als dos serveis de major tràfic, (3) passar al desenvolupament trunk-based. Aquests tres moviments són coherents — cadascun dóna suport als altres, i junts aborden el problema diagnosticat.
La coherència és el que separa l'estratègia d'una llista de tasques. Una llista de projectes de millora no relacionats no és una estratègia. Un conjunt d'accions mútuament reforçants dirigides a un repte específic sí que ho és.
La Mala Estratègia és Per Tot Arreu
La taxonomia de la mala estratègia de Rumelt em va colpejar com un tren de mercaderies perquè vaig reconèixer cada patró en empreses amb les quals havia treballat:
La pararotada. Llenguatge inflat que no diu res. "Aprofitarem les nostres capacitats de plataforma sinèrgiques per desbloquejar valor a tot l'ecosistema." Treu l'argot i no queda res a sota.
Confondre objectius amb estratègia. "La nostra estratègia és ser el líder del mercat en eines per a desenvolupadors." Això és un objectiu, no una estratègia. On és el diagnòstic? On és la política orientadora?
No prendre decisions. El patró més perjudicial. Una empresa que llista 12 "prioritats estratègiques" té zero prioritats estratègiques. Estratègia significa decidir el que NO faràs. Si el teu equip d'enginyeria està simultàniament reescrivint el backend, construint tres funcionalitats, migrant a un nou núvol i reduint el deute tècnic en un 40%, tens una fantasia, no una estratègia.
Ignorar el repte. Saltar directament a objectius i accions sense identificar el que és realment difícil. El resultat són manuals genèrics que no aborden les restriccions específiques.
Per Què la Majoria dels OKRs No Són Estratègia
Aquí és on el marc de Rumelt fa de debò mal en el món tecnològic. Els OKRs — Objectius i Resultats Clau — són excel·lents eines d'execució. Però no són estratègia, i tractar-los com si ho fossin és un dels errors més comuns que veig.
Un OKR com "Augmentar la fiabilitat de la plataforma al 99,95% de disponibilitat" és un objectiu amb un resultat mesurable. Et diu com és l'èxit. No et diu:
- Per què la fiabilitat és el repte més important ara (diagnòstic)
- Quin enfocament adoptaràs per millorar-la (política orientadora)
- Quines accions específiques i coordinades executaràs (acció coherent)
Els OKRs es troben aigües avall de l'estratègia. L'operacionalitzen. Però si estableeixes OKRs sense estratègia, acabes amb una col·lecció d'objectius mesurables que no es connecten entre si i no aborden el teu repte central. Cada equip compleix els seus OKRs i l'empresa encara no avança, perquè ningú ha fet la pregunta difícil: "Quin és el problema més important que hem de resoldre, i què farem al respecte?"
Aplicant Rumelt a les Decisions d'Enginyeria
Aquí és on el llibre es torna intensament pràctic per a qualsevol que lideri enginyeria:
Decisions d'arquitectura. Hauria de reescriure o refactoritzar? El marc de Rumelt t'obliga a començar amb el diagnòstic. Quin és el problema real? Si és "el monòlit és lent per desplegar", la política orientadora podria ser extreure els mòduls d'alta rotació en serveis — no una reescriptura completa. Les accions coherents segueixen: identificar els 3 mòduls principals per freqüència de canvi, definir límits de servei, implementar una extracció com a prova de concepte.
Build vs. buy. "Construïm tot internament" no és una estratègia — és un valor predeterminat. Un bon diagnòstic: "Gastem el 30% del temps d'enginyeria mantenint infraestructura de base." Política orientadora: "Comprar serveis gestionats per als no diferenciadors; construir només on tenim avantatge únic." Ara cada decisió futura té un filtre.
Escalada de l'equip. "Contractar 20 enginyers" és un objectiu. La versió estratègica: "La velocitat de lliurament s'ha reduït a la meitat perquè dos equips s'interfereixen en una base de codi compartida." Política orientadora: "Establir la propietat del domini abans d'augmentar el headcount." Accions coherents: definir contextos delimitats, dividir la base de codi, crear APIs d'equip, després contractar per a la nova estructura.
La Part Difícil: Prendre Decisions
La veritat més incòmoda d'aquest llibre és que la bona estratègia requereix dir que no. No "ara no". No.
Si ets una startup amb 8 enginyers i intentes construir simultàniament una aplicació mòbil, una aplicació web, una plataforma API i una funcionalitat d'IA, no tens una estratègia. Tens FOMO. Rumelt et diria que diagnostiquis el teu avantatge competitiu real, tries l'única cosa que més importa i l'executis amb coherència.
Això significa dir-li a algú — un cofundador, un membre del consell, un client — que no faràs el que vol. Per això la mala estratègia és molt més comuna que la bona. La mala estratègia et permet evitar el conflicte. La bona estratègia l'exigeix.
A Conectia, veiem aquest patró constantment amb les startups amb les quals treballem. Els fundadors acudeixen a nosaltres necessitant enginyers, però la conversa real sovint comença amb "què hauríem de construir primer?" Quan integrem enginyers senior en un equip, no només escriuen codi — fan les preguntes de diagnòstic que afilen l'estratègia. Quin és el veritable coll d'ampolla? Què hauríem de deixar de fer? On afegir capacitat realment resol el problema enfront de simplement fer el caos més ràpid?
Això és el que aporten els enginyers amb experiència: no només execució, sinó criteri sobre el que s'ha d'executar.
Construint el teu equip d'enginyeria i vols persones que pensin estratègicament, no simplement que escriguin codi? Parla amb un CTO — integrem enginyers senior de LATAM que fan les preguntes correctes abans d'escriure la primera línia.
