Ressenya: «Good Strategy / Bad Strategy», de Richard Rumelt
Vaig llegir «Good Strategy / Bad Strategy», de Richard Rumelt, per primer cop el 2019, i d'aleshores ençà l'he rellegit dues vegades. És d'aquells llibres que guanyen a cada relectura, perquè no pares de reconèixer-ne els patrons en les teves pròpies decisions — sobretot en les dolentes.
L'argument central de Rumelt és enganyosament simple: la major part del que es fa passar per estratègia no n'és. Són objectius vestits de llenguatge aspiracional. Són declaracions de visió en una presentació de diapositives. Són llistes de prioritats tan llargues que, a la pràctica, no hi ha res prioritari. I al món de les startups, on la paraula «estratègia» surt a cada consell i a cada all-hands, el problema és endèmic.
Si lideres un equip d'enginyeria, gestiones un producte o dirigeixes una startup, aquest llibre et canviarà la manera de pensar les decisions. T'explico per què.
La bona estratègia té exactament tres parts
Rumelt defineix la bona estratègia per tres parts — el que ell 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 t'agradaria que fos veritat: el problema real.
He segut 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 de debò: «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 principal del producte.»
En termes d'enginyeria, un bon diagnòstic: «El nostre cicle de desplegament triga 3 setmanes perquè no tenim tests automatitzats, el QA és manual i publiquem des d'una sola branca.» Específic. Accionable. Posa nom a la restricció real.
Un mal diagnòstic: «Hem de publicar més ràpid.» Tothom assenteix. Ningú no sap què fer.
2. Política orientadora: l'enfocament
La política orientadora és l'enfocament general davant del repte diagnosticat. No és una acció concreta: és la direcció que acota les teves accions.
L'analogia de Rumelt: una política orientadora és com la barana de seguretat d'una carretera de muntanya. No et diu per on has de girar, però evita que t'estimbis.
Per a l'exemple del desplegament: «Invertirem en automatització perquè els desplegaments siguin autoservei i desaparegui la coordinació manual.» No especifica quina eina de CI/CD ni com gestionaràs les migracions. Marca una direcció.
La característica clau d'una bona política orientadora és que tria. Diu «farem això, i 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 acotat de moviments que es reforcen entre si.
Per al nostre problema de desplegament: (1) introduir feature flags per desacoblar desplegament i llançament, (2) muntar CI amb suites de tests automatitzats per als dos serveis amb més trànsit, (3) passar a trunk-based development. Aquests tres moviments són coherents: cadascun reforça els altres i, junts, ataquen el problema diagnosticat.
La coherència és el que separa una estratègia d'una llista de tasques. Una llista de projectes de millora inconnexos no és una estratègia. Un conjunt d'accions que es reforcen mútuament, apuntades a un repte concret, sí.
La mala estratègia és a tot arreu
La taxonomia de la mala estratègia de Rumelt em va fer mal de llegir, perquè hi reconeixia cada patró d'empreses amb què havia treballat:
Fum. Llenguatge inflat que no diu res. «Aprofitarem les capacitats sinèrgiques de la nostra plataforma per desbloquejar valor a tot l'ecosistema.» Treu-ne l'argot i a sota no hi queda res.
Confondre objectius amb estratègia. «La nostra estratègia és ser líders de 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 triar. El patró que fa més mal. Una empresa que llista 12 «prioritats estratègiques» té zero prioritats estratègiques. Estratègia vol dir decidir què NO faràs. Si el teu equip d'enginyeria reescriu el backend, construeix tres funcionalitats, migra a un núvol nou i redueix el deute tècnic un 40%, tot alhora, no tens una estratègia: tens una fantasia.
Ignorar el repte. Saltar directament als objectius i les accions sense identificar què és realment difícil. El resultat: receptes genèriques que no toquen les restriccions concretes.
Per què la majoria d'OKRs no són estratègia
Aquí és on el marc de Rumelt pica més fort al món tecnològic. Els OKRs — Objectives and Key Results — són eines d'execució excel·lents. Però no són estratègia, i tractar-los com si ho fossin és un dels errors que veig més sovint.
Un OKR com «augmentar la fiabilitat de la plataforma fins al 99,95% de disponibilitat» és un objectiu amb un resultat mesurable. Et diu quina pinta té l'èxit. El que no et diu:
- Per què la fiabilitat és ara mateix el repte més important (diagnòstic)
- Amb quin enfocament la milloraràs (política orientadora)
- Quines accions concretes i coordinades executaràs (acció coherent)
Els OKRs són aigües avall de l'estratègia: l'operacionalitzen. Però si fixes OKRs sense estratègia, acabes amb una col·lecció d'objectius mesurables que ni es connecten entre si ni ataquen el teu repte de fons. Cada equip compleix els seus OKRs i l'empresa continua sense avançar, perquè ningú no ha fet la pregunta difícil: «Quin és el problema més important que hem de resoldre, i què hi farem?»
Les decisions d'enginyeria són decisions d'estratègia
Aquí és on el llibre es torna intensament pràctic per a qualsevol que lideri enginyeria:
Decisions d'arquitectura. Reescriure o refactoritzar? El marc de Rumelt t'obliga a començar pel diagnòstic. Quin és el problema real? Si és «el monòlit és lent de desplegar», la política orientadora pot ser extreure com a serveis els mòduls que canvien més sovint — no pas reescriure-ho tot. Les accions coherents en deriven: identificar els 3 mòduls amb més freqüència de canvi, definir les fronteres de servei i implementar una primera extracció com a prova de concepte.
Build vs. buy. «Aquí ho construïm tot nosaltres» no és una estratègia: és una inèrcia. Un bon diagnòstic: «Dediquem el 30% del temps d'enginyeria a mantenir infraestructura que és pura commodity.» Política orientadora: «Comprar serveis gestionats per a tot allò que no ens diferencia; construir només on tenim un avantatge únic.» A partir d'aquí, cada decisió futura té un filtre.
Fer créixer l'equip. «Contractar 20 enginyers» és un objectiu. La versió estratègica: «La velocitat de lliurament ha caigut a la meitat perquè dos equips es trepitgen en una mateixa base de codi.» Política orientadora: «Establir la propietat per dominis abans d'ampliar plantilla.» Accions coherents: definir bounded contexts, partir la base de codi, crear APIs d'equip i, llavors sí, contractar per a la nova estructura.
La part difícil: triar
La veritat més incòmoda del llibre és que la bona estratègia exigeix dir que no. No «ara no». No.
Si ets una startup amb 8 enginyers i vols construir alhora una app mòbil, una app web, una plataforma d'API i una funcionalitat d'IA, no tens una estratègia: tens FOMO. Rumelt et diria que diagnostiquis el teu avantatge competitiu real, que triïs la cosa que més importa i que l'executis amb coherència.
Això vol dir dir-li a algú — un cofundador, un membre del consell, un client — que no faràs allò que vol. Per això la mala estratègia és molt més freqüent que la bona: la mala estratègia et permet esquivar el conflicte; la bona, l'exigeix.
A Conectia veiem aquest patró constantment amb les startups amb què treballem. Els fundadors ens venen a buscar perquè necessiten enginyers, però la conversa de debò sovint comença per «què hauríem de construir primer?». Quan integrem enginyers sènior en un equip, no es limiten a escriure codi: fan les preguntes de diagnòstic que esmolen l'estratègia. Quin és el coll d'ampolla real? Què hauríem de deixar de fer? On afegir capacitat resol el problema de veritat, i on només serveix per accelerar el caos?
Això és el que aporta un enginyer amb experiència: no només execució, sinó criteri per decidir què cal executar.
Estàs fent créixer el teu equip d'enginyeria i vols gent que pensi estratègicament, no només que escrigui codi? Parla amb un CTO — integrem enginyers sènior de LATAM que fan les preguntes adequades abans d'escriure la primera línia.
